Danny -- Thanks for your questions. I'll update the document. But that might not happen for a while, so here are some quick answers:
1) The CCAPI client and server run on the same Windows PC. The build environment is VS2005. So a time_t is 64 bits. 2) As stated in the Design Requirements section, the OS-independent part of the CCAPI server is single threaded. I need to clarify that only the Windows-specific part is multi-threaded. The multiple threads have to do with the RPC connections. 3) What happens when A takes out a lock and goes away is the 4th design requirement: the server must figure it out and clean up. 4) Yes, this should be clearer. The 'request handler' running on the server is the RPC procedure. Client execution suspends during request handler execution and then the client resumes when the procedure running on the server returns. I'll add a description of the connect and request data structures that are queued. 5) The connection is a logical CCAPI connection. It is the server state that must be cleaned up when the client breaks the connection. 6) This section is a placeholder for whatever needs to happen when the library is loaded. It doesn't have any contents right now. 7) On windows, ccs_pipe_t is a string. What it means has changed slightly since the last rev of the sketch. It is a root that identifies the client, to which different suffices are added. To determine the endpoint on which to call ccs_rpc_request_reply, the suffix is something like ".ep." To determine the name of the global event used to signal to the client that the server started, the suffix is something like ".startup." This part of the design (a root and different suffices) is carried over from the current design. I hope that helps. If not, please let mw know. Kevin -----Original Message----- From: Danny Mayer [mailto:[EMAIL PROTECTED] Sent: Monday, December 24, 2007 8:41 AM To: Kevin Koch Cc: kfwdev@MIT.EDU 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. > > Thanks. > > Kevin Kevin, I was more than a little puzzled by your design. 1) SST uses a time_t timestamp. However, note that time_t changed between VS 2003 and VS 2005 and is now a 64-bit quantity by default. It does not matter if this is for internal use only. However it *does* matter if you are passing it to and from a remote system. So your design should specify the exact number of bits you are going to use. 2) You talk about the server's O/S-independent code being single threaded as it must run on platforms that do not allow multiple threads, but you then go on to just talk about Windows which is always multithreaded. So is this code meant to be just a Windows implementation of an existing Unix server or something else? If the latter is true then isn't the design already settled on how this is supposed to work? If this is meant to be moved to Unix later then you need to state that and clearly differentiate the Windows-specific part from the O/S-independent part as almost everything is about Windows. You might want to look at BIND9's implementation of a task queue if you want an O/S-independent implementation that gives you asynchronous-like behavior. 3) I see no problem with A taking out a lock and B being told that the lock is being held by another process. This is a common thing in multithreaded programming. You *must* return a status to B and let it decide what it needs to do. The server should *never* make decisions for the client. In addition what happens if A takes out a lock and goes away? A still holds the lock. The server needs to decide to drop the lock from A so that B can get it. If A then ever returns to unlock you would need to return a LOCK_LOST error. I don't know what you are designing here so I don't know if it's feasible. 4) The following sentence didn't make a lot of sense to me: "The server's listener thread listens for RPC requests. The request handler puts each request/reply endpoint in a queue and returns to the client." What does it return to the client? Did you mean that the listener thread returns? Also when adding and removing from the queue you need to make sure you lock/unlock the queue when you do so. In order for a request/reply to be handled complete information about what is needed needs to be in a data structure but it doesn't seem to be defined here unless there are other documents on this. 5) Connections Aren't all of these connections using TCP. In that case a connection is *required*. 6) CCAPI.DLL code runs when DLL is loaded? What does that mean? The DLL is either loaded at executable startup or and explicit call is made to LoadLibrary() and then you may as well make explicit calls to the library. 7) I'm not sure where the ccs_pipe_t fits into this. Danny _______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev