Re: identity persistence and comparison issues

[Erik Nordmark <Erik.Nordmark@sun.com>]

> > 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...

I think you're overlooking that UDP doesn't have the concept of incoming
connections :-)

Seriously, I don't see how we can make any detection/heuristic that
can determine whether the identifier needs to be able to survive
across e.g. multiple socket calls at the API.
 
> 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.

But even this is hard for TCP unless I misunderstand your idea.

Suppose an application which doesn
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

In this case the server takes the "identity" (getpeername()) from
the connection created in 1 as the place to call back.
Thus allocating a longer-lived identifier in 4 wouldn't help,
unless you want to modify the application.

   Erik