THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Protocol negotiation
Protocol Negotiation
In order to use the existing Geode client/server infrastructure, we will be leveraging the current Geode "cache server" component. In the current server implementation, the server expects an initial "handshake" byte, which tells the server the client protocol and how it should be handled. A client, using the new protocol, can connect with the Geode server by sending a protocol byte. Initially, we will support the following two protocols:
- byte - 110: Message will contain the whole request or response.
- byte - 111: If the message is large then client or server can divide the message into the set of small messages. Then they need to collect all the small message and parse the whole request or response.
We may add additional protocol definitions here to indicate the use of an alternative serialization mechanism. For instance bytes 112 & 113 might indicate the but require the server to use Protobuf for serialization of client/server messages. How we handle other serialization libraries will be addressed when the pluggable-serialization architecture is roughed out.
Protocol Field Definitions
Understanding the message definitions it is advised that one references the Protocol Field Definitions page and Supported Data Type Definitions.
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.
Additional Request and Response message definitions can be found in the API's section.
Message definition grammar
In order to consistently define messages the Extended Backus–Naur form grammar will be used.
Usage | Notation |
|---|---|
| definition | = |
| alteration | | |
| optional | [ ... ] |
| repetition | { ... } |
| Grouping | ( ... ) |
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) | Description | |
|---|---|---|
| MessageHeader | type = MessageHeader | The MessageHeader corresponding to this Message. |
| Request | type = Request | This field will contain the Request component. |
| Response | type = Response
| This field will contain the Response component. |
MessageHeader
The Message header is a fixed size header which contains the size of a message, boolean flag to indicates whether a message is partial, and correlation id for that request message. The correlation id is used for the dual purpose here.
- If a message is sent in multiple sub-messages, then it will be used for combining the whole message.
- It will be used for correlating the request to its response.
| MessageHeader = Size CorrelationId isPartialMessage hasMetaData | Description | |
|---|---|---|
| Size | type = int32 | Size of request or response (not including this header) |
| CorrelationId | type = int32 | The correlationID used to match a request to its corresponding response. This will be important if/when we allow for out-of-order messages in the future. |
| isPartialMessage | type = boolean | Is this a partial message? The exact semantics of partial messages is to be determined. |
Request
The request contains optional metadata and the request structure itself.
Request = [MetaData] RequestAPI | Notes | Description |
|---|---|---|
| MetaData | optional, type = MetaData | This field is optional and will be populated if the MessageHeader.hasMeta is true |
RequestAPI | type = variable | The specific Request message. Here are some examples of Request messages. PutRequest | GetRequest | PutAllRequest | GetAllRequest |ServerConfigRequest | ClientConfigRequest | AuthRequest |
Response
The response contains optional metadata and the return value.
Response = [MetaData] APIResponse | Description | |
|---|---|---|
| MetaData | optional, type = MetaData | This field is optional and will be populated if the MessageHeader.hasMeta is true |
| APIResponse | type = variable | The Api specific Reponse message. Here are some examples of Response messages PutResponse | GetResponse | PutAllResponse | GetAllResponse | ServerConfigResposne | ClientConfigResponse | AuthResponse | ErrorResponse |
ErrorResponse
The server will raise the error when it failed to execute API request from the client. The error code and message should help the client to diagnose the issue.
| ErrorResponse = errorMessage | Description | |
|---|---|---|
| errorMessage | type = String | The error message |
Value
The Value is serialized bytes for the Geode region value. It contains value header and series of bytes. Using value header, we can send a big serialized object in more than one chunk.
| Value = {ValueHeader value} | Description | |
|---|---|---|
| encodingType | type = int8 (encoding type) | The encoding type of the following bytes. |
| value | type = bytes | Serialized Value Object which Geode can understand |
Encoding Types
We plan to at least support
| Name | Description |
|---|---|
| Int | 32-bit signed integer, big-endian encoded |
| Long | 64-bit signed integer, big-endian encoded |
| Short | 16-bit signed integer, big-endian encoded |
| Byte | 8-bit signed integer, big-endian encoded |
| Boolean | True or False. |
| String | UTF-8 encoded string. (whether it can contain nulls is TBD) |
| Binary | A binary blob to be stored in the region. |
| JSON | UTF-8 encoded string, containing a JSON document that will be deserialized in the same way as the REST API. |
| Float | 32-bit floating point number. |
| Double | 64-bit floating point number. |
MetaData
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 MetadataKeyValue} | Description | |
|---|---|---|
| NumberOfMetadata | type = int16 | The number of MetaDataKeyId : MetaDataKeyValue combinations |
| MetadataKeyId | type = int16 | Supported MetaDataKeyId's can be found in the table "Supported MetaData - MetaData KeyId" |
| MetadataKeyValue | type = variable | The MetaData value for the KeyId. The supported dataType can be found in the table "Supported MetaData - MetaData Value Type" |
Supported MetaData
We would have following pre-defined key and value for a metadata. Note this list will grow over time.
MetaData for Requests
Request MetaData Key | MetaData KeyId | MetaData Value example | MetaData Value Type | Description |
|---|---|---|---|---|
| JSON_KEY | 1 | true | type = boolean | Geode will expect key as JSON string(or bytes) and it will convert that string into PDX key. If the response requires a key, then it will convert the PDX key to JSON string(or bytes) back. |
| JSON_VALUE | 2
| true | type = boolean | Geode will expect Value as JSON string(or bytes) and it will convert that string into PDX value. If the response requires a value, then it will convert PDX value to JSON string(or bytes) back. |
| EVENT_ID | 3
| EventId { uniqueId: type = String ThreadId:type=int64 SequenceId: type=int64 } | type = bytes | The eventid is used to identify same region event in Geode. Geode keeps map of "uniqueId + threadId" Vs "SequenceId" to know whether region event has been already seen or not.
|
MetaData for Responses
Response MetaData Key | MetaData KeyId | MetaData Value example | MetaData Value Type | Description |
|---|---|---|---|---|
| UPDATE_PR_META_DATA | 1 | true | type = boolean | [optional]The server accepted and forwarded the request to the appropriate node holding the affected cache entry. A smart client should refresh its partitioned region location metadata for higher performance. |