...

A cluster connection is a logical connection between a client and the entire cluster. Client is considered connected to the cluster as long as there is at least one logical connection between client and the node of the cluster.

A Connection ID is a UUID uniquely identifying a logical connection.

A Node ID is a unique identifier of a server node.

Description

Initial connection

...

• Magic bytes at the very beginning of the very first message. This helps the server to fail quickly in case there is invalid or non-Ignite client established transport level connection with node;
• Protocol versioning. It is needed to let the user use clients and servers of different versions at the same time. Ordinarily, clients and servers would support several versions of protocol and negotiate a version during the handshake procedure. Protocol version is in major.minor.revision format, 2 bytes for each part. Major version is changed on breaking changes (new protocol, basically), minor is changed when new features are added, and revision is changed on bug fixes, just as always;
• Protocol features bitset. This mechanism lets different clients support different subset of features and allows for simpler implementation of new clients. This also may be a mechanism for providing backward compatibility. Bitset is encoded as a variable length array to support any number of features in the future.
• Cluster tag. This identifier is used to make sure a client won’t connect to nodes from different clusters.
• Connection ID. This identifier is used to identify a logical connection established during a handshake. Connection ID is a UUID.
• Extensions map which consists of keys and values (string -> any). Both client and server may skip keys that are unknown to them, which also adds to the protocol’s backward compatibility.

...

1. If a client does not have a Connection ID associated with a server it tries to connect, it initiates a handshake procedure as always;
2. Upon successful completion of the handshake server node creates a connection context object and associated Connection ID and stores it locally, while the node connection is alive. The Connection ID should be generated using a proper secure algorithm (additional research is required here) to make sure an intruder can not generate an existing Connection ID. The ID is returned to the client in HandshakeResponse;
3. Client saves the token Connection ID on its side and associates it with the server. A proper way to identify a server is by using a Node ID;
4. If the node connection is broken, the server starts a logical connection restore timer (timeout is configurable). A result of any ongoing operation should be saved in the connection context object during this period;
5. If a new node connection is established successfully before the timer expires, and client send a ConnectionRestoreReq with a valid Connection ID then timer is stopped, logical connection is considered to be restored and all pending operation results are reported to the client;
6. If the logical connection was not restored during timeout, the connection context object is released and the logical connection is considered closed. In this case even if the client establishes a new node connection successfully and issues a ConnectionRestoreReq, a reject response should be issued by the server node;
7. The client in its turn tries to establish a new node connection and restore logical connection using ConnectionRestoreReq and the saved Connection ID. It can either get “ok” or “connection unknown” responses. The latter means that the client was not able to restore the logical connection within timeout and thus the client should clear data associated with the logical connection and consider it closed. It should also fail any ongoing operations associated with the logical connection and report errors to the user when appropriate.

...

All resources allocated for the client on the server as well as the Connection ID are released in this case.

...