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

[John Tamplin <[e-mail]>]

On Tue, Apr 24, 2012 at 4:16 AM, Arman Djusupov <[e-mail]> wrote:

> The server might refuse the channel due to reaching the maximum number of
> mux logical channels on the same connection. The issue is not only with the
> cases when the channel is refused but also when the server can't allocate a
> new channel fast, which would force the server to buffer frames of pending
> logical channels until they get accepted in order to read from the wire the
> subsequent frames belonging to already established channels. For this
> reason
> the server needs a way to control a default quota. My suggestion was to let
> the server define the default quota for the logical channel during the
> physical channel handshake rather than hardcoding it into the spec.
>

The problem is that you are using up buffer space in the client to buffer
any frames which might need to be re-sent if the logical connection is not
successful.  So, having the server specify that seems backwards to me.
 Since frames can be nearly arbitrarily large, that means that the client
might have to buffer an arbitrarily large amount of data (even if it
refragments it and sends only part of it, it has to hold onto the rest).

So, the only way I think it makes sense to send data with the connection
are when we know it can't fail or when we pass off responsibility for
buffering the data to the client.  Ie, in a hypothetical API where you can
send data with the open, you explicitly say that data will be dropped if
the connection is not successful, so the code calling WebSocket.open is
responsible for re-sending the data on a later connection attempt.


> As I already mentioned in a previous message, according to the current
> specification (a) the client may send data prior to receiving an
> AddChannelResponse, but (b) it doesn't have any flow control quota until an
> AddChannelResponse with or without quota parameter is received. These two
> obviously contradict each other.


No, there is no conflict - a client is always free to send up to its quota,
and the quota is held to zero until you get a connection.  That means there
are fewer special-cases to consider, both in validating the spec and
implementing it


> PS: I totally agree on the evilness of 'RTT', but there has to be a clean
> way to control the amount of data that the client can send before the
> channel is accepted, preferably not just a hardcoded default quota for all
> clients in all cases.
>

Ok, but who decides, and who bears the buffering cost of that decision?

-- 
John A. Tamplin
Software Engineer (GWT), Google