Re: identity persistence and comparison issues

On 28-jun-04, at 1:38, Erik Nordmark wrote:

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

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

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.

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

Yes, this can be a problem that may require application changes to 
solve.

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

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.