Subject: Re: [hybi] Framing redux

From: "Shelby Moore" <[email-masked]>
Date: Thu, 26 Aug 2010 05:25:32 -0400

Respectfully...

> Similarly I'm having concerns about fragmentation as part of the
> framing. I'm thinking that fragmentation is an attribute of the payload
> and not of the frame itself (ie do we really want fragmented ping
> frames?)

Fragmentation is part of framing layer.  Data size is part of the data
layer.  Please keep it simple and do not conflate and thus complicate the
two.  Here is the simple way to do it:

http://www.ietf.org/mail-archive/web/hybi/current/msg03700.html

Whether a ping will be fragmented is dependent on the maximum frame size
that receivers report they can handle.  It is not something the sender can
control.

The data size should not be in the frame layer at all as explained at
prior link.

I reserve judgement on how extensions are useful and should be
implemented, as I see more discussion on them. Nevertheless, I expect the
above to remain true.

Please do not copy (Cc:) to me on any reply to list. I am unsubscribed.
Thank you.

---

From: "Shelby Moore" <[email-masked]>
Date: Thu, 26 Aug 2010 06:06:01 -0400

> implemented, as I see more discussion on them. Nevertheless, I expect the

Let me clarify that Greg's proposal seems to be consistent with what I
have stated. He puts the data size in the data layer.

My point is there will still need to be a frame size field in the frame
header, and that fragmentation will occur orthogonal to the data layer.

The link I provided in my prior post, explains how that orthogonality can
be handled.

In other words, I am not objecting to Greg's proposal.  I am only
clarifying that fragmentation will occur orthogonally to his proposal.

---

From: "Shelby Moore" <[email-masked]>
Date: Thu, 26 Aug 2010 08:15:08 -0400

> Please do not copy (Cc:) to me on any reply to list. I am unsubscribed.

When I wrote the following post:

http://www.ietf.org/mail-archive/web/hybi/current/msg03694.html

It caused me to ponder why we need framing at all. I have not read the
prior discussions, but I assume it is because we want to send fragments
out-of-order and multiplex.

So I assume one of the extensions will be for a frame unique id and frame
fragment counter that follows each frame header, which enables
multi-plexing and out-of-order fragments (failure re-sends?) respectively.
Without the extenstion, the receiver processes frames in order.

If my assumptions are correct, then Greg is headed in correct direction to
unconflate the data size and the framing.  Then our sendData() function
can input the opcode. And then receiveData() takes a buffer and maximum
size to read. Those can be callbacks so we can support synchronous
multi-plexed transfers. The data sizes get controlled at this data API
layer.  The framing sizes (fragmentation and re-assembly) are controlled
below that in the framing layer, as explained:

http://www.ietf.org/mail-archive/web/hybi/current/msg03694.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03685.html
http://www.ietf.org/mail-archive/web/hybi/current/msg03700.html

The unique id gets handled before the data API, where they are associated
with callbacks.