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

2014-05-07 18:12 GMT+02:00 tim panton <thp@westhawk.co.uk>:
>> Hi, according to the spec (and this is the same for WebSocket):
>>
>> "if the data cannot be sent, e.g. because it would need to be buffered
>> but the buffer is full, the user agent must abruptly close channel’s
>> underlying data transport with an error.”
>
> I think the aim here is to preserve the sequence properties that you
> requested on the channel. If a message is irretreivably lost on a reliable ordered delivery
> channel, then (logically) no subsequent message can be
> ever be delivered on it. The app should open a fresh channel with the same
> properties.
>
> Imagine that the channel is sending state deltas. If you lose or mis-order one
> you really need to start back from a checkpoint. Closing the channel lets the
> far end know that this is happening.

I consider that is more appropriate for TCP (i.e. you cannot parse
incoming data if you loose a single "packet" in the stream). But
DataChannels are message-boundary (SCTP on top of... lot of layers) so
I don't think that closing the socket is a good approach for every use
cases.

For example, I want to send my cursor position in real-time. It does
not matter that some packets are lost, and I do know that every
received packet will be useful, even if some others have been lost.

IMHO is fair enough with raising an exception and let the application
decide whether *its* use case requires reseting the connection or not.



>> OK, I can check the current buffered data size via
>> socket.bufferedAmount. But, how may I know the buffer value that would
>> cause send() to fail *without* calling send()?
>
> That’s unknowable. The buffer in question is shared with other users of the SCTP
> association, i.e. other DCs on this peer connection pair, so the others may use
> a chunk when you least expect it.

Good point.


>> If the buffer size is not standardized, shouldn't the API provide a getter?
>
> I’m not clear that such info actually helps.

Probably not. What I'll do is wait until bufferedAmount is zero before
sending new data.


Thanks a lot.


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

Received on Wednesday, 7 May 2014 16:23:15 UTC