W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2012

Re: Data API Proposal aligned to WebSocket

From: Michael Tuexen <tuexen@fh-muenster.de>
Date: Thu, 23 Feb 2012 22:44:24 +0100
Cc: Randell Jesup <randell-ietf@jesup.org>, public-webrtc@w3.org, Salvatore Loreto <salvatore.loreto@ericsson.com>
Message-Id: <26E1A38A-EDE8-4A63-A93C-3A391CCC3DAB@fh-muenster.de>
To: Randall Stewart <rrs@lakerest.net>
On Feb 23, 2012, at 10:09 PM, Randall Stewart wrote:

> 
> On Feb 23, 2012, at 3:35 PM, Michael Tuexen wrote:
> 
>> On Feb 23, 2012, at 3:44 PM, Randell Jesup wrote:
>> 
>>> On 2/23/2012 8:27 AM, Adam Bergkvist wrote:
>>>> On 02/23/2012 02:08 PM, Michael Tuexen wrote:
>>>>> 
>>>>> On Feb 23, 2012, at 1:39 PM, Adam Bergkvist wrote:
>>>>>> You're right that it's not used in either of the examples given here.
>>>>>> It's a pure API-related property to help the developer identify a
>>>>>> particular DataChannel object if several objects (with the same
>>>>>> transport porperties) are used. E.g. you might have a DataChannel
>>>>>> object with label "chat" and another with the label "game-data" for
>>>>>> different purposes.
>>>>> OK. So if I understand this correctly, it is just a local thing and it
>>>>> is not expected to be on the wire, right?
>>>> 
>>>> Yes, it's not intended to be some "channel id" on the wire, but
>>>> it would have to be transported to the other end so that the
>>>> corresponding DataChannel object on the B-side can be initialized with
>>>> the same label.
>>> 
>>> 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.
> 
> Michael: I mentioned this to Randell as well.. I was thinking they can
>         register a couple of id's and thats all they would need….
OK, great!
> 
> 
>> 
>> 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...
>> 
>> I also assume that you want to map channels to streams, but you can map multiple channels
>> to one stream, right?
>> 
>> 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 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…
> 
> Or it could be DOMStringOpen … 
I think with open a channel and can transfer all of the three over a channel. So it is
not a property of the channel, but of the message. There are three send calls:
   void send(DOMString data);
   void send(ArrayBuffer data);
   void send(Blob data);
as far as I understand the stuff right now...

Best regards
Michael
> 
> R
> 
> 
>>> 
>>>> 
>>>>>>> What about unordered? When do you expect a message to be abondoned
>>>>>>> when treated unreliable?
>>>>>> 
>>>>>> I don't really have an opinion on when to abandon messages in
>>>>>> unreliable mode.
>>>>> OK. But it needs to be specified.
>>> 
>>> 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.
>> 
>> Best regards
>> Michael
>>> 
>>> -- 
>>> Randell Jesup
>>> randell-ietf@jesup.org
>>> 
>> 
>> 
> 
> ------------------------------
> Randall Stewart
> 803-317-4952 (cell)
> 
> 
Received on Friday, 24 February 2012 13:31:03 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:27 UTC