sending a file through sockets

[brueckd at tbye.com]

On Fri, 5 Jul 2002, Bryan Olson wrote:

>  > Fine if the file is all you're sending, but it's like "who needs
>  > an on-off switch on this appliance, when you can just cut the
>  > power cord with a pair of insulated wire cutters."
> 
> No, cutting the cord will not do the same thing.  You only get the zero-
> byte successful read on graceful shutdown.

Actually, you get 0-byte successful read when you simply call close() too. 
Try it. Also note that the socket object destructor calls close(), so 
those sockets also get closed cleanly. Finally, I just tried killing the 
server process and the client side immediately came back with a 0-byte 
successful read.

> That is in fact how HTTP 0.9
> handles the end of response, and one of the options in HTTP 1.0 and FTP
> data connections.

...and is not small source of errors in HTTP agents, and is also why 
HTTP 1.1 discourages this method. It's especially annoying to deal with 
if you're writing web proxies and caches and the origin server is using 
closed sockets to mean end-of-transmission.

> 
> [...]
>  > | Did you test this?  The Python library uses the empty string for
>  > | INADDR_ANY, which is fine for bind(), but I don't think it's legal for
>  > | connect().
>  >
>  > So, did you test it?  I did!  According to my results, he's right,
>  > you're wrong.
> 
> Yes, the connect() fails on my system (Win 2000, Python 2.2).
                                         ^^^^^^^^
Ahh... there's the problem. ;-)    ------'
Works on Unices..

>  > We would?  I never have, and I don't notice the standard library
>  > modules doing that.  It might something to think about, but hardly
>  > the given it would be in C.
> 
> You just wing-it and hope for the best?  The Python "standard library
> modules" for network protocols are not so good.  The need for timeouts
> has come up many times in this group.

FWIW, latest CVS version of sockets has timeout support. Yay!

> Try your pull-the-plug idea on the Python network protocol libraries.
> Most TCP stacks will detect the dead connection in about two hours.

Again, a call to shutdown is not needed to get the 0-byte successful recv
call. The other side detects it immediately, for other problems you tend
to get a socket.error exception. What you _do_ need timeouts for is when
you are reading data from a buggy sender that puts your connection on a
shelf and then forgets about it, i.e. the connection is still open and
ready for use but the sender side simply fails to send anything.

-Dave