From: Antoine Cœur Date: Sun, 30 Jun 2019 17:32:16 +0000 (+0800) Subject: Fix typos X-Git-Tag: krb5-1.18-beta1~97 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=27521a6b02421608148f20f26c2a73f93d339f8c;p=thirdparty%2Fkrb5.git Fix typos --- diff --git a/doc/basic/rcache_def.rst b/doc/basic/rcache_def.rst index de3b2155cc..a80cf5af6c 100644 --- a/doc/basic/rcache_def.rst +++ b/doc/basic/rcache_def.rst @@ -66,7 +66,7 @@ are in lowercase. The following types are defined: #. **none** disables the replay cache. The residual value is ignored. #. **file2** (new in release 1.18) uses a hash-based format to store - replay records. The file may grow to accomodate hash collisions. + replay records. The file may grow to accommodate hash collisions. The residual value is the filename. #. **dfl** is the default type if no environment variable or diff --git a/src/aclocal.m4 b/src/aclocal.m4 index c74755a35c..2394f7e335 100644 --- a/src/aclocal.m4 +++ b/src/aclocal.m4 @@ -1245,11 +1245,11 @@ dnl dnl This test exists so that every application developer does not test this in dnl a different, and subtly broken fashion. dnl -dnl It has been argued that this test should be broken up into two seperate +dnl It has been argued that this test should be broken up into two separate dnl tests, one for the resolver libraries, and one for the libraries necessary dnl for using Sockets API. Unfortunately, the two are carefully intertwined and dnl allowing the autoconf user to use them independantly potentially results in -dnl unfortunate ordering dependancies -- as such, such component macros would +dnl unfortunate ordering dependencies -- as such, such component macros would dnl have to carefully use indirection and be aware if the other components were dnl executed. Since other autoconf macros do not go to this trouble, and almost dnl no applications use sockets without the resolver, this complexity has not diff --git a/src/ccapi/doc/CCAPI-Windows-Design.html b/src/ccapi/doc/CCAPI-Windows-Design.html index bbcb9303df..dd32acbacf 100644 --- a/src/ccapi/doc/CCAPI-Windows-Design.html +++ b/src/ccapi/doc/CCAPI-Windows-Design.html @@ -40,12 +40,12 @@

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.

+

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 client's cci_os_ipc function waits for ccs_reply. The client sends the request, including its 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.

+

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.

@@ -53,8 +53,8 @@

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.

+

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, its 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