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

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>