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