Re: Data API Proposal aligned to WebSocket

On 2/24/2012 5:48 AM, Adam Bergkvist wrote:
> On 02/23/2012 11:18 PM, Randell Jesup wrote:
>> On 2/23/2012 3:35 PM, Michael Tuexen wrote:
>>> 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).
>>
>
> Some thoughts about collision on names (label in the API):
>
> I think the approach with "connecting" two independently created 
> DataChannels (with the same label) is a bit tricky. What would be the 
> difference between calling createDataChannel("id") on both sides 1 
> second apart compared to 1 minute apart? Would the objects be 
> "connected" in the 1-second case but two separate endpoints in the 
> 1-minute case (or would it fail)? Would this be a documented feature 
> of the API?

On label collision (assuming you don't have multiple channels with the 
same label):

a) no glare (common case):  there's already a dataChannel object of that 
label.  Simplest would be to fail it with a specific error.You could 
also return a reference to the current object, but that could be 
confusing to the application and lead to usage errors.  Note that since 
data is delivered via a callback, it would get delivered to once, though 
the second version may overwrite the function from the first instance 
(one hopes they would be the same).

b) glare: 'a' implies that we should return an error for one of them, 
but on the other hand there's no chance of the problem in 'a' (one side 
thinking there are two separate data channels).  So unless there's an 
implicit directionality to the channel in the application logic, there's 
no obvious problem.  However, we can't know if the application assumes 
directionality (i.e. the logic in some way depends on whether it was 
created as ondatachannel).  Since directionality is actually probably 
common, it's probably best to fail one of them.  So I'll reverse my 
opinion on further reflection, and suggest failing the label glare case 
on one side (side determined in some manner via the protocol).  Note 
that in very rare cases this may delay channel open and complicates the 
implementation.

Note that all of this goes away (and most, though not all, failure 
handling) if we're unidirectional.  :-)

As you mention, if you allow multiple channels with the same label, then 
the label glare case goes away.  You don't *have* to require in-order 
creation; you'd merely need to state that ordering of creates from side 
1 doesn't have to match the ordering on the receive side (and that's 
only to deal with the case of creating two channels with the same label 
from the same side at virtually the same time - extreme edge case).  I 
think I prefer this solution, and it leads to a simpler wire protocol 
and implementation.  In some rare-ish cases, applications might need 
additional logic, but few would need it.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Friday, 24 February 2012 14:02:11 UTC