Kevin Koch wrote: > I've outlined the main parts of the Windows CCAPI design for your reading > enjoyment at http://web.mit.edu/kpkoch/Public/CCAPI-Windows-Design.html. > > You don't need to point out that these are missing: authenticating the > client and server, starting up the server. > > Comments are welcome. Reading through the design, I'm not sure I understand why the reply cannot be sent back to the requester using the RPC connection established by the requestor (the client). Yes, you need to separate the incoming request thread from the worker thread, and yes, you must be able to process multiple incoming requests at the same time, and yes, you must be able to associate the reply with the correct RPC request. However, all of this is reasonable to do. Using the concept of a separate reply endpoint for each and every thread is going to result in a lot of additional complexity in the client side implementation.
Your core code is not going to be thread safe. That just means that you need to wrap all calls into that code with a CriticalSection so that only one thread can process in that code at a time. You must also ensure that you never block in that code to wait for logical locks unless you exit the CriticalSection. You ask if there are any security issues with the client listening for requests from the server. No more so than the security issues of the server listening to requests from the client. If you can authenticate the peer process so that you know you are talking to the correct entity, there would be no issues. Maintaining open connections to the "alive" endpoint of the client seems wasteful. There is a need for a client side endpoint to be used for sending change notifications. This is so that the client doesn't have to poll the cache server every minute as is done today. Why can't the server simply cleanup resources when a change notification fails to establish a connection to the client endpoint? Please review the way that RPC endpoints are named in the current CCAPI implementation. If you are only using the "USER" name for the server endpoint, you will have collisions between multiple sessions on a terminal server implementation. You will also have problems with the CCAPI server instances that are created by winlogon.exe. The endpoint needs to be bound to the logon session not to the user. There is a lot of history in the existing implementation. Please do not repeat the mistakes that have been made over the last eight years. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev