3.1.5.1.1 CONNECT

If the bExtOpcode field indicates FRAME_EXOPCODE_CONNECT (0x01), the source address (for example, IPv4 address and port type when running on UDP) for the message SHOULD be checked. If the address corresponds to one with an existing fully established connection, it SHOULD be ignored. If the address is for a previously received inbound connection that has not completed the handshake process and if the dwSessID field matches the previously received CONNECT, another CONNECTED message SHOULD immediately be sent; otherwise, the packet SHOULD be ignored. If the address is for a previously established outbound connection that has not completed the handshake process, the packet SHOULD be ignored.

If the source address does not correspond to any existing connection, it is treated as a new connection attempt. If the recipient is not allowing connections, the packet MUST be ignored. Otherwise, it MUST check the dwCurrentProtocolVersion field for compatibility and reject incompatible version numbers, as indicated in section 2.2.1.1. If the recipient will require fast or full signing on the connection, it MUST also validate that dwSessID is not 0.

If the recipient is not enforcing signing, it SHOULD allocate resources for the new connection and send a CONNECTED response. This includes setting the connect retry timer to continue retrying the CONNECTED reply until either a valid CONNECTED response arrives from the connector, or the maximum number of retries elapses and the connection is terminated.

If the recipient is enforcing signing, it SHOULD NOT allocate resources but instead, send a CONNECTED_SIGNED response that uses a cookie value in its ullConnectSig field that can be used to subsequently verify that the connector saw the CONNECTED_SIGNED reply. This is described in more detail in section 3.1.5.1.3.