Versions Compared

Old Version 3

changes.mady.by.user Alex Plehanov

Saved on

compared with

New Version 4

changes.mady.by.user Alex Plehanov

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Currently, protocol versions are used to support backward-compatibility. Sometimes it's not convenient since to support some feature client should increase protocol version and support all other features introduced in all the previous versions of the protocol. This problem can be solved by using feature masks in the new protocol version. Clients and servers should inform each other on handshake about features that they supported.

Proposed new protocol version: 2.0.0

Proposed changes to handshake request and response: 

Request
byteHandshake code, always 1
shortVersion major
shortVersion minor
shortVersion patch
byte

Client code, always 2


intClient features mask array lengthSince version 2.0.0 (new field)
byte[]Client features mask arraySince version 2.0.0 (new field)
MapUser attributesSince version 1.7.0
StringUsername (optional)Since version 1.1.0
StringPassword (optional)Since version 1.1.0


Response (success)
byteSuccess flag, 1
intServer features mask array lengthSince version 2.0.0 (new field)
byte[]Server features mask arraySince version 2.0.0 (new field)
UUIDNode idSince version 1.4.0

Features mask - it's an array, where some bit is set if the feature with the corresponding id is supported. 

For compute tasks execution following future should be introduced:

Featureid
EXECUTE_TASK_BY_NAME0

So, bit 0 should be set on features mask if the client supports this feature.

...