Re: [hybi] Multiplexing: Pre-AddChannelResponse quota

[Jamie Lokier <[e-mail]>]

Takeshi Yoshino wrote:
>    Without the server assigning some identifier for the new slot (doesn't
>    need to be the channel ID to be used after channel open, but some
>    identifier), we cannot match the slot and the pre-handshake FC frames.
>    Sorry but could you elaborate your idea? Maybe, you said here that
>    we'll be able to send FC after receiving AddChannelRequest and before
>    sending back AddChannelResponse?
>    What I had in my mind is like this:
>    (C) receives Physical channel server's opening handshake
>    (C) receives NewChannelSlot[ID=1]
>    (C) receives NewChannelSlot[ID=2]
>    (C) receives NewChannelSlot[ID=3]
>    Now (C) can issue three AddChannelRequests but may not send any
>    pre-handshake data.

Why not just send NewChannelSlots[ADD=3], instead of 3
NewChannelSlot messages?

The slot messages are wasteful if the server is happy to accept 1000
low-usage slots from the beginning.

>    (C) receives FlowControl[ID=1, quota=1024]
>    (C) receives FlowControl[ID=2, quota=1024]
>    (C) receives FlowControl[ID=3, quota=1024]
>    Now (C) is allowed to send pre-handshake data up to 1024 for each of
>    allocated slots.

Why not just send NewChannelSlots[ADD=3,PER_CHANNEL_QUOTA=1024]?

(Or SHARED_QUOTA, whatever seems to work best.)

>    Here, the client attempts to open a new logical channel using the first
>    allocated slot.
>    (C) sends AddChannelRequest[ID=1]

Replace with:

    (C) sends AddChannelRequest[CLIENT_ASSIGNED_ID=1]

(where the ID is whatever the client says it should be - or it might
follow some rule such as incrementing from 1 each new one).

>    (C) sends TextData[len=512]

Yes.  The channel data quota on the client is now 512.

>    (C) receives AddChannelResponse[ID=1, success]

Yes.  But the ID is what the client assigned.  The server can also
send response data immediately after this, if it has some very
quickly.

>    (C) receives NewChannelSlot[ID=4]

Replace with:

    (C) receives NewChannelSlots[ADD=1,PER_CHANNEL_QUOTA=1024].

(Or it can be a flag in the AddChannelResponse parameters in the
common case where it's COUNT=1 and the data quotas haven't changed,
but that's just a special case to compress a message.)

This is the same method as flow control for bytes in a channel, but
for new channel counts.  Send out messages granting more room.

>    (C) receives FlowControl[ID=1, quota=1024]
>    Now channel 1 is open and its quota  is 1536.

Yes.

So the main differences between your and my scheme here is:

  - the client assigns IDs
  - the server sends one count update, not a message for each slot

In both schemes, new channel assignment is "pessimistic" in the sense
that channel requests can't block the socket or get rejected at the
mux level.

If it turns out to that network scaling behaviour improves with
"optimistic" requests that can fail and be retried, it can be built on
top of this in various ways, such as NewChannelSlotsAck for when slots
are reduced (negative ADD, round trip before server is allowed to
block) or AddChannelDropped (client must retry, here or elsewhere, and
it's guaranteed the server did not act on the data sent; allows server
to remove quota immediately instead of round-trip).  However TCP works
fine without this sort of "quota retraction", using gradually
increasing window if needed to share memory, so I don't know that it's
useful and I would bet on low-quality clients reacting buggily to it.

-- Jamie