Subject: [hybi] Multiplexing (suggesting sequence number in each frame)

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:06:30 +0200

Hi, I recognize that I don't know what the purpose of the MUX
extension is (a Google extension?). But I suppose it intends to allow
sending frames (fragments) of different WS messages at the same time.

It could be easily achieved if each frame contains message sequence
number or just a message identificator (a random integer). So a client
could send frames belonging to different messages in parallel:

- frame 1:     message_id = 123,  FIN=0,  opcode=1
- frame 2:     message_id = 961,  FIN=0,  opcode=1
- frame 3:     message_id = 123,  FIN=0,  opcode=0
- frame 4:     message_id = 123,  FIN=0,  opcode=0
- frame 5:     message_id = 961,  FIN=0,  opcode=0
- frame 6:     message_id = 123,  FIN=1,  opcode=0
- frame 7:     message_id = 961,  FIN=1,  opcode=0

Doesn't it seem easy?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:09:48 +0200

> - frame 7:     message_id = 961,  FIN=1,  opcode=0

By adding such simple "msg_id" to each frame, the following point in
the draft-10 could be removed:

   o  The fragments of one message MUST NOT be interleaved between the
      fragments of another message unless an extension has been
      negotiated that can interpret the interleaving.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:11:11 +0200

>      negotiated that can interpret the interleaving.

And next one (as it would be implicit):

   o  An endpoint MUST be capable of handling control frames in the
      middle of a fragmented message.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:20:10 +0200

>      middle of a fragmented message.

The current spec is a hack:

   _Note: if control frames could not be interjected, the latency of a
   ping, for example, would be very long if behind a large message.
   Hence, the requirement of handling control frames in the middle of a
   fragmented message._

And the very same could occur in the following example:

XMPP over WebSocket.:
- A contact sends me a very big file (various MBs) which becomes a MS
message splitted in N frames.
- It takes 3 minutes to arrive the full file.
- During those 3 minutes I cannot receive presence/status updates for
other contacts in my buddylist. Ugly design, period.

Add a msg_id to frame binary format and problem solved, without
extensions, just as easy as a single identificator field (like in many
other protocols).

In HTTP there is no such "id" field to correlate responses and
requests, so parallesims/pipeline is a ugly hack (just valid for some
specific cases and with heavy constrains). Don't learn just from HTTP
please. Check SIP protocol in which the same TCP connection can hold
different transactions (request+responses) by using a "branch" field
for mathing responses and the requests they belong to.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:37:59 +0200

>   Hence, the requirement of handling control frames in the middle of a

Another hack in the spec:

   If an endpoint receives a Ping frame and has not yet sent Pong
   frame(s) in response to previous Ping frame(s), the endpoint MAY
   elect to send a Pong frame for only the most recently processed Ping
   frame.

It does not make sense. The endpoint cannot decide "which Ping to
reply" as the Pong frame has no way to identify which Ping belongs to.
So basically the endpoint can just decide whether sending two Pong or
just one. In the last case, the remote endpoint will never know which
Ping the received Pong belongs to.

NOTE: *Again* using a msg_id in the frame would solve this issue by
mandating that a Pong frame MUST mirror the same msg_id than the Ping
it's replying to. Easy.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 16 Aug 2011 10:20:51 +1000

Inaki,

a message ID would certainly allow message fragments to be interleaved
and then disentangled.
However, it would not support another important aspect of MUX, namely
routing the different messages to different endpoints.

regards

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 16 Aug 2011 02:23:11 +0200

> routing the different messages to different endpoints.

Ok, but which of those features should be part of the core protocol
and which want an extension?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 16 Aug 2011 10:26:54 +1000

> and which want an extension?

Currently it is proposed that both message interleaving and virtual
channels will be supported in an extension.
While there is significant support for MUX to be in the base protocol,
I think it is more productive to get on with a design (in an
extension) and wide spread implementations.

cheers