sending a file through sockets

[Bryan Olson]

Donn Cave wrote:
 > Quoth Bryan Olson:

 > If you feel the standard distribution's modules are really bad, then
 > maybe it would make sense to address that.

I've looked into it.  Right now I don't have facilities to test on most
of the supported platforms.

 > They certainly ought to
 > be much more robust than the present example needed to be, since it
 > really was more introductory.  What perhaps is really harder than it
 > looks, is deciding "how much is enough".  Part of my job is to decide
 > how robust an application needs to be, and while it may be good to
 > err on the side of safety, that doesn't excuse me from making the call.

For an internet application, it turns out to be more than most people
think.  It's a rough network out there.

[...]
 > The signal issue with httplib.py is another matter.  It isn't so much
 > about sockets, as C stdio via file objects.  I wouldn't have written
 > it that way myself, because of liabilities like this.  recv(2) will
 > return EINTR, and socketobject.recv() will accordingly raise an 
exception,
 > so there is no ambiguity.  fileobject.read() ignores the error.  The
 > example used recv(), so it didn't put its foot in that hole to start 
with.
 > But that's another trade-off - the authors of those modules apparently
 > felt that the simplicity of a file object solution was worth the lossage.

I have to disagree.  The trouble with signals is their global-ness.  The
modules don't handle the exception on EINTR.  One module using an alarm
can break others.  On the other side, the sockets module (on some
platforms) calls signal to ignore SIGPIPE.  That could come as a
surprise to other modules or users, and it's possible someone else might
set it back.


 > | I gathered that you had in mind a kind of any-old-way of ending.  Clean
 > | close of a TCP connection is a deliberate act, and the method you named
 > | doesn't do it.
 >
 > Let's review what I said:
 >   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."  A byte count
 >   prefix usually is needed, and in the rare case when it isn't,
 >   it doesn't cost much to do it anyway.
 >
 > "Appliance" means, to me, popcorn popper, steam iron, whatever you
 > like.  It's an analogy.

Yes, and a TPC's graceful close is analogous to an off-switch, not a cut
cord.

 > I would send a byte count.

I welcome you to send a byte count.  I didn't even say it was bad
advice; just that it's not really needed, and since the protocol
didn't check it, we might as well take it out.  To me, this one looked
like a job for HTTP/0.9.

For a flexible protocol I would not recommend sending a single byte
count as a prefix, because in many cases the sender doesn't know how
much data he'll be transmitting. It's a huge pain to have to buffer the
entire transmission to see how big it is. So we'd want a chunked
representations, or a maybe a second control connection.


--Bryan