Windows CCAPI design sketch

[Danny Mayer]

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