[Python-Dev] _socket efficiencies ideas

[Marcus Mendenhall]

On Wednesday, April 9, 2003, at 09:37 AM, Guido van Rossum wrote:

>> OK, I'll chime back in on the thread I started...  I mostly have a
>> question for Sean, since he seems to know the networking stuff well.
>
> I'll chime in nevertheless.
>
>> Do you know of any reason why my original proposal (which is to allows
>> IP addresses prefixed with <numeric> e.g. <numeric>127.0.0.1 to cause
>> both the AI_PASSIVE _and_ AI_NUMERIC flags to get set when resolution
>> is attempted, which basically causes parsing with not real resolution
>> at all) would break any known or plausible networking standards?
>
> What are those flags?  Which API uses them?
>
The getsockaddr call uses them (actually the correct name for one of 
the flags is AI_NUMERICHOST, not AI_NUMERIC as I originally stated), 
and its part of the BSD sockets library, which is basically what the 
python socketmodule wraps.

> I still don't understand why intercepting the all-numeric syntax isn't
> good enough, and why you want a <numeric> prefix.
>
I guess intercepting all numeric is OK, it is just less efficient 
(since it requires a trial parsing of an address, which is wasted if it 
is not all numeric), and because it is so easy to implement <numeric>.  
However, all my operational goals are achieved if the old check for 
pure numeric is reinstated at the lowest level (probably in 
getsockaddrarg in socketmodule.c), so it is used everywhere.

>> The current Python socket module basically hides this part of the
>> BSD socket API, and I find it quite useful to be able to suppress
>> DNS activity absolutely for some addresses.  And for Guido: since
>> this type of tag has already been used in Python (as <broadcast>),
>> is there any reason why this solution is inelegant?
>
> The reason I'm reluctant to add a new notation is that AFAIK it would
> be unique to Python.  It's better to stick to standard notations IMO.
> <broadcast> was probably a mistake, since it seems to mean the same as
> 0.0.0.0 (for IPv4).
I accept this logic.  However, python is hiding a very useful (for 
efficiency) piece of the API, or depending on guessing whether you want 
it or not by looking at the format of an address. There are times in 
higher-level (python) code where getaddrinfo  is called to get a CNAME, 
where I would also like to cause the raw IP to be returned by force, 
instead of attempting to get a CNAME, since I already know, by the IP I 
chose, that one doesn't exists.  If we make the same check for numeric 
IPs in getaddrinfo, then it becomes impossible to resolve numeric names 
back to real ones.  There is not way for getaddrinfo to know which way 
we want it, since in this case both ways might be needed.