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

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

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

But anything you send after the failure is by definition out of sequence, 
since there is a hole.
 
There is no way the stack can know that you don’t really care about the 
order when you created an ordered reliable channel.

What’s more there is no way the far end javascript can know that there is a hole, since
it didn’t get that data. 

T.


> 
> -- 
> Iñaki Baz Castillo
> <ibc@aliax.net>
>

Received on Wednesday, 7 May 2014 20:37:35 UTC