THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Message Definition
A message is a series of bytes which contains the request or response. If the message is large, then we will have provision to divide the message into small messages. In that case, client/server needs to collect all messages to parse the request/response.
The message will be sent in following way. A client can send the multiple messages on the connection and the server will respond to those messages in same order.
Message definition grammar
In order to consistently define messages the Extended Backus–Naur form grammar will be used.
| Usage | Notation |
|---|---|
| definition | = |
| alteration | | |
| optional | [ ... ] |
| repetition | { ... } |
Generic Message definition
Every message will adhere to the following generic message definition. A Message will comprise of a MessageHeader and either a Request or Response component.
| Message => MessageHeader (Request | Response) | |
|---|---|
| MessageHeader | variable size, type = MessageHeader |
| Request | variable size, type = Request |
| Response | variable size, type = Response |
Protocol Terminology
Any binary protocol requires the following things:
Version: This indicates the API version.
Correlation Id: This should be different per request sent. It allows correlation of request and response.
Object Type: The type of a serialized object.
Response Type: It indicates whether a response is partial or complete.
ErrorCodes: It indicates the problem with API invocation.
Chunk Response: Send large response in multiple chunks.
Continuous Response: Client can register(Observer pattern) for events and then server notify the client if those events occur.
Request: It indicates client's message
Response: It indicates server's message.
Request Format: Format of request API and its parameters, which client wants to invoke.
Response Format: Format for API return value, which client invoked.
Message: Set of bytes which contain the Message Header and Request/Response.
Serialized Byte Order: Big Endian
...
We will support all the object types which Geode understands. This would include all the primitive java types, an array of primitive types, collections, java serialization, data serializable, pdx PDX serialization and custom user data serializers. The client needs to serialize objects as described here. This might be extended as part of making the Geode storage format pluggable.
...
| Request => RequestHeader [MetaData] RequestAPI | |
|---|---|
| RequestHeader | variable size, type = RequestHeader |
| MetaData | optional, variable size, type = MetaData |
RequestAPI | variable size, type = RequestTypes (PutRequest | GetRequest | PutAllRequest | GetAllRequest |ServerConfigRequest | ClientConfigRequest | AuthRequest) |
...
The purpose of a metadata to pass defined key value pair with request and response. That will be optional for a client. If there is any metadata associated with request or response, then need to set "hasMetadata" flag to "true" in request or response header. After that send metadata in the following format.
| MetaData => NumberOfMetadata MetadataKeyId MetadataKeyId MetadataKeyValue { MetadataKeyId MetadataKeyValue} | ||||
|---|---|---|---|---|
| NumberOfMetadata | =>fixedSize = 2 bytes, type = int16 | |||
| MetadataKeyId | =>fixedSize = 2 bytes, type = int16 – as defined in the table "Supported MetaData - MetaData KeyId" | |||
| MetadataKeyValue | =>variable size, | Valuetype = as defined in | table belowthe table "Supported MetaData - MetaData Type" | |
Supported MetaData
We would have following pre-defined key and value for a metadata. Note this list will grow over time.
...