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 21:01:30 +0100
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <4B663C53-82D9-47B8-9FC4-C0A28C240EEF@westhawk.co.uk>
To: Iñaki Baz Castillo <ibc@aliax.net>

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

> 2014-05-07 19:06 GMT+02:00 tim panton <thp@westhawk.co.uk>:
>>> The point here is not about reliability but about message-boundary. In
>>> TCP you must really close the socket is data is lost. That is not true
>>> (not for all the use-cases) in DataChannel since you always receive a
>>> complete message (may be you have lost some messages or they are not
>>> ordered, but what you receive is always a full message).
>> Ok, so this is unreliabledc.send(myBigBlob);
>> where myBigBlob is probably bigger than the buffer on my IoT device?
> OK, I assume that myBigBlob will *entirely* arrive to the remote
> within a single STCP message (so in will be the event.data of the
> onmessage event) or it won't arrive at all. But it will never happen
> that just a fragment of myBigBlob arrives to the remote. Am I wrong?

The fragments may get delivered to the SCTP stack, but it shouldn’t present it 
to the API until the whole thing arrives.

>> That is knowable. This end knows how much buffer the far end said it still had free.
>> Throwing an error is reasonable. If the channel is reliable closing the channel is
>> the right thing to do.
> I don't entirely agree. If you get an exception (and assuming the
> socket is not closed) you can still send the data later. Different
> concepts here. A TCP non-blocking write() call can fail and that does
> not mean that the connection should be closed (instead it means that
> you must wait for the socket to become writeable, so same here).

My view is, if you said it is an ordered channel, then that is what it is, 
no holes.

Received on Wednesday, 7 May 2014 20:02:00 UTC

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