[ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect

[SourceForge.net]

Bugs item #889153, was opened at 2004-02-02 19:04
Message generated for change (Comment added) made by klimkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&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: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sankov Dmitry Alexandrovich (sankov_da)
Assigned to: Josiah Carlson (josiahcarlson)
Summary: asyncore.dispactcher: incorrect connect

Initial Comment:
When i use non-blocking socket, connect() method of
asyncore.dispatcher class looks like works incorrect.

Example: if connection have not established then socket
merely closed and handle_error not called and no
exception throwed.

One more example: if writable() and readble() methods
returns zero than handle_connect() will never be called
even if connection will be established.

Thanks.


----------------------------------------------------------------------

Comment By: Alexey Klimkin (klimkin)
Date: 2007-01-08 23:52

Message:
Logged In: YES 
user_id=410460
Originator: NO

I was working with Dmitry desk by desk :), but I don't remember, what did
he really mean with his "broken" english :). The main problem was in
impossibility to connect to another peer in non-blocking manner. The patch
contains the workaround code, which changes original behaviour
significantly. You may seek for your own way to fix blocking connect there.


----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-01-08 20:02

Message:
Logged In: YES 
user_id=341410
Originator: NO

According to my reading, the only change necessary to make the semantics
equivalent for a non-blocking socket for which .connect() has been called
is to change a portion of the dispatcher's __init__ method to:

    try:
        self.addr = sock.getpeername()
    except socket.error:
        # if we can't get the peer name, we haven't connected yet
        self.connected = False


----------------------------------------------------------------------

Comment By: Alexey Klimkin (klimkin)
Date: 2007-01-08 13:37

Message:
Logged In: YES 
user_id=410460
Originator: NO

It's about _non-blocking_ socket. Socket has been created and connect
called. However, for non-blocking socket connect returns immediately. The
patch allows to use connect in non-blocking manner. I don't see any reason
of limiting socket to be connected in blocking manner.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2007-01-07 02:05

Message:
Logged In: YES 
user_id=341410
Originator: NO

It sounds as though the original poster is passing a socket that has been
created, but which is not yet connected, to the dispatcher constructor.

We should update the documentation to state that either the user should
pass a completely connected socket (as returned by socket.accept(), or
which has connected as the result of a a blocking socket.connect() call),
or use the .create_socket() and .connect() methods of the dispatcher.

----------------------------------------------------------------------

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 11:22

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&group_id=5470