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.