LUDOC-296 protocol: remove internal details from descriptions

[doc/protocol.git] / ptlrpc_body.txt

diff --git a/ptlrpc_body.txt b/ptlrpc_body.txt
index 1f5999a..f8585f5 100644 (file)
--- a/ptlrpc_body.txt
+++ b/ptlrpc_body.txt
@@ -125,10 +125,11 @@ layers supporting the exchange of RPCs can be in good working order
 when 'pb_status' = -ENOTCONN is returned in an RPC reply message. The
 connection refered to by that status is the Lustre connection. That
 connection is part of the shared state between Lustre clients and
-servers that gets established via MDS_CONNECT and OST_CONNECT RPCs,
-and can be lost due to an 'eviction'. So, even when that Lusre
-connection is lost (or has not been established, yet), RPC messages
-can be exchanged.
+servers that gets established via *_CONNECT RPCs,
+and can be lost due to an 'eviction' in the face of temporary connection
+failure or in case of an unresponsive client (from the server's point
+of view). So, even when that Lusre connection is lost (or has not been
+established, yet), RPC messages such as *_CONNECT can be exchanged.
 
 The 'pb_version' identifies the version of the Lustre protocol and is
 derived from the following constants. The lower two bytes give the
@@ -274,7 +275,8 @@ set in any kind of reply message including pings and non-modifying
 transactions. If 'pb_last_committed' is larger than, or equal to, any
 of the client's uncommitted requests (see 'pb_transno' below) then the
 server is confirming those requests have been committed to stable
-storage. At that point the client will free the request structures.
+storage. At that point the client may free those request structures
+as they will no longer be necessary for replay during recovery.
 
 The 'pb_transno' value is always zero in a new request. It is also
 zero for replies to operations that do not modify the file system. For
@@ -363,8 +365,9 @@ allowed during server recovery.
 MGS_CONNECT_ASYNC is currently unused.
 
 MSG_CONNECT_NEXT_VER indicates that the client can understand the next
-higher protocol version, and the server can reply to the connect with
-that RPC version if it is supported, otherwise it will reply with the
+higher protocol version in addition to the currently used protocol, and
+the server can reply to the connect with that higher RPC version if
+it is supported, otherwise it will reply with the
 same RPC version as the request.  This allows RPC protocol versions to
 be negotiated during a transition period (e.g. upgrade from RPC from
 LUSTRE_MSG_MAGIC_V1 to LUSTRE_MSG_MAGIC_V2).