RPC 250: MGS CONNECT - Client connection to an MGS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[[mgs-connect-rpc]]

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-request.png diagram resembles this text art:

       MGS_CONNECT:
      --request--------------------------------------------------
      | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
      -----------------------------------------------------------
      |  obd_connect_data |
      ---------------------
//////////////////////////////////////////////////////////////////////

'ptlrpc_body'::
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.

'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 'export' structure to this value.

'lustre_handle'::
See <<struct-lustre-handle>>. This 'lustre_handle' is distinct from
the 'pb_handle' field in the 'ptlrpc_body'.  This 'lustre_handle'
provides 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 '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.

.MGS_CONNECT Reply Packet Structure
image::mgs-connect-reply.png["MGS_CONNECT Reply Packet Structure",height=50]

//////////////////////////////////////////////////////////////////////
The mgs-connect-reply.png diagram resembles this text art:

       MGS_CONNECT:
      --reply---------------------------
      | ptlrpc_body | obd_connect_data |
      ----------------------------------
//////////////////////////////////////////////////////////////////////

'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>>.

'obd_connect_data'::
See <<struct-obd-connect-data>>.