Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

Miika Komu wrote:
> On Fri, 11 May 2007, Keith Moore wrote:
>
>> please no.  don't try to hide this stuff from the app in the low-level
>> API.   the rest of the network keeps trying to force routing decisions
>> on the apps in the absence of routing information.  ideally, the app
>> shouldn't have to be doing any routing or address selection or
>> anything.  but at present, how to cope with this kind of world is an
>> unsolved problem, and the only place where experimentation can be done
>> towards learning how to solve that problem is at layer 7.    if you
>> cripple the API, you prevent that kind of experimentation (at worst) or
>> (at best) increase the burden on the app writer by forcing him to write
>> his own kernel extensions.
>>
>> that, and you still need to expose IP addresses for diagnostic purposes.
>>
>> what do you gain from trying to hide the IP addresses?
>
> First, to discourage the use of IP addresses as referrals because
> application developer would have to fetch them using a separate
> function call. But maybe this is a weak justification... Second, the
> socket address structure is constrained to 255 bytes. It will fit
> "only" 1 HIT and 15 addresses. Is this enough for e.g. routers?
perhaps strangely, the latter justification makes more sense to me.  no,
15 addresses is not enough.  but it's not acceptable to have the IP
addresses passed implicitly from the resolver to the socket.  offhand,
I'd say that a good compromise would be to allow some reasonable number
of addresses to be specified using sockaddr_hip and to allow more peer
addresses to be added using a setsockopt() call.