Re: Minimizing the protocol (Re: Data API)

On 02/28/2012 06:36 PM, Randell Jesup wrote:
> 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.

argh. was fun while it lasted :-)
second suggestion is to have the first message contain the label and 
flags.....

Received on Tuesday, 28 February 2012 21:18:31 UTC