Jeffrey Altman wrote: > Jeffrey Altman wrote: >> Kevin Koch wrote: >>> Thanks for that suggestion. I don't believe the local RPC mechanism uses >>> TCP or UDP so are I/O completion ports applicable? >> I'm sorry I haven't had time to provide a detailed response to your >> question. The choice of which RPC mechanism is used is up to you. >> Either TCP or Named Pipes can be used instead of local rpc if you want >> to establish a connection between the two processes that can provide for >> endpoint connectivity detection. >> Both of these methods are frowned upon because they require the >> allocation of additional kernel resources. >> >> Another approach that is much lower cost would be to use the client to >> server connection to communicate the name of a global object that is >> allocated by the client. The client can lock the object and the server >> can add the object to a list of objects it waits on (or tests at the >> beginning of each incoming request.) If the client dies, the server >> will be able to lock the object or will detect that the object is no >> longer present. This approach takes advantage of the shared resources >> of the local system and does not require the use of heavy weight RPC >> mechanisms. >> >> Jeffrey Altman > Better idea, get a handle to the client process and wait on that. >
Is the client process on the same machine? Danny > Jeffrey Altman _______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
