Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics)

[Takeshi Yoshino <[e-mail]>]

On Wed, Apr 18, 2012 at 21:01, John Tamplin <[e-mail]> wrote:

> On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <[e-mail]>wrote:
>
>> You're right. In the latest spec, it's not explicitly specified what the
>> value of send quota is until AddChannelResponse is received.
>>
>> There're several options we can take.
>>
>> a) specify the fixed value of send quota before AddChannelResponse in the
>> spec
>> b) add a new parameter "pre_handshake_quota" to multiplexing extension to
>> negotiate the value of send quota before AddChannelResponse
>> c) drop the feature to configure initial quota for each logical channel,
>> and redefine the quota parameter as pre-handshake send quota for all
>> logical channels
>>
>
> Until we know the AddChannel was accepted, how can we send data anyway?
>  This seems just like the initial handshake on a new connection -- you
> wouldn't consider sending that data until you knew the connection was
> accepted.  Since we are avoiding TCP setup requirements, this will be much
> less latency than if the connection were created without multiplexing.
>
> I suppose it would be possible to send the data while keeping it buffered
> as an optimization, but since adding a channel should be infrequent
> compared to sending data on it, I don't see it as that important to
> optimize for.
>

Yes. It's infrequent.

If the information the impatient client want to send is small, it can also
be just embeded into URL or subprotocol to avoid the additional RTT.

If no one really needs this feature and has justification, I'm fine with
keeping the same restriction (no transmission until AddChannelResponse) as
no-mux connection.

IIRC, Gabriel was interested in this optimization. Gabriel, do you have any
comment about this?