[Python-bugs-list] [ python-Feature Requests-706392 ] faster _socket.connect variant desired

SourceForge.net noreply@sourceforge.net
Mon, 07 Apr 2003 19:37:27 -0700


Feature Requests item #706392, was opened at 2003-03-19 11:14
Message generated for change (Comment added) made by mendenhall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=706392&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Marcus Mendenhall (mendenhall)
Assigned to: Nobody/Anonymous (nobody)
Summary: faster _socket.connect variant desired

Initial Comment:
The  _socket.connect() call is not quite semantically equivalent to the underlying bsd connect() call in that it always parses an internet address.  This process can be quite slow, since it attempts to determine names and cnames (etc) using getaddrinfo(), which may require DNS lookups to complete.  In an environment where many sockets are being connected and disconnected, this is expensive.  

I would like to propose two minor additions to the _socket module:

1) A python wrapper to the internal getsockaddrarg(), allowing a fully processed socket address to be returned as a string

2) a connect_raw_address() call which is a pure wrapper to the bsd connect() call, and which assumes it is passed a string from getsockaddrarg().

This would allow a socket to be disconnected and reconnected many times to the same address, but with much less network chatter and OS overhead.  Effectively, I would like an unbundled version of _socket.connect(), with each of the two processes it uses able to be carried out independently.  

This is also useful in environments where one is communicating on aprivate network which is connected to the outside world over a (for example) PPP or PPPoE link.  Internal traffic handled through this connect will not result in gratuitous DNS traffic which will keep the link from ever closing.

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

>Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-07 21:37

Message:
Logged In: YES 
user_id=470295

Fater thiunking about what I have done with this patch, I would also like to suggest another change (for which I am also willing to submit the patch, which is quite simple):  Consistent with some of the already extant glue in _socet to handle addresses like <broadcast>, would there be any reason no to modify setipaddr() and getaddrinfo() so that if an address is prefixed with <numeric> (e.g. <numeric>127.0.0.1) that the PASSIVE and NUMERIC flags are always set so these routines reject any non-numeric address, but handle numeric ones very efficiently?

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-04-04 07:29

Message:
Logged In: YES 
user_id=470295

OK, I followed your suggestion and made a very lightweight type sockaddr, which has only a constructor, a destructor, and a method called to_tuple() which allows one to get the data out for reconstruction.  I have included, I think, decent docstrings, but haven't patched any of the main Python doc tree.  If you look at the top of getsockaddrarg(), this is the _only_ place this new type interacts with the rest of the _socket module.  Here is a prototype patch.  I have tried it a bit, and I think it works and is safe.  If you have any comments, please let me know.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-30 14:34

Message:
Logged In: YES 
user_id=470295

Aha, now I see what you are suggesting.  I didn't quite understand what you intended before.  This (wrapping sockaddr and having connect check for the wrapped object) sounds like a very plausible idea.  I will consider strongly doing it this way.

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 11:35

Message:
Logged In: YES 
user_id=21627

Providing a wrapper would allow to reuse the connect
operation, as it could check whether the argument is the
wrapper. If you prefer to use plain strings and a separate
function: that would be fine as well.

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

Comment By: Marcus Mendenhall (mendenhall)
Date: 2003-03-29 11:16

Message:
Logged In: YES 
user_id=470295

Does it really require wrapping sockaddr?  It seems that returning an opaque string containing the data returned by getsockaddrarg that can be passed to the new connect_arw (or whatever) is sufficient.  There doesn't need to be any way to access/mess with the data in this string, since its format is whatever the underlying unix utilities return, and varies by socket address family, etc, but it only needs to be able to be passed blindly to connect.  

Anyway, I would be glad to provide a patch to provide the other routines.    

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

Comment By: Martin v. Löwis (loewis)
Date: 2003-03-29 09:08

Message:
Logged In: YES 
user_id=21627

I think this requires creating a struct sockaddr wrapper
object. Would you be interested in developing a patch?

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

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