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