sending a file through sockets

[brueckd at tbye.com]

On Sat, 6 Jul 2002, Bryan Olson wrote:

>  >>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.
> 
> I assume you mean when the other side calls close.

Yes, of course, as it would be goofy to call close and then recv all on
the same side of the connection. I'm just pointing out that a call to
shutdown() is not needed. And in fact in many cases it would be not wanted 
since you'd probably want to use the connection for something else later.

>  > Finally, I just tried killing the
>  > server process and the client side immediately came back with a 0-byte
>  > successful read.
> 
> That's the system doing the shutdown for you.  If you think it's too
> dangerous, well,

?? Not sure what you're talking about here. I don't remember saying 
anything was too dangerous.

> the code you posted didn't actually check the length.
> The explicitly sent length only protected against the server sending
> more data than that.

Yes, as I already pointed out, I failed to include the standard disclaimer
of "this works in my brain's Python interpreter, YMMV". I actually spend
most of my days writing network agents in Python (so I do know how to do
it "right" or whatever), but I was just posting some code from memory to
help the guy out; I think it's pretty obvious that you don't cut code from
a Usenet post and paste it into your production system and expect no
problems.

>  > FWIW, latest CVS version of sockets has timeout support. Yay!
> 
> Actually the sockets in the Python 2.2 (Windows) library I have support
> timeouts and select().  The problem is that the protocol libraries don't
> use them.

What I'm saying is that, in CVS, Modules/socketmodule.c has Michael
Gilfix's timeout socket implementation, e.g. socket objects have
settimeout().  Also, once you have timeout sockets, most of the protocol
libraries don't _need_ to worry about them. For example, in the Python
version of timeoutsocket.py, you can just set a global timeout value and
then the protocol libraries work automatically because an exception gets
raised on timeout and control returns to your app. There's not much more
than this they could do intelligently even if they _did_ know about
timeouts themselves.

>  > The other side detects it immediately, for other problems you tend
>  > to get a socket.error exception.
> 
> On pull-the-plug a recv won't detect the connection loss until the local
> system tries a keepalive probe, which is typically two hours.

Apparently we're talking about different things because I just tried it
and got a socket.error exception ('connection reset by peer') on Windows.  
Or, you misunderstood the point of Donn's appliance analogy - I believe he
was just saying, "yeah, technically in some cases you can get by without a
length prefix, but it's handy and more reliable to include it and so darn
easy that you might as well".

-Dave