Re: identity persistence and comparison issues

[Erik Nordmark <Erik.Nordmark@Sun.COM>]

> 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 :-)

> I haven't written anything that handles incoming UDP packets, so I 
> don't know for sure, but unless I'm very much mistaken applications 
> need to do a bind() call before they can receive UDP packets too.

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.

> > 1. Client connects to the server.
> > 2. Client asks server do perform X.
> > 3. The server might be able to perform X immediately in which case it 
> > returns
> >    the results on the same connection,
> >    or the server says "I'll call you back later".
> >    In the second case we get
> > 	4. Client creates listening socket. Tells the port number to the 
> > server.
> > 	5. Existing socket is closed
> > 	6. Later server calls back the client

> I don't think I see your problem. If the system uses a long-lived 
> identifier at step 4, and the application obtains this identifier from 
> the system, we're in business, I think. The problems start when the app 
> tries to discover the identifier before step 4 and it obtains a 
> short-lived one.

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.

  Erik