Re: Proposal for API for Data

On Apr 10, 2012, at 6:42 PM, Timothy B. Terriberry wrote:

> 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.
If a channel is not in OPEN, I would expect a send() call to fail. However, its return type
is void. Why? Or is it intended that the onerror callback is invoked?
> 
>>>  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.
Not sure why we need to provide reasons (no matter if it is a number or a string)...
> 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.
Yes, we would need to draft-jesup-rtcweb-data-protocol...
> 
> 
>>>  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.
Again, why can't send return a value indicating success or failure. Or is it intended that the onerror
callback is invoked indicating the the message is too big.
> 
>

Received on Thursday, 12 April 2012 09:06:57 UTC