One way around this is to define a new MIME
Content-Transfer-Encoding: binary-packetized,
something like:
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.
This would have very little overhead compared to
straight binary encoding, and much less overhead than
base64.
Another option is to use the Content-Length: header.
This may place an undue burden on servers when sending
automatically generated binary objects (like WebWorld
does). A binary-packetized encoding would let the
server send the object in pieces as it's being
generated, instead of having to buffer the whole
thing just to count the total number of bytes.
[...]
> The client doesn't close the socket until it sees the
> close on the server's end. It's too bad that TCP is always implemented
> with just one file descriptor. Wouldn't it be useful (in cases like this)
> if the client could close its sending fd w/o closing its receiving fd?
You can do this with the BSD sockets API with
the shutdown(2) call. Don't know about other
implementations though.
--Joe English
jenglish@crl.com