[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.