Re: identity persistence and comparison issues

Iljitsch van Beijnum wrote:
> On 24-jun-04, at 1:28, Erik Nordmark wrote:
> 
>> One could argue that the application should inform the "stack" about
>> the lifetime of the communication, perhaps by defining some new "open"
>> and "close" APIs, i.e. getting close to defining a session layer.
>> But my gut feel is that this requires more changes to the applications
>> than is warranted.
> 
> 
> Hm, I think you're overlooking the fact that in any case where referrals 
> happen, the host that's being referred to must accept incoming 
> connections. An application waiting for incoming connections is 
> something that's pretty easy to detect for a host stack...
> 
> In other words, the bind(2) call can trigger the creation of a 
> longer-lived identifier. Still, I'm not sure how applications determine 
> which address to use in referrals, it may be necessary to make this an 
> explicit API call = application changes = a bad thing.

That's an interesting point. In a 2-way conversation, a 'close' on a socket
is a strong signal that the stack can forget any state (unless there is
some optimization possible by caching the state). In a referral conversation
that is no longer true - but presumably the referred ID cannot be ephemeral
anyway. Or to say it another way, referrals will only be possible with
long-life IDs. To avoid *any* apps changes, those long-life IDs are going
to have to look exactly like IP addresses, IMHO.

    Brian (not in the chair at this moment)