Re: holding connections open: a modest proposal

Joe English (jenglish@crl.com)
Thu, 15 Sep 1994 21:56:19 +0200

Rick Troth <troth@rice.edu> wrote:
> [lost attribution, sorry]
> > [ I <jenglish@crl.com> wrote: ]
> > > The server sends a binary stream in packets,
> > > each packet prefixed with a 2-byte packet
> > > length in network byte order. Packets can be
> > > any convenient size from 1-65K bytes. The data
> > > stream is terminated by a zero-length packet.
> >
> > ARG! What's with the 2-byte lengths!?
> >
> > Why in the world would you limit packets to 64K?
>
> I don't think he really meant to limit packets to 64K,
> rather, segments (yeah ... that's the word ... yeah "segments").

Yeah; "segment" is a better word than "packet".

I thought a 2-byte segment length was reasonable because
typically a server process is going to use a small (< 64K)
buffer *anyway* as it's sending data over the network -- a
program that reads a 4 megabyte file into memory and writes
it back out with only two system calls is going to have
problems -- and this also provides a reasonable maximum
buffer size for clients to allocate.

> I have reasons that would make me prefer the 2-byte length.
> But the suggestion en-whole (zero length segment terminates, 2-byte
> length, all of it) solves exactly >one< problem. Were we to add
> real structure to the stream, we'd need something more complete.

My first thought was to use a 3 part tag-length-value
encoding for segments/packets, but I couldn't think of any
uses for the tag field.

This scheme is only trying to solve one problem --
how to provide an in-band end-of-message indicator for
multipart MIME messages without "spreading social diseases
like base64 encoding around" :-) What other structure do you
have in mind?

--Joe English

jenglish@crl.com