http://web.mit.edu/kpkoch/Public/CCAPI-Windows-Design.html has been updated to reduce the number of endpoints and use the logon session ID in the endpoint name.
At the same time, I'd like the benefit of the eight years of learning. After I read the change logs, I might not fully appreciate some subtlety and might repeat some mistake. If Jeff is talking specifically about the naming of endpoints, then what about lifting that code out of the current implementation? Any clarification will be appreciated. Thanks. Kevin Koch -----Original Message----- From: Jeffrey Altman [mailto:[EMAIL PROTECTED] Sent: Friday, November 09, 2007 12:31 AM To: [EMAIL PROTECTED] Cc: [email protected] Subject: Re: Windows CCAPI design sketch 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 _______________________________________________ kfwdev mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/kfwdev
