1 RPC 250: MGS CONNECT - Client connection to an MGS
2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5 The general behavior of MGS_CONNECT RPCs closely resembles that of
6 OST_CONNECT RPCs (See <<ost-connect-rpc>>) and MDS_CONNECt RPCs. The
7 actual RPC's 'pb_opc' value will be different as are the names of the
8 targets and the specific values in the 'obd_connect_data' structure.
10 .MGS_CONNECT Request Packet Structure
11 image::mgs-connect-request.png["MGS_CONNECT Request Packet Structure",height=50]
13 //////////////////////////////////////////////////////////////////////
14 The mgs-connect-request.png diagram resembles this text art:
17 --request--------------------------------------------------
18 | ptlrpc_body | target_uuid | client_uuid | lustre_handle |
19 -----------------------------------------------------------
22 //////////////////////////////////////////////////////////////////////
25 RPC descriptor. See <<struct-ptlrpc-body>>. In a connect message the
26 'ptlrpc_body' field 'pb_handle', which is a <<struct-lustre-handle>>,
27 is 0. That 'lustre_handle' is distinct from the one mentioned
31 A string identifying the target. See <<struct-obd-uuid>>. The client
32 learns the UUID strings for the targets via an interaction with the
36 A string with the client's own UUID. This is also a
37 <<struct-obd-uuid>>. The target sets the 'exp_client_uuid' field of
38 its 'eport' structure to this value.
41 See <<struct-lustre-handle>>. This 'lustre_handle' is distinct from
42 the 'pb_handle' field in the 'ptlrpc_body'. This 'lustre_handle'
43 provied a unique 'cookie' to identify this client for this connection
44 attempt. After a disconnect, a subsequent connect RPC will have a
45 different value. The target preserves this cookie in the 'exp_handle'
46 field of its 'obd_export' structure for this client. In that way it
47 can distinguish between a resent connection request and an entirely
48 new connection request.
51 See <<struct-obd-connect-data>>.
53 The 'ocd_connect_flags' field reflects the capabilities appropriate to
54 the client. The 'ocd_brw_size' is set to the largest value for the
55 size of an RPC that the client can handle. The 'ocd_ibits_known' and
56 'ocd_checksum_types' values are set to what the client considers
57 appropriate. Other fields in the descriptor and 'obd_connect_data'
60 .MGS_CONNECT Reply Packet Structure
61 image::mgs-connect-reply.png["MGS_CONNECT Reply Packet Structure",height=50]
63 //////////////////////////////////////////////////////////////////////
64 The mgs-connect-reply.png diagram resembles this text art:
67 --reply---------------------------
68 | ptlrpc_body | obd_connect_data |
69 ----------------------------------
70 //////////////////////////////////////////////////////////////////////
73 See <<struct-ptlrpc-body>> for details about the RPC descriptor. In a
74 connect message the 'ptlrpc_body' field 'pb_handle', which is a
75 <<struct-lustre-handle>>, is 0. That 'lustre_handle' is distinct from
76 the one mentioned below. In a reply, the 'pb_handle' field has the
77 value, $C_t$, uniquely identifying that target. The value $C_t$ is
78 preserved in the 'imp_remote_handle' field of the client's import
79 structure for this target. See <<struct-obd-import>>.
82 See <<struct-obd-connect-data>>.