simple-peer
simple-peer copied to clipboard
support creating multiple data channels
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 :)
:+1: would more easily allow for heartbeats so friends can be aware of other friends in channels
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.
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.
What's the status of this?
@webglider Since the issue is still open, the status is what it looks like. No one has done the work yet.
Is renegotiation required for creating datachannels?
@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
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.
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
- 1 reliable data channel for important events
gameStart
,kickPlayer
, etc. - 1 fast (non reliable) data channel for changes streaming.
❓ in the meantime, is there any recommanded way to do so ?
- should I try to hack something by reading the code and reusing 'private' fields ?
- is there any example or guide somewhere ?
Thanks for great lib by the way.
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.
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.
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.
also interested here. Would be useful to piggyback on other libraries which integrate simple-peer such as https://github.com/yjs/y-webrtc