~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[[mgs-connect-rpc]]
-.MGS_CONNECT Generic Packet Structure
-image::mgs-connect-generic.png["MGS_CONNECT Generic Packet Structure",height=100]
+The general behavior of MGS_CONNECT RPCs closely resembles that of
+OST_CONNECT RPCs (See <<ost-connect-rpc>>) and MDS_CONNECt RPCs. The
+actual RPC's 'pb_opc' value will be different as are the names of the
+targets and the specific values in the 'obd_connect_data' structure.
+
+.MGS_CONNECT Request Packet Structure
+image::mgs-connect-request.png["MGS_CONNECT Request Packet Structure",height=50]
//////////////////////////////////////////////////////////////////////
-The mgs-connect-generic.png diagram resembles this text art:
+The mgs-connect-request.png diagram resembles this text art:
MGS_CONNECT:
- --request--------------------------------------------
- | ptlrpc_body | obd_uuid | obd_uuid | lustre_handle |
- -----------------------------------------------------
+ --request--------------------------------------------------
+ | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
+ -----------------------------------------------------------
| obd_connect_data |
---------------------
- --reply---------------------------
- | ptlrpc_body | obd_connect_data |
- ----------------------------------
//////////////////////////////////////////////////////////////////////
'ptlrpc_body'::
-RPC descriptor.
+RPC descriptor. See <<struct-ptlrpc-body>>. In a connect message the
+'ptlrpc_body' field 'pb_handle', which is a <<struct-lustre-handle>>,
+is 0. That 'lustre_handle' is distinct from the one mentioned
+below.
-'obd_uuid'::
-UUIDs of the target (first) and client (second) entities. See
-<<struct-obd-uuid>>.
+'target_uuid'::
+A string identifying the target. See <<struct-obd-uuid>>. The client
+learns the UUID strings for the targets via an interaction with the
+MGS.
+
+'client_uuid'::
+A string with the client's own UUID. This is also a
+<<struct-obd-uuid>>. The target sets the 'exp_client_uuid' field of
+its 'eport' structure to this value.
'lustre_handle'::
-See <<struct-lustre-handle>>.
+See <<struct-lustre-handle>>. This 'lustre_handle' is distinct from
+the 'pb_handle' field in the 'ptlrpc_body'. This 'lustre_handle'
+provied a unique 'cookie' to identify this client for this connection
+attempt. After a disconnect, a subsequent connect RPC will have a
+different value. The target preserves this cookie in the 'exp_handle'
+field of its 'obd_export' structure for this client. In that way it
+can distinguish between a resent connection request and an entirely
+new connection request.
'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?
-
-The 'struct lustre_handle' (the fourth buffer in the message) has its
-cookie set to .. what? It is set, but where does it come from?
+The 'ocd_connect_flags' field reflects the capabilities appropriate to
+the client. The 'ocd_brw_size' is set to the largest value for the
+size of an RPC that the client can handle. The 'ocd_ibits_known' and
+'ocd_checksum_types' values are set to what the client considers
+appropriate. Other fields in the descriptor and 'obd_connect_data'
+structures are zero.
-The 'ocd_connect_flags' field is set to (fixme: what?) reflecting the
-capabilities appropriate to the client. The 'ocd_brw_size' is set to the
-largest value for the size of an RPC that the client can handle. The
-'ocd_ibits_known' and 'ocd_checksum_types' values are set to what the client
-considers appropriate. Other fields in the descriptor and
-'obd_connect_data' structures are zero.
+.MGS_CONNECT Reply Packet Structure
+image::mgs-connect-reply.png["MGS_CONNECT Reply Packet Structure",height=50]
-Once the server receives the 'obd_connect_client' message on behalf of
-the given target it replies with an 'obd_connect_server' message. In
-that message the server sends the 'pb__handle' to uniquely
-identify the connection for subsequent communication. The client notes
-that handle in its import for the given target.
+//////////////////////////////////////////////////////////////////////
+The mgs-connect-reply.png diagram resembles this text art:
-fixme: Are there circumstances that could lead to the 'status'
-value in the reply being non-zero? What would lead to that and what
-error values would result?
+ MGS_CONNECT:
+ --reply---------------------------
+ | ptlrpc_body | obd_connect_data |
+ ----------------------------------
+//////////////////////////////////////////////////////////////////////
-The target maintains the last committed transaction for a client in
-its export for that client. If this is the first connection, then that
-last transaction value would just be zero. If there were previous
-transactions for the client, then the transaction number for the last
-such committed transaction is put in the 'pb_last_committed' field.
+'ptlrpc_body'::
+See <<struct-ptlrpc-body>> for details about the RPC descriptor. In a
+connect message the 'ptlrpc_body' field 'pb_handle', which is a
+<<struct-lustre-handle>>, is 0. That 'lustre_handle' is distinct from
+the one mentioned below. In a reply, the 'pb_handle' field has the
+value, $C_t$, uniquely identifying that target. The value $C_t$ is
+preserved in the 'imp_remote_handle' field of the client's import
+structure for this target. See <<struct-obd-import>>.
-In a connection request the operation is not file system modifying, so
-the 'pb_transno' value will be zero in the reply as well.
+'obd_connect_data'::
+See <<struct-obd-connect-data>>.
git://git.whamcloud.com / doc / protocol.git / blobdiff