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 22:21:01 +0200
Message-ID: <CALiegfm_xNjmD+O3fagJ-+OX+ZqgBaa=wC-f+B0P-MxA77-G0w@mail.gmail.com>
To: tim panton <thp@westhawk.co.uk>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
2014-05-07 22:01 GMT+02:00 tim panton <thp@westhawk.co.uk>:
>>> 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.

Yes, sorry, with remote I meant "the remote API" :)


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

Again the same as in TCP:

The fact that write() fails when in non-blocking mode does not mean
that *sent* data may arrive unordered. It just mean that you couldn't
write at that moment.



-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Wednesday, 7 May 2014 20:21:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC