Page History

...

Removing annotated entities is allowed after current version is greater than (@Until + 1) or (@Since + 1).

Transport compatibility 

FeatureTable

In case of transport protocol should be changed, Ignite must support -1 Ignite version. 

1. It's proposed to add FeatureTable class that used to track changes in transport protocol. Each entry
2. Changes to communication transport must be tracked with FeatureTable. 
3. Every such a feature must be annotated with @Since Ignite version. This is required to track all affected places, and for removing the compatible code after Ignite version becomes greater than (@Since + 1).
4. Ignite release must disable a communication feature with Ignite node with (@since @Since - 1) version. 
5. On release Ignite should check the @since @Since version and notify release manager to drop support of old versions.

ProtoVer is fixed for Ignite release version. Nodes exchange theirs ProtoVer, FeatureMask on joining node on discovery:

1. If ProtoVer.Major is different then FeatureMask is validated. Let the cluster version V, the joining node version V+2. If the joining node mask contains features since V + 1, then this node must not be join the cluster.
2. If ProtoVer.Minor is differrent then enable Rolling upgrade mode for communication protocol between nodes with different versions.
3. Otherwise communication protocol runs in Stable mode.

Communication handshake

Handshake algorithm is extended on new step - validating TcpCommunicationConfiguration consistency. Settings that affects both communicating nodes must be same:

1. usePairedConnections
2. connectionsPerNode

Stable mode

In Stable mode logic of exchanging messages is not changed. Between nodes open channel, messages are written to the channel one by one as byte stream. There is no delimeters between messages, each message starts with direct type. Reader knows reads full message with Message#readFrom logic.

...

2 bytes: direct type

...

Rolling upgrade mode 

In Rolling upgrade mode logic is different, because node can't know whether it reads full message - Message#readFrom can't guarantee that.

• Sender splits every message on frames. One frame cannot contain more than one message.
• Frame header contains: 
  • continuation bit - flag that shows whether this frame is a part of previous message, or start of new message.
  • frame size - can be default for varlen messages, or defined by Message class for fixed sized messages.
• Message header contains direct type and fields count:
  
  • Let receiver expects N fields, but sender sends (N-1) fields. This field protect of reading random bytes to the Nth field.
• After message is fully written, writer fills remaining frame buffer with zeros. 
• Reader reads message from frames util Message#readFrom returns true or fields count is achieved. Then the message is processed.
  • After that, reader reads to /dev/null until continuation bit is unset.

...

1 byte:

1bit - continuation bit

2-7bit - reserved

...

2 bytes:

unsigned frame size

(frame size limit 64Kb)

...

2 bytes:

direct type

...

1 byte:

fields count

(max 255 fields)

...