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 18:47:11 +0200
Message-ID: <CALiegfk2xeGOpSiwFjri0oRFjdUNn4Jar3DUfp+C2v0Y5dN1Qw@mail.gmail.com>
To: tim panton <thp@westhawk.co.uk>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
2014-05-07 18:39 GMT+02:00 tim panton <thp@westhawk.co.uk>:
> 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
> as the possible behaviours on a rtcweb SCTP stream.


var dcOptions = {
  ordered: false,
  negotiated: true,
  id: "XXXX",
  maxRetransmitTime: NNNN

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

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

Note that DataChannel settings may be negotiated in-band within the
DataChannel "Handshake" or "Connect" (I don't remember now) packet.

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

If it is set to RELIABLE I agree :)

Iñaki Baz Castillo
Received on Wednesday, 7 May 2014 16:47:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:58 UTC