Re: Proposal for API for Data

On 4/10/2012 12: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),

It's actually the amount of data that has not been ACKed at the 
WebSocket protocol level by the other side, so it does give an idea of 
how badly you've overrun the connection.  Basically it's sent_data - 
acked_data.

> 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).

We don't ack messages at the user protocol level; our definition had 
been planned to be a measure of the amount of data queued for 
transmission by the stack (depending on what the stack makes easy to 
get).  We hadn't put a precise definition on it yet.

> 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.

Sure; I should also note that while we're extending WebSockets (in this 
discussion), we can override or extend certain behaviors if we decide to 
(though if we choose the wrong thing we could break the ability for 
applications to treat us like a WebSocket.

>>> 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.

Correct, though we could define that we basically ignore codes/reasons 
and just provide a generic on at the other end.  Or add a close message 
sent reliably before reset to provide them.  If we decide to extend 
WebSocket this is doable.

>>> 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.

Or you define that a send() is never too large for the "current buffer" 
in WebRTC.

BTW, the current WebSockets impl in Firefox appears to return 
ERROR_FILE_TOO_BIG, but nothing more.  (However, that's just from code 
inspection.)


-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 10 April 2012 19:26:26 UTC