[5629] in www-talk@info.cern.ch
Re: holding connections open: a modest proposal
daemon@ATHENA.MIT.EDU (Joe English)
Thu Sep 15 16:17:47 1994
Date: Thu, 15 Sep 1994 22:07:55 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: jenglish@crl.com
From: Joe English <jenglish@crl.com>
To: Multiple recipients of list <www-talk@www0.cern.ch>
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
