[5588] in www-talk@info.cern.ch
Re: holding connections open: a modest proposal
daemon@ATHENA.MIT.EDU (Joe English)
Wed Sep 14 18:29:44 1994
Date: Thu, 15 Sep 1994 00:20:51 +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>
troth@is.rice.edu (Rick Troth) wrote:
> It's non-trivial to indicate end-of-file without closing the
> TCP connection. This is probably why FTP uses a second TCP connection
> (but I'm not Postel; you'll have to ask him)
>
> MIME is a Good Thing. Multipart/mixed is a Good Thing.
> Given the lack of out-of-band EOF indicators aside from shutting down,
> multipart/mixed with just >one< object may help a bit. The problem
> then becomes keeping the multipart boundary unique or (better) out of band.
> This implies Base64 encoding for too many things.
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
