Webrtc is p2p (peer to peer) for browsers. You can use it for audio, video. Datachannel is a bit like p2p websockets.
Why did he wanted to use it? Well, he writes educational software. In elementary schools in the Netherlands, that often means a teacher and a digiboard. He showed a demo with a website that showed a six-figure code that the teacher then had to type in on his accompagnying phone app. After thus connecting the webbrowser to the phone, he could then steer the webbrowser from the phone. Advancing sheets, and so.
The advantage about webrtc and p2p: it is a direct connection between the phone and the browser, without being dependent on the ofttimes-flaky school’s internet connection.
How do you build up a connection? The one that starts creates an
RTCPeerConnection and creates a “session offer”. The one that wants to
connect can create a reply, accepting the offer, and send it back. The initial
communication has to happen over another type of connection as you haven’t,
well, set up the p2p connection yet :-) REST and web sockets are often used
It is fun. If you want to experiment, look at bistri. For instance http://blog.bistri.com/webrtc-demo. They have samples you can use.
A big problem with webrtc is that it provides almost no feedback about what succeeds or not. So if it doesn’t work, you’re out of luck. If it works, it works...
In the end it turned out to be too much pain to get/keep everything working. The current solution uses websockets.
Real time websites are fun. Like http://casperflights.com/unified/?location=eham for live airplane flight tracking.
According to its website, Meteor’s distributed data protocol (DDP) is a simple protocol for fetching structured data from a server, and receiving live updates when that data changes. DDP is like “REST for websockets”.
Real-time functionality in websites is going to be the default. We are going to need to connect to live firehoses like twitter. DDP is a way to share between applications. It has no http, no REST and no request/response cycle. It is pub/sub and remote procedure calls. Basically a bi-directional json.
He showed a live demo with http://endpoint15.meteor.com/, everybody in the audience was happily dragging photos (avatars of the attendees) around on the map. No XHR requests visible in the chrome dev tools, but there was a lot of content moving over a websocket connection.
The DDP spec consists of four parts:
He then showed the demo’s code. One code base, with some explicit if/else
Meteor.isClient statements. So: one short 77-line (!)
(He mentioned https://api.import.io/ as that helped him grab the attendees’ avatars from the meetup page).
When to use DDP? You could use it for full stack real-time web applications (if you dare). You can also create realtime functionality as an addition to an existing app. Also nice: the “Internet of Things”: lots of possibilities there!
Can it scale? Well, it is limited to the max connections your box can sustain. If you do loadbalancing, you need “session affinity”. There’s simple autoscaling if you use certain hosted solutions.
See also https://github.com/peterpeerdeman/ddp-the-real-time-api-for-web-applications/ for the code examples.
His closing comment: push the web forward! And give DDP a try. Use DDP instead of yet-another-ad-hoc-message-protocol.
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):