Detecting socket connection failure

Discussion in 'Python' started by schwehr@gmail.com, Jul 10, 2006.

  1. Guest

    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
    , Jul 10, 2006
    #1
    1. Advertising

  2. 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
    Dieter Maurer, Jul 15, 2006
    #2
    1. Advertising

  3. Guest

    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:
    > 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
    , Jul 19, 2006
    #3
  4. Ben Sizer Guest

    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
    Ben Sizer, Jul 20, 2006
    #4
  5. 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.
    Dieter Maurer, Jul 23, 2006
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Laszlo Nagy
    Replies:
    1
    Views:
    4,743
    Mark Wooding
    Jan 27, 2009
  2. Jean-Paul Calderone
    Replies:
    0
    Views:
    936
    Jean-Paul Calderone
    Jan 27, 2009
  3. Laszlo Nagy
    Replies:
    0
    Views:
    517
    Laszlo Nagy
    Feb 1, 2009
  4. Steve Holden
    Replies:
    0
    Views:
    638
    Steve Holden
    Feb 1, 2009
  5. Steve Holden
    Replies:
    1
    Views:
    691
Loading...

Share This Page