djoehlman

Oh, and if you want to get a picture of what chrome (assuming you are using chrome) is doing in the background use this url:

chrome://webrtc-internals/

Sweet layout - love it. Also while there was no hope of any client being able to decode that amount of video at one time I think it does show that the overheads of a RTCPeerConnection (without media) aren't extreme. My browser here has currently got about 60 peer connection objects open (not sure how many actually connected), but CPU and memory aren't going too crazy...

I think there has been some progress made on implementing BitTorrent like clients using WebRTC data channels:

https://github.com/feross/webtorrent

I haven't done that much investigation myself yet, but I definitely think it's possible. No idea on which will be faster, I imagine it will come down to quantity and quality of peers in both cases...

I agree with that comment, which was one of the reasons rtc.io was created in the first place. A lot of the other libraries hide away the core browser objects through higher-level JS objects, whereas the core rtc.io library (rtc - https://github.com/rtc-io/rtc) encourages direct use of the browser api.

Some of the other modules (rtc-quickconnect, rtc-glue, etc) in the rtc.io suite, however, do take you further away from the metal but if you are comfortable with the core browser APIs then using a combination of rtc-signaller and the connection coupling helper in rtc (https://github.com/rtc-io/rtc/blob/master/couple.js) will probably give the most flexible option for writing a WebRTC application.

Just be aware that there are some bizarre edge cases when working with WebRTC that can leave you scratching your head at times. The rtc/couple module takes care of some, but there are still others that I'm still investigating solutions for, e.g. https://github.com/rtc-io/rtc/issues/14

It does work best with the signaller from the rtc.io suite:

https://github.com/rtc-io/rtc-signaller

That said, it wouldn't take much to write an signalling client that followed the basics of the messaging format if you did want to roll your own:

https://github.com/rtc-io/rtc-signaller#signaller-message-ha...

The client portions are definitely in the library, and as you point out the node-webrtc library is looking really promising for interop with server processes.

If you need any help with the POC that you are currently working on feel free to reach out and I'll see what I can do (I'm the main dev working on rtc.io at the moment). Also, the primary dev on the node-webrtc project (modeswitch) is super helpful so I'm sure he'd be happy to help out also.

Either twitter or github is a good way to get in touch with me - usename is DamonOehlman in both channels...

Thanks to a project that has been previously pointed out (node WebRTC bindings - https://github.com/js-platform/node-webrtc) interop between a browser and node applications isn't too far away.

There is this issue which is being worked on at the moment in the node-webrtc library:

https://github.com/js-platform/node-webrtc

Once that's resolved data channel connectivity between a browser and command-line app, server, etc should be reasonably simple. While this bug is outstanding, it is possible to fall back to Rtp data channels in the browser and if that is something that is of interest then we can look at putting together some examples with rtc.io if that would help you out.