Re: sockets APIs extensions for Host Identity Protocol

[Miika Komu <[e-mail]>]

On Mon, 7 May 2007, der Mouse wrote:

Hi and thanks for you comments,

>> Application software wants to work with strings.  [...]
>
>> If I change my "connectbyname" code again, I will change it once more
>> to use a new OS API that hides all the v4 vs. v6 vs. HIP vs. whatever
>> junk, preferably to something much simpler than the code today.
>
> Something wrong with getaddrinfo()?  It certainly could use something
> HIPish under the hood, if some implementor decided to.

Yes, I think the changes in the native HIP API draft are not visible at 
all to higher-level "connectbyname" callers. However, the C-based sockets 
API is used by all of the higher-level libraries and languages...

>>> A potential benefit of the handles is that it would make the API
>>> future-proof againts changes to the HIT size.
>
> getaddrinfo() already is...or at least, it is when used correctly, and
> in this respect it's easier to use it correctly than incorrecetly
> (which is about all you can expect).  It's a slightly broken API, true,
> but the problems with it are not in areas that any putative HIP/HIT
> stuff would fix.

I am curious. Even though this is irrelevant for the discussion, can be 
more specific on what is broken with getaddrinfo?

>>> Similarly, one might argue that the IPv6 transition would have been
>>> a lot easier for applications if the concept of endpoint descriptor
>>> were already available for the past twenty years;
>
> That concept *has* been available for the past twenty years; it's
> called a "socket".  What hasn't been available is a socket
> implementation that doesn't expose the underlying addressing details to
> the application.  This could be - and arguably should be - fixed
> entirely under the socket-layer hood, not by inventing new protocols
> and exposing *them* to the application.  I speculate that the major
> reason this hasn't been done is tradition - sockets have traditionally
> been a fairly direct interface into the kernel, and preserving that
> while presenting this kind of socket interface is relatively hard.

Yes, I agree that the socket would do the trick and would provide enough 
indirection. As you said, the problem is with the tradition of exposing 
the addresses directly to the application. To solve this problem properly, 
we need a "clean slate" approach for the APIs. However, I am not sure if 
the sockets API level is proper place to do this. The draft tries to 
preserve backwards compability while extending the current sockets API to 
its limits. The backwards compatibility is handy when porting old sockets 
API based applications to use the API. The limits are reached by hiding 
the presentation of identifiers and port numbers behind endpoint 
descriptors.

I am not sure what you meant with protocol, but here I assume you meant 
PF_SHIM. The new PF_SHIM family was "invented" as a consequence of 
introducing a new socket address structure for endpoint descriptors. This 
way, the correct size of the socket structure can be determined. It also 
makes more sense to have a separate socket handler for endpoint 
descriptors rather than to mix with IPv4 or IPv6 sockets handlers.

-- 
Miika Komu                                       http://www.iki.fi/miika/