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

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

From: tim panton <thp@westhawk.co.uk>
Date: Wed, 7 May 2014 17:12:01 +0100
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <95F409D0-1E42-4E05-94ED-3D5C3DC97C35@westhawk.co.uk>
To: Iñaki Baz Castillo <ibc@aliax.net>

On 7 May 2014, at 16:19, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 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 

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.

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

> If the buffer size is not standardized, shouldn't the API provide a getter?

I’m not clear that such info actually helps.


> Thanks a lot.
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>
Received on Wednesday, 7 May 2014 16:12:31 UTC

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