feross / simple-peer

📡 Simple WebRTC video, voice, and data channels
MIT License
7.36k stars 972 forks source link

support creating multiple data channels #19

Open mafintosh opened 9 years ago

mafintosh commented 9 years ago

Would be cool if simple-peer moved to the multiplex interface since webrtc/datachannels supports multiplexing.

I can help out with this if you want since we need it in dat/friends as well :)

ungoldman commented 9 years ago

:+1: would more easily allow for heartbeats so friends can be aware of other friends in channels

feross commented 9 years ago

Yeah :+1:

I like how Peer is a duplex stream since it makes it easier to use in place of a net.Socket. We could add a createDataStream method to get additional data channels in addition to the default one that gets set up with every simple-peer connection.

Whatever API we go with, we should make sure all the scenarios in the multiplex test suite pass.

kumavis commented 8 years ago

another possible api, though perhaps a little asymmetrical: create a primary data channel by default, and let the peer obj wrap this as a stream (as you do now). have a method to then create additional streams over new data channels.

just a thought.

webglider commented 7 years ago

What's the status of this?

feross commented 7 years ago

@webglider Since the issue is still open, the status is what it looks like. No one has done the work yet.

t-mullen commented 7 years ago

Is renegotiation required for creating datachannels?

webglider commented 7 years ago

@RationalCoding Nope renegotiation is not required i.e onnegotiationneeded will not be called again and it's not necessary to exchange ice candidates and offer/answer again. There is an option called 'negotiated' that can be passed while creating a datachannel. If that's set to false "negotiation" happens inband. This "negotiation" is just to inform the other end about the creation of the DataChannel, and the overhead for that is just one extra message (0.5 RTT) which is pretty much negligible. If 'negotiated' is set to true then both ends would have agreed about the DataChannel out of band and hence there is no overhead at all. (see: https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#section-6)

So, I guess one can ignore for all practical purposes the communication overhead of creating additional DataChannels

t-mullen commented 6 years ago

Here's a proposal for an API to this:

We abstract DataChannels as their own objects wrapping an RTC DataChannel. The Peer remains a duplex stream, but it passes data to one of these DataChannel objects. The peer can have a second DataChannel for renegotiation signalling if opts.inBandSignaling === true .

The API adds addDataChannel({label: '', ... }, cb) that returns a new DataChannel instance in the callback. There's also a new datachannel event that emits these new objects.

DataChannels are duplex streams. They expose the datachannel label to correlate streams on both sides.

rvion commented 6 years ago

some addDataChannel capabilities would be great !

context: I'm developping a fast-paced web multiplayer game with P2P support (where one tab acts as the server), and I really need to have


❓ in the meantime, is there any recommanded way to do so ?

Thanks for great lib by the way.

t-mullen commented 6 years ago

There's no contributor guide or code explanation anywhere, but if you're familiar with the native WebRTC API and read the PRs for any confusing lines, it should be self-descriptive. Me and other contributors would also be happy to answer questions.

Even if you aren't able to get it working, partial "hacky" attempts are still useful for future reference.

t-mullen commented 6 years ago

I've made progress on this, but I'm currently blocked by an electron-webrtc issue.

I'm not sure if electron-webrtc is still maintained (the tests no longer pass), but no multiplexing support on Node would be very disappointing.

nazar-pc commented 6 years ago

I have the same perception about electron-webrtc. In contrast, node-webrtc progresses really well and is almost capable of working with media streams in Node.js.

So I'd focus on node-webrtc for now and not worry about electron-webrtc too much.

disarticulate commented 3 years ago

also interested here. Would be useful to piggyback on other libraries which integrate simple-peer such as https://github.com/yjs/y-webrtc