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