[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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)