Re: identity persistence and comparison issues

On 28-jun-04, at 11:32, Erik Nordmark wrote:

>> Sure it has, the connections just don't last longer than one packet.
>> (-:

> Ah - so "connection" survivability for UDP-based apps then becomes 
> quite easy
> since the problem doesn't exist :-)

Well, yes. But UDP really needs the ability to set up new connections 
very badly...  8-)

> I don't know what the API standards say, but in many implementations
> the app can just do a sendto() which will make UDP pick a port number
> for the duration of the lifetime of the socket. Thus the application
> will be able to receive packets sent in to that port number.

Ok, I don't have enough information to determine whether this is a show 
stopper or not.

> The problem is that the unmodified server extracts the identifier (aka 
> IP
> address) in step2 thus you'd need to make the client pick a long-lived
> identifier in step1, or make step4 pass the identifier+port to the 
> server.
> In either case this implies modifications to the application.

What if we just always show the application a long-lived identifier, 
even though when it sets up a session we use ephemeral identifiers? If 
the application then doesn't do referrals there is no issue as the 
long-lived identifier doesn't leave the host. If it does "contact me at 
xxx" type referrals there is also no problem as xxx is the long-lived 
identifier so the reference remains valid over (a reasonable amount of) 
time. Only in the case of "you'll hear from me and I'm xxx" type 
referrals wouldn't work, but those won't work reliably in the presence 
of multiple addresses anyway.

Obviously there can be a new API call that allows applications to find 
the actual identifier used.