Bugs item #805194, was opened at 2003-09-12 12:56
Message generated for change (Comment added) made by dmeranda
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Popov (evgeni_popov)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inappropriate error received using socket timeout
Initial Comment:
When using the timeout option with a socket object
(python 2.3), I don't have the same behaviour under
Windows than under Linux / Mac.
Specifically, if trying to connect to an unopened port of
the localhost, I get a timeout exception on Windows
(tested under W2K Server), whereas I get a "111 -
Connection Refused" exception on Linux and "22 - Invalid
Argument" on Mac (OS X).
Even if the error message under Mac is not really
appropriate (someone said to me he got the
right 'Connection Refused' on his MAC), I think that the
behaviour under Linux and Mac is the right one, in that it
sends (quickly) an error message and not timeouting.
Note that when using blocking socket the behaviour is
ok under all platforms: they each return back quickly
a "Connection refused" error message (err codes are
different depending on the platform (61=Mac,
111=Linux, 10061=Windows)). FYI, I don't use firewall or
similar prog on my windows box (but that should not
matter, because it does work in blocking mode, so that
can't be a firewall problem).
I heard that the timeout option was implemented based
on Timothy O'Malley timeoutsocket.py. Then, maybe the
pb can come from the usage of select in the connection
function: select is not asked to get back exceptions in
the returned triple, whereas I think some errors can be
returned back through this mean under Windows
(according to Tip 25 of Jon C. Snader book's "Effective
TCP/IP Programming"). So, by not checking the returned
exceptions, we would miss the "connection refused"
error and get instead the timeout error...
----------------------------------------------------------------------
Comment By: Deron Meranda (dmeranda)
Date: 2007-03-09 11:53
Message:
Logged In: YES
user_id=847188
Originator: NO
This is also a problem under HP-UX 11.0 with Python 2.5
The socket connect_ex() will return errno 22 EINVAL instead of
the more appropriate 239 ECONNREFUSED when connecting to a
non-listening socket ... but only if a socket timeout is being
used.
A system call trace reveils a little more what is going on.
For the python code
import socket
s = socket.socket( socket.AF_INET, socket.SOCK_STREAM )
s.settimeout(15.0)
res = s.connect_ex( ('127.0.0.1', 8099) ) # An unused port number
the system call sequence is as follows:
Calling socket.socket()
socket(AF_INET, SOCK_STREAM, 0) = 3
Calling s.settimeout(15.0)
fcntl(3, F_GETFL, 0) = 2
fcntl(3, F_SETFL, 65538) = 0
Calling s.connect_ex(...)
connect(3, 0x400b43f0, 16) = -1 -> ERR#245 EINPROGRESS
poll(0x7cff1914, 1, 15000) = 1
connect(3, 0x400b43f0, 16) = -1 -> ERR#22 EINVAL
If the call to settimeout is removed, then an ERR#239 ECONNREFUSED
is returned by the first connect() and no subsequent poll+connect
is attempted. With the timeout set, note that the poll() returns
immediately no timeout actually occurs.
Note that tracing the same code under Linux shows the exact same
set of system calls, but that the second connect() call returns
ECONNREFUSED instead.
So this appears to be a specific behavior of HP-UX (and
perhaps other Unixes).
Excerpted from the HP man pages for connect(2):
[EINVAL] The socket has already been shut down or
has a listen() active on it; addrlen is
a bad value; an attempt was made to
connect() an AF_UNIX socket to an NFS-
mounted (remote) name; the X.121 address
length is zero, negative, or greater
than 15 digits.
For datagram sockets, if addrlen is a
bad value, the peer address is no longer
maintained by the system.
[ECONNREFUSED] The attempt to connect was forcefully
rejected.
[EINPROGRESS] Nonblocking I/O is enabled using
O_NONBLOCK, O_NDELAY, or FIOSNBIO, and
the connection cannot be completed
immediately. This is not a failure.
Make the connect() call again a few
seconds later. Alternatively, wait for
completion by calling select() and
selecting for write.
----------------------------------------------------------------------
Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-02 04:51
Message:
Logged In: YES
user_id=32863
The Windows part of this bug is a duplicate of bug #777597.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805194&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
