Re: Data API Proposal aligned to WebSocket

On 2/24/12 12:18 AM, Randell Jesup wrote:
> On 2/23/2012 3:35 PM, Michael Tuexen wrote:
>> On Feb 23, 2012, at 3:44 PM, Randell Jesup wrote:
>>
>>> Correct; the idea discussed (at the Interim, and with Randall) was to
>>> either use stream 0 as a control channel, or to use PPID values to
>>> flag a message on a stream containing metadata such as an "open
>>> dataChannel" message, which would include information needed to open
>>> the reverse stream (and avoid 'glare' when both sides are opening
>>> streams at the same time), the label, and the channel options (so it
>>> has the same attributes in both directions).
>> I almost always agree with Randy, but we have a different perspective when it comes the the PPID.
>> Currently upper layers of SCTP register some values at IANA and this value is used, for example,
>> by protocol analyzers like Wireshark to determine the upper layer protocol. If possible,
>> I would like to keep it that way.
> We discussed registering a value or values with IANA for this.

if we are not going to use stream 0 as control channel,
are we going to use it for anything "special" or we will use it as all 
the others?


>
>> So you want that one side creates a channel with an identifier which is a string. This is
>> transported to the other side. Right?
>> What should happen if both sides try to open a channel with the same identifier? Should
>> this result in one channel?
>> It seems that we need to messages which are exchanged...
> Right; this is a variation of the 'glare' case.  (Two types of glare
> here: collision on names, and collision on stream IDs selected.)  For
> "name glare", I'd just mark both sides as open and ready.  You could
> also fail one of them (requires a message back indicating failure due to
> collision) and then give an ondatachannel message saying the other side
> created it, but then you have to decide somehow how to chose which one
> "wins".  Easily doable, but gains you nothing over just telling both
> sides it's open (one place bidirectional helps you).
>
>> I also assume that you want to map channels to streams, but you can map multiple channels
>> to one stream, right?
> Actually, I was going to map each channel to a stream in each direction
> (though they don't have to have the same stream number - again an
> artifact of glare).  So once established, there's a 1-1-1 relationship
> of incoming stream, outgoing stream and data channel object, with no
> sharing.
>
>> It looks like we need some rtcweb control message for opening and closing a channel. These
>> would transfer the channel identifier.
>> One would use a separate PPID for
>> * the control messages
>> * user messages containing a DOMString
>> * user messages containing an ArrayBuffer
>> * user messages containing an Blob
> We can use a PPID for identifying those object types, or we could layer
> that into the binary protocol.  If the PPID space is large (and it is),
> I'm good with defining 4 PPID values, and we would define more if/as
> needed (and register them all with IANA).

perhaps we can reserve with IANA a range of values,
so that we can use for further control/non-control stuff in the future
in WebSocket Protocol Opcodes is a 4 bits field with some room for 
further stuff.

Received on Friday, 24 February 2012 07:04:52 UTC