W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: DataChannel: how to know the max size of the sending buffer?

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 7 May 2014 18:22:26 +0200
Message-ID: <CALiegfn6OW2G9wvPgM7-1YOW+5BM0+c6TzRXi8ctBu6YPrjYUQ@mail.gmail.com>
To: tim panton <thp@westhawk.co.uk>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
2014-05-07 18:12 GMT+02:00 tim panton <thp@westhawk.co.uk>:
>> Hi, according to the spec (and this is the same for WebSocket):
>> "if the data cannot be sent, e.g. because it would need to be buffered
>> but the buffer is full, the user agent must abruptly close channel’s
>> underlying data transport with an error.”
> I think the aim here is to preserve the sequence properties that you
> requested on the channel. If a message is irretreivably lost on a reliable ordered delivery
> channel, then (logically) no subsequent message can be
> ever be delivered on it. The app should open a fresh channel with the same
> properties.
> Imagine that the channel is sending state deltas. If you lose or mis-order one
> you really need to start back from a checkpoint. Closing the channel lets the
> far end know that this is happening.

I consider that is more appropriate for TCP (i.e. you cannot parse
incoming data if you loose a single "packet" in the stream). But
DataChannels are message-boundary (SCTP on top of... lot of layers) so
I don't think that closing the socket is a good approach for every use

For example, I want to send my cursor position in real-time. It does
not matter that some packets are lost, and I do know that every
received packet will be useful, even if some others have been lost.

IMHO is fair enough with raising an exception and let the application
decide whether *its* use case requires reseting the connection or not.

>> OK, I can check the current buffered data size via
>> socket.bufferedAmount. But, how may I know the buffer value that would
>> cause send() to fail *without* calling send()?
> That’s unknowable. The buffer in question is shared with other users of the SCTP
> association, i.e. other DCs on this peer connection pair, so the others may use
> a chunk when you least expect it.

Good point.

>> If the buffer size is not standardized, shouldn't the API provide a getter?
> I’m not clear that such info actually helps.

Probably not. What I'll do is wait until bufferedAmount is zero before
sending new data.

Thanks a lot.

Iñaki Baz Castillo
Received on Wednesday, 7 May 2014 16:23:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC