3.1.5.1 MSG_NEGO_RESP Received

  • Article

On receiving a MSG_NEGO_RESP (section 2.2.5.1) response message from a server, the client MUST first determine if this is a response to a previously sent request by checking the Outstanding Request List for the address of the server. If it is a response to either a MSG_GETBLKLIST (section 2.2.4.2) or MSG_GETBLKS (section 2.2.4.3) message, the client MUST compare the ranges of protocol versions and select a protocol version based on the rules specified later in this section. It must then resend the original MSG_GETBLKLIST or MSG_GETBLKS message, using the selected version.

If it is a response to an MSG_NEGO_REQ (section 2.2.4.1), the client MUST return the highest protocol version supported by both the client and the server to the higher-layer applications.

If the client and server are incompatible, then the client MUST silently discard the MSG_NEGO_RESP message and MUST abort any current exchange with the server, including exchanges for previously sent MSG_GETBLKLIST, MSG_GETBLKS, or MSG_NEGO_REQ messages.

The rules for determining compatibility and selecting a version are listed below:

  1. The client's and the server's major version ranges are calculated from the MSG_NEGO_REQ and MSG_NEGO_RESP messages, respectively. In both cases, they are defined as the inclusive range between the major version from the MinSupportedProtocolVersion field and the major version from the MaxSupportedProtocolVersion field. The highest common major version is the highest value that is included in both ranges. If these ranges do not contain any common values, then no highest common major version exists.

  2. The minor versions within the same major version do not affect protocol compatibility. For instance, a client sending a version 3.2 request message and a server replying with version 3.0 message are fully compatible. The client and the server MUST each select their own highest minor version supported within the highest common major version. For example, if the client supports protocol version range [3.2, 5.0] and the server supports protocol version range [2.0, 4.3], then the highest common major version is 4, and the client will be sending messages with version 4.8 (assuming the highest minor version number for major version 4 is 4.8), whereas the server will be replying with messages with version 4.3. Another example: a client with a supported version range of [1.0, 2.1] and a server with a supported range of [2.5, 2.9] will result in a highest common major version of 2, with the client using version 2.1 and the server using version 2.9.

  3. If no highest common major version exists, then the client and the server are incompatible.

If there is no existing request message previously sent to the server stored in the Outstanding Request List, the client MUST silently discard the received message.