- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Wed, 7 May 2014 18:47:11 +0200
- 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 > 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. Sure, in fact I use PARTIAL_RELIABLE_REXMIT_UNORDERED: 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 <ibc@aliax.net>
Received on Wednesday, 7 May 2014 16:47:57 UTC