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

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

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

In SCTP you can say what sort of behaviour you want, the default in webRTC is
sequenced reliable - i.e. TCP but with message boundaries. 
If you don’t care about the sequence (or the reliability) you need to set a different 
SCTP mode on the stream.

The draft-ietf-rtcweb-data-protocol-03.txt offers you 
    RELIABLE
    PARTIAL_RELIABLE_REXMIT
    PARTIAL_RELIABLE_REXMIT_UNORDERED 
    PARTIAL_RELIABLE_TIMED 
    PARTIAL_RELIABLE_TIMED_UNORDERED  
    RELIABLE_UNORDERED 
as the possible behaviours on a rtcweb SCTP stream.


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

So you need to set one of the Partial Reliable unordered options
(where failure is either determined by the number of retries or the time
retrying)

I don’t know how/if this behaviour is surfaced to the API - but no doubt there is a jot or iota
on the m=application DTLS line that indicates it.


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

Agreed, but it is also fair to close the channel if it failed to meet the requested criterion.

Tim.

>

Received on Wednesday, 7 May 2014 16:40:08 UTC