- From: Martin Thomson via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Jan 2018 02:32:03 +0000
- To: public-webrtc-logs@w3.org
Actually, belay that, lack of sleep. I assume that we would only be able to produce a stream of streams if the data channel were ordered. Though perhaps it's OK if there is no requirement for messages to be complete before the next message is delivered. There might be some caveats regarding back pressure in that case though. If A is sent before B, but the first octets of B are delivered first, we would manifest a new message on the top-level stream. But A might be completed prior to completing B. For instance, the stream might deliver B2, B1, A1, A2, A3, B3. B1 and B2 would have to be reordered by the browser for delivery (messages themselves are always ordered internally), but it has no obligation to hold B until A arrives. In an ordered stream, the browser would have to hold all of B until A arrives. (It seems like there's a memory exhaustion attack somewhere in there, but I'm sure our SCTP friends will point out the natural defense that applies.) -- GitHub Notification of comment by martinthomson Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1732#issuecomment-357125784 using your GitHub account
Received on Friday, 12 January 2018 02:32:05 UTC