[Pythonmac-SIG] Lost connection

Jack Jansen Jack.Jansen@oratrix.com
Sun, 28 Apr 2002 23:05:03 +0200


On zondag, april 28, 2002, at 06:53 , broz wrote:

> Hi folks,
>
> The solution to my problem could very well seem obvious, but to 
> me it's not
> obvious.
>
> I've got a python application that opens a socket, receives data (XML),
> parses it, and updates a database. Under normal circumstances, 
> it all works
> just fine. Under abnormal circumstances, it sits and spins.
>
> The main application opens a socket with listen(), and then accept() is
> called. It dutifully waits for the other machine to connect() and start
> dumping data. That process works fine. If the other machine 
> drops the line,
> things get hairy. My python app thinks the connection is still 
> live, and
> spins waiting for more data.

Are you sure this is actually what is happening? If the other 
machine dropped the connection early then the accept() will 
never have returned, and you're still waiting for some other 
connection to come in. If you indeed have a recv() hanging on 
the slave socket while you know the other side has disconnected 
then you've run into a bug. If you can give full version 
information on your Python (you didn't even mention whether you 
are using MacPython or MachoPython:-), and include a full script 
(preferrably with the client side too, even though it'll 
probably be a simple socket()/connect()/close() script) I can 
try to reproduce this.

Oh yes, in reply to Bob's remark: there's no problem with the 
listen() call in your setup routine. Listen() does nothing more 
than tell the TCP code that you plan to do an accept() later on, 
so the kernel can start queuing requests for you (and the 
parameter is the maximum number of incoming connection requests 
you'd like to see queued at any one time, so 5 is probably 
overkill here).
--
- Jack Jansen        <Jack.Jansen@oratrix.com>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -