Re: Framing and control-frame continuations

A reasonable compromise here would seem to be: let's place limits on
control frame size but allow data frames to be variable with 32-bit
lengths. Done properly, control frames should never be too large. Doing so
ought to encourage developers to keep control-frame overhead at a minimum
while allowing optimization of data flow (honestly, I think allowing 32-bit
length control frames is just asking for trouble by encouraging bad
behavior). This would mean moving type and flags before length.


On Wed, Feb 6, 2013 at 6:30 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote:

> Content-Type: text/plain; charset=ISO-8859-1
> --------
> In message <
> CAP+FsNfTZ56An-g3qa5Xo6+ZH_hBUHFM2shHrn-NmM6VWzS_oQ@mail.gmail.com>
> , Roberto Peon writes:
>
> >In any case, if/when we implement and there are real performance
> >bottlenecks, we can rev the protocol [...]
>
> Yeah, and 640k is enough for everybody, trust us, we've tested this.
>
> Sorry for getting a bit sarcastic here, but I am frankly flabbergast
> here that anybody can even propose a <64kByte framesize for a protocol
> which will not emerge from standardization for another five years
> and which is supposed to last at least 10 years after that.
>
> Just make it 32 bit length, and move on, ok ?
>
> --
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
>
>