sending a file through sockets

[Donn Cave]

Quoth Bryan Olson <fakeaddress at nowhere.org>:
...
| I was deliberately pointing out that sockets programming is harder than
| it looks.  A novice cannot tell whether an answer is a hint or a
| solution.  He may not be ready to worry about signals, but he does need
| to know the distance between his question and a robust application.
|
| Also, there's tons of bad sockets code out there, some in the Python
| standard library.  I did intend my post for people who were already
| doing sockets programming.  Did you check out the signal issue?

If you feel the standard distribution's modules are really bad, then
maybe it would make sense to address that.  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.
If you go ahead and code up the changes that the standard distribution
needs in your estimation, it will be interesting to see how they fly.
Probably be gratefully accepted, but if the gang thinks the complication
is going to be a burden on future maintenance, for example, or there's
a portability problem, then they could justifiably say thanks, but
no thanks.  The standard library modules really are useful, in real
applications.

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 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.  I would send a byte count.

	Donn Cave, donn at u.washington.edu