sending a file through sockets

[Bryan Olson]

brueckd at tbye.com wrote:

[Bryan Olson had written:]
 >>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.

My intended meaning was "if you think relying on shutdown to determine
end-of message is 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".

Well it did work, the same as it would work without the length prefix.
So in my response when I saw the length was useless, I thought I'd keep
simple and remove it, consistent with my recommendation of the HTTP
protocols.  It also explains good socket programming practice: shutdown
the writing end, and read till the other end's shutdown.

 > 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.

O.K., and if you read my first post, I was entirely matter-of-fact in
pointing out the issues.  No reason to get defensive.  Do you actually
believe use of INADDR_ANY in connect() is doing it right?


 >>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.

O.K. I'm not familiar with Gilfix's implementation.  I tried Tim
O'Malley's, and the timeout on accept() caused servers to bomb out just
because no one had yet made a connection.  I'm a security engineer, so I
tend to look at adversarial cases, hence my call for a "timeout
discipline" rather than just a global timeout.


 >>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.

On the recv() side?  Sure doesn't work that way for me.  Any idea how it
knew?


--Bryan