Versions Compared

Old Version 2

changes.mady.by.user Alex Plehanov

Saved on

compared with

New Version 3

changes.mady.by.user Alex Plehanov

Saved on

Key

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

...

Proposed notification format:

Notification
longResource ID (task ID, continuous query ID, etc)
short

Message flags. Bitwise OR operation of following options:

0x0001 Error flag

0x0004 Notification flag (should always be set for notifications)

shortNotification operation code
intError code (if error flag is set)
stringError message (if error flag is set)
...Notification payload (if error flag isn't set)

Operation codes

New request type should be added to start a new task:

...

To notify about task completion following notification code should be used:

NameCode
OP_COMPUTE_TASK_FINISHED6001

To cancel the task existing request type should be used:

NameCode
OP_RESOURCE_CLOSE0

OP_COMPUTE_TASK_EXECUTE message format

...

Notification for successfully executed task
long

Task ID (resource ID).

short

Notification flag (0x0004)

shortOP_COMPUTE_TASK_FINISHED (6001)
objectTask result


Notification for the failed task
long

Task ID (resource ID).

short

Notification flag | Error flag (0x0005)

shortOP_COMPUTE_TASK_FINISHED (6001)
intError code
stringError message

Overall workflow

Proposed task execution workflow:

  1. Client sends OP_COMPUTE_TASK_EXECUTE request and gets task ID as a response if task was successfully registered.
  2. Client has the ability to cancel the task using OP_RESOURCE_CLOSE request and passing task ID as a resource ID to the server.
  3. Server notifies the client with OP_COMPUTE_TASK_FINISHED message when the task is completed (successfully, unsuccessfully or if it was canceled by client). Notification should be sent eventually for each task which was successfully registered by OP_COMPUTE_TASK_EXECUTE request.

Feature masks

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. Clients and servers should inform each other on handshake about features that they supported.

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.

Client-side API (java thin client)

...