Windows CCAPI design sketch

[Kevin Koch]

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:mayer at ntp.isc.org] 
Sent: Monday, December 24, 2007 8:41 AM
To: Kevin Koch
Cc: kfwdev at 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