sending a file through sockets

[Bryan Olson]

Donn Cave wrote:
 > Quoth Bryan Olson <fakeaddress at nowhere.org>:
 > | brueckd at tbye.com wrote:
 > ...
 > |> but to send the length of the file first so the receiving end
 > |> knows if and when it got the whole thing.
 > |
 > | That's not really needed.  Just  call shutdown(1) when finished 
writing.
 > | The receiver can detect the end when recv() returns zero bytes without
 > | error, which only happens on clean shutdown.  The socket will also
 > | select() as readable just before the zero-byte recv().
 >
 > 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.  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.

[...]
 > | 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).  I'm not
sure what a connect to INADDR_ANY should mean either.

 > | I understand it's a basic demo, but I'll note that any real application
 > | requires some time-out discipline to avoid very long hangs.  Also on
 > | most Unix systems we'd need to watch out for signals that force system
 > | calls to return.
 >
 > 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.  As for signals, there's even
comment in the HTTPlib.py "Note that we cannot distinguish between EOF
and an interrupt when zero bytes have been read."  That's no longer true
according to current sockets library doc, so now that it can be handled
correctly, surely it should be.

 > Does any real application need a timeout discipline?  Some applications
 > probably need one, but "real" or not doesn't sound like a very useful
 > way to think about it.

Real as in the ones that need to be robust enough for production use in
the real world.

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


--Bryan