Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing

From: Takeshi Yoshino <[email-masked]>
Date: Thu, 2 Aug 2012 02:20:17 +0900

On Tue, Jul 31, 2012 at 10:51 PM, Bruce Atherton <[email-masked]>wrote:

>
> On 7/26/2012 4:01 AM, Takeshi Yoshino wrote:
>
>>
>> Separating the stream identifier space into two for each direction is
>> necessary since each end may initiate stream asynchronously. I don't come
>> up with any other attribute with a risk of collision.
>>
>>
> Not with the two protocols currently proposed, but what of the future?
> Will other protocols be carried on this common framing layer? If a peer to
> peer protocol is added then the number of endpoints that could initiate the
> stream is unlimited.
>

I see. But we don't have to use the channel ID space for addressing peers.
It's fine that the client establishes a client-initiated stream with the
destination peer ID, and then the server establishes a server-initiated
stream to the peer and notifies the ID of the origin peer.

The routing table on the server remembers the destination channel ID in
addition to the destination peer. It's not so painful.

>
> Why can there not be a separate field to identify the endpoint that
> initiated the connection?
>
>
>  I feel that reserving ID number space is over killing.
>>
>>
> I'm not sure what you mean by "over killing". Are you agreeing that all
> the bits in the ID space should serve the single purpose of defining the
> ID, and not be overloaded to mean other things as well?
>

Yes. It looks using LSB for direction and the others for ID is sufficient
for me. Protocol differentiation and source peer identification can be done
by exchanging some token on AddChannelRequest rather than reserving
precious bits in channel ID field.