Proposed RPC design for Windows CCAPI clients and server

The proposal is for a single user; the solution is replicated for each user logged onto the PC.

Conventions & clarifications

"Client" and "server" refer to the CCAPI client and server.

The CCAPI client acts as both an RPC client and RPC server and the CCAPI server acts as both an RPC client and RPC server.

• The RPC call from the CCAPI client to the CCAPI server is called the "request." In this mode, the CCAPI client is the RPC client and the CCAPI server is the RPC server.
• The RPC call from the CCAPI server to the CCAPI client is called the "reply." In this mode, the CCAPI client is the RPC server and the CCAPI server is the RPC client.

The Windows username is referred to below as "<USER>."

The Windows Logon Security Identifier is referred to as "<LSID>."

<UUID> means a thread-specific UUID.

<SST> means server start time, a time_t.

A description of client and server authentication has not been added yet.

Design Requirements

• The server's OS-independent code is single threaded, because it must operate on platforms that do not allow multiple threads.
• The client and server must be able to maintain connections, where state is maintained between individual messages.
• Individual messages must be handled in a single threaded server.
• The server must be able to detect when a client dies, so that any connection state can be cleaned up.

Design

The server and each client create an RPC endpoint. The server's endpoint is CCS_<LSID> and the client's endpoint is CCAPI_<UUID>, where each client geta a UUID.

On Windows, the server's ccs_pipe_t type is a char* and is set to the client UUID.

How is the request handled in the server and the reply sent to the client?

One straightforward way is for the reply to be the returned data in the request RPC call (an [out] parameter). That is, data passed from the RPC server to the RPC client. The request handler calls ccs_server_handle_request. Eventually, the server code calls ccs_os_server_send_reply, which saves the reply somewhere. When the server eventually returns to the request handler, the handler returns the saved reply to the client.

But this doesn't work. If two clients A and B ask for the same lock, A will acquire the lock and B will have to wait. But if the single threaded server waits for B's lock, it will never handle A's unlock message. Therefore the server must return to B's request handler and not send a reply to B. So this method will not work.

Instead, there are listener and worker threads in Windows-specific code.

The client's cci_os_ipc function waits for ccs_reply. The client sends the request, including it's UUID, from which the server can construct the endpoint on which to call ccs_reply.

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.

The server's worker thread removes items from the queue, calls ccs_server_handle_request. ccs_server_handle_request takes both the request data and the client UUID . Eventually ccs_os_server_send_reply is called, with the reply data and client UUID in the reply_pipe. ccs_os_server_send_reply calls ccs_reply on the client's endpoint, which sends the reply to the client.

Is there any security issue with the client listening for RPC calls from the server?

Connections

If the client wants state to be maintained on the server, the client creates a connection. When the connection is closed, the server cleans up any state associated with the connection.

Any given thread in an application process could want to create a connection. When cci_ipc_thread_init is called, the connection thread-local variables are initialized. New connections are created when cci_os_ipc() (via _cci_ipc_send) is called and no connection was previously established. Basically we lazily establish connections so the client doesn't talk to the server until it has to.

Detecting client exit

The server must be able to detect when clients disappear, so the server can free any resources that had been held for the client.

The Windows RPC API does not appear to provide a notification for an endpoint disappearing. It does provide a way to ask if an endpoint is listening. This is useful for polling, but we want a better performing solution than that.

The client has an isAlive function on its endpoint.

To detect the client disappearing without using polling, the server makes an asynchronous call to the isAlive function on the client's endpoint. The isAlive function never returns. When the client exits for any reason, it's endpoint will be closed and the server's function call will return an error. The asynchronous call on the server means no additional threads are used.

Windows provides a number of notification methods to signal I/O completion. Among them are I/O completion ports and callback functions. I chose callback functions because they appear to consume fewer resources.

RPC Endpoint / Function summary

• The server creates one CCS_<LSID> endpoint to listen for connection requests and client requests. It has the functions
  • ccs_rpc_connect(msgtype, UUIDlen, <UUID>, status)
  • ccs_rpc_request(msgtype, UUIDlen, <UUID>, msglen, msg, SST, status) called by client. NB: The windows server sets the in_client_pipe to the in_reply_pipe.
    
• Each client thread creates a CCAPI_<UUID> endpoint. It has the functions
  • isAlive [function never returns.]
  • ccs_rpc_request_reply(msgtype, SST, replylen, reply, status)
  • ccs_rpc_connect_reply(msgtype, SST, status

Windows-specific implementation details

Client CCAPI library initialization:

This code runs when the CCAPI DLL is loaded.

• ?

Client initialization:

This code runs when cci_os_ipc_thread_init is called:

• Generate <UUID> and save in thread-specific storage. This serves as the client ID / ccs_pipe_t.
• Create client endpoint.
• Listen on client endpoint.
• Create canonical server connection endpoint from the <LSID>, which the client and server should have in common.
• Test if server is listening to the CCS_<LSID> endpoint.
  • If not, quit. (! Start it?)
• Call ccs_connect(<UUID>) on the CCS_<LSID> endpoint.
• Save SST in thread-specific storage.

Server initialization:

[old]

• Server is initialized by client starting a new process. There should be only one server process per Windows username.

[new]

• Server is started by kfwlogon (as is done currently).
• Capture server start time (SST).
• Start listener thread, create listener endpoint, listen on CCS_<LSID> endpoint.

Establishing a connection:

• Client calls ccs_connect(<UUID>) on server's CCS_<LSID> endpoint.
• Client gets back and stores SST in thread-specific storage.
• If new connection, server ...
  • adds connection to connection table
  • calls isAlive on CCAPI_<UUID>.
    • NB: isAlive never returns.

Client request:

The server's reply to the client's request is not synchronous.

• Client calls ccs_rpc_request(msglen, msg, msgtype, UUIDlen, <UUID>, SST, status) on server's endpoint.
• Server listen thread receives message, queues request.
• Server worker thread dequeues request, processes, calls ccs_rpc_reply(replylen, reply, msgtype, status) on CCAPI_<UUID>.
• Server checks SST. If server's SST is different, it means server has restarted since client created connection.
• Client receives reply.

Detecting client exit

• When connection created, client created an endpoint.
• Server calls isAlive on client's endpoint.
• When isAlive returns, the server's notification callback will be called. Call back routine queues a DISCONNECT pseudo-message. When the server's worker thread handles the DISCONNECT, it will release connection resources.

Detecting server exit

• Client's call to ccs_rpc_request will return an error if the server has gone away.

------
Stop:
Start: