Re: sockets APIs extensions for Host Identity Protocol

[Chris Newman <[e-mail]>]

der Mouse wrote on 5/11/07 12:02 -0400:
>> - getaddrinfo encourages use of string constants to specify ports,
>>    rather than numeric constants, which is wrong -
>
> No, this is very right.  The notion that "ports" are small integers is
> a *horribly* IP-centric notion.  DECnet, for example, uses short
> strings (8-char? 12-char? I don't know the limit) which do *not* have
> to map into numbers - I think X over DECnet, for example, uses "port"
> strings like "X$0" and "X$1".

Making an IETF-defined API more complex in order to accommodate non-IETF 
technology seems to go against the primary purpose of an IETF-defined API (to 
ease deployment of IETF protocols).

>> - it has no way to be used asynchronously other than to put each call
>>    to getaddrinfo in a separate thread,
>
> Neither does gethostbyname().  And, without a lot of callback or AIO
> scaffolding - or threading - it *can't*.

The sockets API, on the other hand, provides a convenient socket option and 
socket fd/handle suitable for asynchronous use.  Even though the only universal 
API to wait for async socket activity has a terrible design, the simple concept 
of an fd/handle for a socket has allowed operating systems to independently 
develop different asynchronous scaffolding (e.g., poll, /dev/poll, 
port_associate, kqueue, CFNetwork, etc).  So it's possible to design an 
asynchronous-friendly API (like sockets) without limiting the scaffolding and 
with minimal impact on synchronous users.

                - Chris