Re: Data API Proposal aligned to WebSocket

On Feb 24, 2012, at 8:04 AM, Salvatore Loreto wrote:

> 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?
Let's decide it once we know the protocol...
> 
> 
>> 
>>> 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.
Since we can hide the mapping from the JS user and we can get PPIDs very easily,
we can reserve them when needed...

Best regards
Michael
> 
>

Received on Friday, 24 February 2012 14:16:24 UTC