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 20:58:49 +0200
Message-ID: <CALiegf=1G8=-pwFGm8WY5iQpykDomskWX8JyUn761WAo6vZc_g@mail.gmail.com>
To: tim panton <thp@westhawk.co.uk>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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?



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






-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Wednesday, 7 May 2014 18:59:39 UTC

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