Re: Data API Proposal aligned to WebSocket

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.

> 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).

> We need to make sure that messages sent on a channel don't arrive earlier than the open message...
> and that the close messages are the last one...

Yes, I was going to specify "reliable in-order" for those.  Also, 
Randall and I were talking about resetting a stream to indicate a close 
(though that opens a question about in-flight messages versus the 
reset).  If we were unidirectional and didn't use labels (just stream 
IDs), we could probably use reset for indicating channel open, but I 
think there's enough consensus to ignore that.

>> Right.  I was trying to indicate in my response that streams would (at open time) have attributes that specify reliable, unreliable, in/out of order, and for non-reliable a value to control retry/abandonment (exact semantics TBD but should map simply to the SCTP options).  I mistakenly added them to the wrong dictionary.
> I could imagine that for some applications want to limit the number of retransmissions (most likely to 0)
> or want to limit the lifetime of the message. Both it supported by our userland stack.

Exactly, but my suggestion was (for now) to limit those to be a channel 
attribute, instead of per-user-message.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Thursday, 23 February 2012 22:20:29 UTC