Re: Minimizing the protocol (Re: Data API)

On 2/28/2012 10:49 AM, Harald Alvestrand wrote:
> Random thought on trying to get away without defining a setup
> protocol..... what if:
>
> - the existence of the data connection is negotiated in the SDP, not its
> channels.

Ok.

> - channels have labels only on the *creator* side - on the recipient
> side, they get a "label" identical to the channel number. Numeric labels
> on the creator side are forbidden. Result: Label glare is impossible.

The problem is that the point of the label was to indicate to the 
recipient what this dataChannel object was for.  There are two obvious 
ways to do this: use channel numbers defined by the application (which 
is typically how SCTP application protocols work), or use labels defined 
by the application.  With this setup, the recipient gets a "random" 
channel number without any meaning, and the initiator uses a label that 
doesn't actually help them in any way.

> - SDP initial offerer gets to create all the odd numbered channels,
> initial answerer gets to create all the even numbered ones. Result:
> Channel number glare is impossible.

Yes, I was thinking along those lines for the wire-level description for 
handling bidirectional dataChannels (see earlier threads).

> - at creation time, the creator sends a zero-byte datagram through the
> channel, with the reliability and retry properties he wants for all
> datagrams on that channel. This results in the "open" signal on the
> other side, and locks in those properties on the return channel (same
> channel number).

Except that I'm not sure you can "read" those properties from the 0-byte 
datagram, especially if you want to allow for partial reliability.

>
> No setup protocol needed....?

If we go back to numbered channels (i.e. put it in the application's 
domain), we have to deal with number glare if we want bidirectional 
channels (return channel_already_opened or some such - not a big deal). 
  But I think JS programmers prefer labels to application-specified numbers.

Sorry.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 28 February 2012 17:38:24 UTC