Re: Proposal for API for Data

Cullen Jennings wrote:
> Of the above, it seems like we need pretty much all of them with the same
 > semantics as websocksts. Are there some of these you think we don't need?

What do you think the semantics of bufferedAmount should be? As defined 
right now for WebSockets, it indicates the amount of UTF-8 text or 
binary data queued by send() but "as of the last time the event loop 
started executing a task, had not been transmitted to the network". The 
WebSockets spec also says, "This does not include framing overhead 
incurred by the protocol, or buffering done by the operating system or 
network hardware." The latter seems to imply that data is removed from 
bufferedAmount when write() is called on the socket (even though this 
makes it basically useless for the kinds of pacing examples given in the 
WebSockets spec), but our SCTP stack will exist entirely in userspace, 
so is not technically "buffering done by the operating system". So does 
it get removed from the buffer when we hand it over to libsctp, or when 
it actually gets transmitted over the UDP socket (which of course could 
happen multiple times in the case of reliable messages).

The other interesting property of this attribute is that this value must 
continue to increase if you keep calling send() on a stream after it has 
been closed. I don't think that's actually a problem, but was something 
I wouldn't have found obvious.

>>   void close([Clamp] optional unsigned short code, optional DOMString reason);
>
> Seems like we will end up with a close one way or another

Agree, but there are some details here that are important.
http://www.ietf.org/id/draft-jesup-rtcweb-data-protocol-00.txt currently 
defines stream closes using an SCTP Stream Sequence Number Reset, which 
doesn't have any mechanism for transmitting a status code or a text 
reason (see http://tools.ietf.org/html/rfc6525#section-4.1 for the 
message format). In particular, the status codes are not all arbitrary, 
application-defined things, but have specific definitions according to 
the WebSockets protocol: http://tools.ietf.org/html/rfc6455#section-7.4 
(and there are additional constraints placed on status codes that can be 
passed in to the API: for example, the JS can't tell the UA to end a 
connection with status 1002 "terminating the connection due to a 
protocol error"). So if we want this particular close() API, then we 
have some more protocol work to do.

>>   void send(DOMString data);
>>   void send(ArrayBuffer data);
>>   void send(Blob data);
>
> Again seems like we will choose to have all of theses.

One of the fun semantics of send() is that if the message is too large 
for the current buffer, the UA must _close_ the WebSocket connection 
(with prejudice, which means an a simple event named "error" is fired by 
the WebSocket object). Even if we agree that's a reasonable behavior for 
an unreliable data channel, there's some questions here: does it close 
just this stream, the entire SCTP association, the whole PeerConnection? 
For each one of those things, there's a different set of behaviors 
(events and/or callbacks) that you'll want.

Received on Tuesday, 10 April 2012 16:43:07 UTC