Detecting socket connection failure

[schwehr]

Hi All,

I've tried to RTFM this and am having no luck. First off, I am using
Mac OSX 10.4.7 with python 2.4.2 from fink. I am trying to connect to
a server that should be rejecting connections and I was surprised when
it did not throw an exception or do something otherwise equally nasty.
It just connects and never returns any data. First, the proof that
something is there and rejecting the connection (or is it that this
thing actually accepts the connection and then drops it?)...

telnet localhost 31414
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.
Now if I fire up ipython and try to connect...

In [1]: import socket, select

In [2]: remote = socket.socket(socket.AF_INET,socket.SOCK_STREAM)

In [3]: remote.connect(('localhost',31414))

In [4]: remote.recv(200)
Out[4]: ''

In [5]: r,w,e=select.select([remote],[remote],[remote],1)

In [6]: print r,w,e
[<socket._socketobject object at 0x7e48d0>] [<socket._socketobject
object at 0x7e48d0>] []

In [7]: remote.recv(200)
Out[7]: ''

So it looks like it will for ever say that it is ready for read and
write, but really is not. How do I detect this case? The recv may
really not have any data for a long time, so a recv of no bytes is not
a way to test the connection status. This is probably a FAQ, but I
can't figure it out.

Thanks!!
-kurt

[Dieter Maurer]

sc*****@gmail.com writes on 10 Jul 2006 08:42:11 -0700:

I've tried to RTFM this and am having no luck. First off, I am using
Mac OSX 10.4.7 with python 2.4.2 from fink. I am trying to connect to
a server that should be rejecting connections and I was surprised when
it did not throw an exception or do something otherwise equally nasty.
It just connects and never returns any data. First, the proof that
something is there and rejecting the connection (or is it that this
thing actually accepts the connection and then drops it?)...

telnet localhost 31414
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

What you see here is that the connection was opened successfully
(the connect succeeded) and then closed again.

...
In [1]: import socket, select

In [2]: remote = socket.socket(socket.AF_INET,socket.SOCK_STREAM)

In [3]: remote.connect(('localhost',31414))

In [4]: remote.recv(200)
Out[4]: ''

The means, that you see the same in Python:
"recv" returning an empty string indicates that the connection
was closed.

>
In [5]: r,w,e=select.select([remote],[remote],[remote],1)

In [6]: print r,w,e
[<socket._socketobject object at 0x7e48d0>] [<socket._socketobject
object at 0x7e48d0>] []

I have seen something similar recently:

I can write ("send" to be precise) to a socket closed by
the foreign partner without error
(but of course, the written data does not arrive at the remote side).
Only the second "send" raises an exception.

I expect this is a TCP bug.
--
Dieter

[schwehr]

Hi Dieter,

Thanks for the feedback. Were you also using mac osx? I am wondering
at what level this bug is occuring.

-kurt

Dieter Maurer wrote:

sc*****@gmail.com writes on 10 Jul 2006 08:42:11 -0700:

I've tried to RTFM this and am having no luck. First off, I am using
Mac OSX 10.4.7 with python 2.4.2 from fink. I am trying to connect to
a server that should be rejecting connections and I was surprised when
it did not throw an exception or do something otherwise equally nasty.
It just connects and never returns any data. First, the proof that
something is there and rejecting the connection (or is it that this
thing actually accepts the connection and then drops it?)...

telnet localhost 31414
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

What you see here is that the connection was opened successfully
(the connect succeeded) and then closed again.

...
In [1]: import socket, select

In [2]: remote = socket.socket(socket.AF_INET,socket.SOCK_STREAM)

In [3]: remote.connect(('localhost',31414))

In [4]: remote.recv(200)
Out[4]: ''

The means, that you see the same in Python:
"recv" returning an empty string indicates that the connection
was closed.

In [5]: r,w,e=select.select([remote],[remote],[remote],1)

In [6]: print r,w,e
[<socket._socketobject object at 0x7e48d0>] [<socket._socketobject
object at 0x7e48d0>] []

I have seen something similar recently:

I can write ("send" to be precise) to a socket closed by
the foreign partner without error
(but of course, the written data does not arrive at the remote side).
Only the second "send" raises an exception.

I expect this is a TCP bug.
--
Dieter

[Ben Sizer]

sc*****@gmail.com wrote:

First, the proof that
something is there and rejecting the connection (or is it that this
thing actually accepts the connection and then drops it?)...

Yes, it accepts it and then drops it, or perhaps drops it after
receiving some data? It's not a failed or rejected connection from a
socket point of view, however.

In [4]: remote.recv(200)
Out[4]: ''

Assuming I understand the socket module, given how under-documented it
is, I assume this means the socket has now been closed.

How do I detect this case? The recv may
really not have any data for a long time, so a recv of no bytes is not
a way to test the connection status.

You already received zero bytes the first time, which I believe means
the socket is closed, and you shouldn't pass it to select a second
time. You should never get zero bytes unless the socket is closed,
otherwise it would just sit there and wait until it has some bytes to
return to you. Select doesn't tell you that there's data waiting -
obviously it can't, as how would it handle the write case? - but in
fact tells you that the socket is 'ready', and operations upon it
should return immediately. And 'ready' in this case could well just
mean it's ready to tell you that it's not connected.

--
Ben Sizer

[Dieter Maurer]

sc*****@gmail.com writes on 19 Jul 2006 08:34:00 -0700:

...
Were you also using mac osx?

No, I have observed the problem under Linux.

Dieter Maurer wrote:
....

I have seen something similar recently:

I can write ("send" to be precise) to a socket closed by
the foreign partner without error
(but of course, the written data does not arrive at the remote side).
Only the second "send" raises an exception.

I expect this is a TCP bug.