LUDOC-296 protocol: Rearrange presentation to be more top-down

[doc/protocol.git] / mgs_connect.txt

diff --git a/mgs_connect.txt b/mgs_connect.txt
index 2579f57..38a2810 100644 (file)
--- a/mgs_connect.txt
+++ b/mgs_connect.txt
@@ -2,18 +2,35 @@ RPC 250: MGS CONNECT - Client connection to an MGS
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 [[mgs-connect-rpc]]
 
-.MGS_CONNECT (250)
-[options="header"]
-|====
-| request            | reply
-| obd_connect_client | obd_connect_server
-|====
-
-When a client initiates a connection to the MGS,
-it does so by sending an 'obd_connect_client' message and awaiting the
-reply from the MGS of an 'obd_connect_server' message. This is the
-first operation carried out by a client upon the issue of a 'mount'
-command, and the target UUID is provided on the command line.
+.MGS_CONNECT Generic Packet Structure
+image::mgs-connect-generic.png["MGS_CONNECT Generic Packet Structure",height=100]
+
+//////////////////////////////////////////////////////////////////////
+The mgs-connect-generic.png diagram resembles this text art:
+
+       MGS_CONNECT:
+      --request--------------------------------------------
+      | ptlrpc_body | obd_uuid | obd_uuid | lustre_handle |
+      -----------------------------------------------------
+      |  obd_connect_data |
+      ---------------------
+      --reply---------------------------
+      | ptlrpc_body | obd_connect_data |
+      ----------------------------------
+//////////////////////////////////////////////////////////////////////
+
+'ptlrpc_body'::
+RPC descriptor.
+
+'obd_uuid'::
+UUIDs of the target (first) and client (second) entities. See
+<<struct-obd-uuid>>.
+
+'lustre_handle'::
+See <<struct-lustre-handle>>.
+
+'obd_connect_data'::
+See <<struct-obd-connect-data>>.
 
 The target UUID is just "MGS", and the client UUID is set to the
 32byte string it gets from ... where?