WebRTC's RTCDataChannel for real time updates avoiding mongodb

[Bjorn Tipling]

Hi,

I've been going over WebRTC and am currently working on a Meteor experiment where I enable screen sharing and video conferencing on Meteor.js and have come upon an idea which I think may address some of the things I've heared other Meteor.js developers discuss: a way to send real time messages from client to client without storing stuff in MongoDB collections.

I think RTCDataChannel might just be thing thing for this. It takes a little bit of setup to turn on the connection, but once it's running it's client to client communication. If the data isn't too much, you can connect a great deal of clients this way. Maybe it even makes sense for Meteor to make this easier. I might explore developing a package. The big draw back is in client support. Most of this technology only barely works in Chrome Canary, and beta Firefox.

I'm pretty excited about this though. You can avoid putting things in Mongodb right now, but it's a little bit of a hack (but at least it works in all browsers). I haven't been following the latest changes in devel so maybe this has improved. In any case RTCDataChannel is right up Meteor's alley though.

I still have quit a bit of work left on my project, but hope to have something that works in Chrome Canary soon. Right now it only calls getUserMedia: https://github.com/btipling/meteor_webrtc

B

[Gabriel Pugliese]

Hey Bjorn,

I've already researched about it, but very little. I wanted to implement screensharing too but there's some concerns about connection throughput, because upload limits from ISPs are, in most cases, very low and if you have 3+ people watching it, it's not pleasant to watch.

So, storing data on MongoDB for me is nice. It could be a mediator for every user. Have you tried to implement that ? I would like to see how do you do that :)

The best case cenario for me is to make something what Tokbox does - a central server that only serves the video data. But they support only up to 4 people at the same time with openTok.

Another thing is that limitation with browsers that pisses me off. But the WebRTC website says that it's available for Firefox and Chrome stable releases: http://www.webrtc.org/ . And I imagine, will IE ever have this feature ? :(

Gabriel Pugliese CodersTV.com @gabrielsapo

--
You received this message because you are subscribed to the Google Groups "meteor-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meteor-talk...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Bjorn Tipling]

Oh maybe my post was a little confusing. It had quite a few typos, sorry. What I meant to say is that I think WebRTC's RTCDataChannel might help users send real time data from client to client without having to store stuff in MongoDB. Right now some developers, including myself, perceive this is a major limitation in Meteor, but I think RTCDataChannel, just to send small bits of data like bjson sent via ddp, might be a great way to get around having to store stuff in MongoDB.

For example if you want a chat room in Meteor.js, and you want to detect who all is connected to your room, you might do something like in the presence package in Atmosphere, which uses a collection in MongoDB called Meteor.precesnces. The client does polling on a basic interval and the server does a findOne query lookup on MongoDB. Not very real time, not very efficient. If you built something with socket.io/sockjs yourself you could probably store these connections in memory (if there's a lot in redis) and update automatically by referencing the actuall connection. 

But RTCDataChannel is even better than that, because it's peer to peer. You get real time connection updates, without using the server for anything other than initial signaling. No polling, no storing stuff in mongodb. You actually know immediately who is in your chat room because the clients are all directly talking to each other.

For stuff like video you are correct, the bandwidth is significant, the solution is probably to use an MCU for WebRTC, but there aren't any good solutions in that space, all that is still experimental. I'm still working on just getting the basic p2p connection working, but that isn't going to be a big challenge, just following the documentation.

B

[Silly Clown]

Update meteor-server and peer-clients in parallel rather than serial intermediate meteor-server to peer-clients.

[Robert Dickert]

Hi Bjorn,

You may want to check out the streams package by Arunoda. It still goes through the server, but it does give you real-time data communication without Mongo, and it gives you built-in security and filtering through Meteor. If it suits, it will be much easier than implementing WebRTC and will work across browsers. Obviously, this won't work if you require that the connection be true peer-to-peer with no server in-between.

Robert

[Bill Spinhoven]

Hi Bjorn 

I have used meteor in combination with WebRTC video in a iframe (running as google app)  was really quick to implement and did the job for me.

meteor generated the room ID and layout.

Bill 

 

2014/1/14 Robert Dickert <robert....@gmail.com>

--

You received this message because you are subscribed to the Google Groups "meteor-talk" group.