- From: Nicholas Wilson <nicholas@nicholaswilson.me.uk>
- Date: Wed, 26 Mar 2014 13:18:58 +0000
- To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Cc: public-webrtc@w3.org
On 26 March 2014 09:17, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote: > Could you explain how you can the underlying SCTP channel supports > backpressure per stream? SCTP supports a flow control which affects > all streams, but not a flowcontrol per stream. Oh dear - you're quite right! I hadn't looked at the code yet for the case of multiple data channels. The fact that each DataChannel runs over a single SCTP connection is a real nuisance then. Let's imagine a complex app: someone's bound to implement a torrent-like protocol on top of WebRTC at some point, which would require several channels between peers. It's perfectly possible for an app to want to block reading from one of the channels, eg the user needs to select a download directory, or the application wants to show a warning or security prompt before continuing to read from the channel. We'd want to be able to continue to process data in the background from the other channels though. > It does not only have an ideal external interface, SCTP doesn't > provide a flowcontrol per stream. Not ready data on one stream > would affect the other streams... >From my point of view then, the problem is using SCTP streams for the data channels, rather than opening a new SCTP association for each channel. We have every single port number available (because the port numbers used to distinguish SCTP connections are encapsulated, private to the WebRTC protocol). What was the reasoning for using streams - simply to avoid the SCTP handshake? The port number can apparently be selected currently using a "data codec", some sort of a pseudo-codec with a port number property. I don't know if Chrome/Firefox use that? The SCTP port numbers are essentially unused, so I think it would be preferable just to make a new SCTP connection per channel, with the SCTP port set to `5001+$ssrc` (say). Then it would still be possible to change the base port to 6001 if the protocol gets bumped up. This would be a breaking change only to applications using more than one data channel. Regards, Nicholas ----- Nicholas Wilson: nicholas@nicholaswilson.me.uk Site and blog: www.nicholaswilson.me.uk
Received on Wednesday, 26 March 2014 13:19:26 UTC