Moved to Icebox
A substantial portion of a New Client Server Protocol was implemented as described below. The project was tabled indefinitely soon afterward and dormant for quite a while. After discussing the matter on the dev email list we decided to delete the experimental implementation from the "develop" branch. This was done in release 1.15 in Github SHA ae6b3ac1550bdaed75159fbbe360b6733e7e84ee.
See GEODE-8997
Introduction
Apache Geode is a data management platform that provides real-time, consistent access to data-intensive applications throughout widely distributed cloud architectures. While it currently has high-speed client interfaces for Java, C++ and .NET there is both a need to create lighter-weight clients and a
Table of Contents |
---|
Introduction
Geode is a reliable distributed data management tool. There is a demand to access Geode from various other programming languages. But Unfortunately, the existing client-server protocol is too complex to understand, undocumented. This establishes the need for a new client-server protocol.
Goals
Here are the high level goals.
is undocumented. It evolved over time and is overly complex to meet either of these needs.
This proposal details the requirements, API and structure for a new client/server protocol. It does not specify the exact serialization mechanism, but the intent is for the protocol that is described to be complete in terms of the interface and message ordering. The intent is to make it pluggable so that we can experiment with different serialization formats based on varying performance and ease-of-use needs. In particular, we expect to use a widely-available IDL to serialize the protocol at first and make it accessible from many languages, and possibly implement a custom serialization later for clients needing very high performance. Choosing the IDL is an open goal.
The intent is to allow client functionality to be implemented in phases, moving from a "basic client" to a more advanced "smart client". It endeavors to provide a protocol that is also more amenable to more modern APIs such as those using asynchronous or reactive patterns.
Serialization of application keys, values, callback arguments, function parameters and so forth is a separate matter and are not necessarily tied to the serialization protocol used for client/server messaging. The initial protocol will support primitive types such as scalars, strings, and byte arrays. It will also support JSON documents as values and convert between these and Geode PDX-serialized objects in the servers.
Goals
The high-level goals for the protocol are defined here.
Protocol Requirements
In the evaluation or definition of any protocol, it expected that the evaluated protocol/framework meets the following requirements:
Versioning: The protocol has to provide version information, in order to distinguish different protocol versions from one another.
Correlation Id: This number is a unique identifier that allows the system to correlate requests and responses.
Object Type: The serialization type of the data objects stored inside the messages
Protocol Terms
Any binary protocol will require following things:
Version: This indicates the API version.
Correlation Id: This helps to relate the request-response.
Response Type: It indicates whether a response is partial or complete.
ErrorCodes: It indicates the problem with API invocation.
Chunk Response:
The ability to send a large response in multiple smaller, more manageable chunks.
Continuous Response: Client can register(Observer pattern) for events and then server notify the client if those events occur.
Request:
The request message to be sent
Response: The response message received in relation to a request 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:
The generic construct that represents a message that is to be sent which contains a Message Header and Request/Response.
Serialized Byte Order: Big Endian
RPC and Message serialization Frameworks
Connect
The new protocol will be integrated with the current Geode server. The new client driver can connect with the Geode server by sending a protocol byte. Initially, the Geode 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.
API Id
The ApiId recognizes the API, a client wants to invoke on the server. The request format will contain the 2-byte(int16) for Api id. It will be marked as ApiId in the request format.
API Version
API version will be associated with the request api. The request format will contain a 1-byte(int8) for the version. It will be marked as ApiVersion in the request format. Its current value will be 1.
Correlation Id
The purpose of correlation id to match the request and its corresponding response. The request format will contain the 4-bytes(int32) for correlation Id. It will be marked as CorrelationId in the request and response format. The client needs to send correlation id with the request and server will send the same id with the response.
Object Type
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 serialization and custom user data serializers. The client needs to serialize objects as described here.
ObjectKeyType
Geode supports only few object types as the region Key. The region key will be marked as Key in the request format. the client needs to serialize key as described here.
ResponseType
The Response Type indicates whether the response is partial or complete. The response with the FullResponse type id indicates the completion of that request. And the response with PartialResponse type id indicates the response is partial. The response format will contain the 2-bytes(int16) for response type. It will be marked as ResponseTypeId in the response format.
ResponseType | ResponseTypeId |
---|---|
FullResponse | 1 |
PartialResponse | 2 |
Error Codes
The Error codes indicate the issue with the invocation of API at the server. We have defined the error code for various issues here. The response format will contain the 2-bytes(int16) for error codes. It will be marked as ErrorCode in the response format.
Format grammar
The format is described using Extended Backus–Naur form grammar.
Usage | Notation |
---|---|
definition | = |
alteration | | |
optional | [ ... ] |
repetition | { ... } |
ProtocolType
The format contains following fixed and variable types. They need to serialize in Big Endian byte order as showed for the example.
Type | Number Of Bytes | Value | SerializedBytes |
---|---|---|---|
boolean | Fixed = 1 | true | 0x01 |
boolean | Fixed = 1 | false | 0x00 |
int8 | Fixed = 1 | 1 | 0x01 |
int16 | Fixed = 2 | 1 | 0x00 0x01 |
int32 | Fixed = 4 | 1 | 0x00 0x00 0x00 0x01 |
int64 | Fixed = 8 | 1 | 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 |
String(modified UTF 8 ) | Variable
| "Geode" | 0x00 0x05 (length) 0x47 0x65 0x6f 0x64 0x65 (utf encoding) |
byte[] | Variable
| {1,2} | 0x00 0x02 (length) 0x01 0x02 |
bytes | Variable: series of bytes which contains all the meta info to create the java object. |
...
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 => MessageHeader (Request | Response ) |
---|
MessageHeader => defined below |
Request => defined below |
Response => defined below |
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 isPartialMessage CorrelationId | Description |
---|---|
Size => fixedSize = 4 bytes, type = int32 | Size of request or response |
isPartialMessage => fixedSize = 1 byte, type = boolean | |
CorrelationId => fixedSize = 4 bytes, type = int32 |
Request Format
The request would contain the fixed size request header, optional metadata and request api parameters.
Request => RequestHeader [MetaData] RequestAPI |
---|
RequestHeader => defined below |
MetaData => optional |
RequestAPI => (PutRequest | GetRequest | PutAllRequest | GetAllRequest |ServerConfigRequest | ClientConfigRequest | AuthRequest) |
RequestHeader
The request header contains the ApiId, ApiVersion, and hasMetaData flag to indicate whether the request contains some metadata.
RequestHeader => ApiId apiVersion hasMetaData | Description |
---|---|
ApiId => fixedSize = 2 bytes, type = int16 | |
apiVersion => fixedSize = 1 byte, type = int8 | |
hasMetaData => fixedSize = 1 byte, type = boolean | if there is any meta data associated with this request |
Response Format
The response would contain the fixed size response header, optional metadata and return values.
Response => ResponseHeader [MetaData] APIResponse |
---|
ResponseHeader => defined below |
MetaData => Optional |
APIResponse => (PutResponse | GetResponse | PutAllResponse | GetAllResponse | ServerConfigResposne | ClientConfigResponse | AuthResponse | ErrorResponse) |
ResponseHeader
The response header will have resposneType, which indicates its partial response, full response or error. A hasMetaData flag indicates whether the response contains some metadata.
ResponseHeader => (ResponseTypeId | ErrorCode) hasMetaData CorrelationId | Description |
---|---|
ResponseTypeId => fixedSize = 2 bytes, type = int16 | |
ErrorCode => fixedSize = 2 bytes, type = int16 | When there is error response will have error message(String) for it |
hasMetaData => fixedSize = 1 byte, type = boolean | if there is any meta data associated with this request |
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 |
---|
errorMessage => (variable size, type = String) |
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 {ValueHeader value} | Description |
---|---|
ValueHeader => defined below | |
value => bytes | Serialized Value Object which Geode can understand |
ValueHeader
The value header contains the value bytes size, and a flag indicates whether it contains all the value bytes.
ValueHeader => Size hasPartialBytes | Description |
---|---|
Size => fixedSize = 4 bytes, type = int32 | Number of serialized bytes |
hasPartialBytes => fixedSize = 1 byte, type = boolean | Whether this contains partial bytes of value |
APIS
PutRequest
PutRequest => RegionName Key CallbackArg Value |
---|
RegionName => (variable size, type = String) |
Key => bytes |
CallbackArg => bytes |
Value => defined above |
PutResponse
PutResponse => Success |
---|
Success => fixedSize = 1 byte, type = boolean |
GetRequest
GetRequest --> RegionName Key CallbackArg |
---|
RegionName => (variable size, type = String) |
Key => bytes |
CallbackArg => bytes |
GetResponse
GetResponse => Result |
---|
Result => bytes |
GetAllRequest
GetAllRequest => RegionName NumberOfKeys Key {Key} CallbackArg |
---|
RegionName => (variable size, type = String) |
NumberOfKeys => fixedSize = 4 bytes, type = int32 |
Key => bytes |
CallbackArg => bytes |
GetAllResponse
GetAllResponse --> NumberOfKeyValuePair Key value {Key value} |
---|
NumberOfKeyValuePair => fixedSize = 4 bytes, type = int32 |
Key => bytes |
value => bytes |
PutAllRequest
PutAllRequest => RegionName NumberOfKeys Key Value{Key Value} CallbackArg |
---|
RegionName => (variable size, type = String) |
NumberOfKeys => fixedSize = 4 bytes, type = int32 |
Key => bytes |
Value => defined above |
CallbackArg => bytes |
PutAllResponse
PutAllResponse => Success |
---|
Success => fixedSize = 1 byte, type = boolean |
Metadata
The purpose of a metadata to pass defined key value pair with request and response. That will be optional for 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 following format.
MetaData => NumberOfMetadata MetadataKeyId MetadataKeyValue { MetadataKeyId MetadataKeyValue} | |
---|---|
NumberOfMetadata=> fixedSize = 2 bytes, type = int16 | |
MetadataKeyId => fixedSize = 2 bytes, type = int16 | |
MetadataKeyValue => variable, Value as defined in table below |
...
During the investigation into frameworks to help "lower the barrier of entry," it became evident that there are two types of external frameworks:
- Message Serialization Frameworks - These frameworks allow for the definition of a message in a generic IDL, the generation of language specific classes from the IDL, and the encoding/decoding of those message to be sent over a transport
- RPC Frameworks - There frameworks provide greater coverage in the node-to-node communication: the transport layer (HTTP, TCP, UDP), the message definition in IDL with corresponding serialization mechanism and the definition of methods in the IDL, as well as the generation of corresponding service stubs.
- Message serialization frameworks define the encoding/decoding of defined messages but not the transport or connectivity.
- RPC frameworks concern themselves with connectivity and transport, remote method invocations and the encoding/decoding of defined messages.
Because this protocol needs to be tunable for very high performance, for some lack of functionality and because RPC frameworks hide their network and threading internals, it was decided that option 2 was not viable. See a comparison at RPC framework evaluation.
From an higher-level architectural perspective we can identify 2 layers:
- A Transport Layer (TCP, UDP, HTTP, etc..)
- Message encoding/decoding Layer
This proposal will define the message structure and protocol to be agnostic of transport used.
Message Structure Definition
All details relating to the Message structure definition can be found on the page Message Structure and Definition.
Proposed Implementation Phases
Introducing a new protocol into GEODE has the potential to be highly disruptive. In order to minimize the disruption and maximize the feedback cycles, we suggest implementing the changes in a phased approach. To view the milestones for each phase please see the page Phases and Milestones.
Example messages
To better visualize the protocol messages a few sample messages have been provided on the page Protocol Message Examples
Request MetaData Key | MetaData KeyId | MetaData Value | Description |
---|---|---|---|
JSON_KEY | 1 fixedSize = 2 bytes, type = int16 | true fixedSize = 1 byte, 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 fixedSize = 2 bytes, type = int16 | true fixedSize = 1 byte, 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 fixedSize = 2 bytes, type = int16 | EventId { uniqueId: type = String ThreadId:type=int64 SequenceId: type=int64 } | 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.
|
Response MetaData Key | MetaData KeyId | MetaData Value | Description |
---|---|---|---|
UPDATE_PR_META_DATA | 1 fixedSize = 2 bytes, type = int16 | true fixedSize = 1 byte, 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. |
ServerConfigRequest
The purpose of ServerConfigRequest request to get a server config from the server. The client needs to send this request after connecting to the server. If the client knows server properties, then there is no need to send this request.
ServerConfigRequest => {} |
---|
ServerConfigResponse =>NumberOfProperties PropertyId PropertyValue{ PropertyId PropertyValue} | |
---|---|
NumberOfProperties => fixedSize = 2 bytes, type = int16 | |
Propertyid => fixedSize = 2 bytes, type = int16 | |
PropertyValue => variable, Value as defined in table below |
Server Response Properties | PropertyId | PropertyValue | Description |
---|---|---|---|
SECURITY_ENABLED | 1 | boolean | Whether security is enabled at server |
DIFFIE_HELLMAN_KEY | 2 | byte[] | The server Diffie-Hellman key if the credential is required to encrypt. |
MAX_TIME_BETWEEN_CLIENT_PING | 3 | int32 | If the client connection is idle for MAX_TIME_BETWEEN_CLIENT_PING seconds then the server will close that connection. |
...
The Purpose of ClientConfigRequest request to send a client config to a server. The client needs to send this request after connecting to the server. This request is optional for a client unless a server is configured for the Diffie-hellman algorithm.
ClientConfigRequest | NumberOfProperties PropertyId PropertyValue{ PropertyId PropertyValue} |
---|---|
NumberOfProperties | fixedSize = 2 bytes, type = int16 |
Propertyid | fixedSize = 2 bytes, type = int16 |
PropertyValue | variable, Value as defined in table below |
ClientConfigResponse –-> Success |
---|
Success => fixedSize = 1 byte, type = boolean |
Client Request Properties | PropertyId | PropertyValue | Description | |
---|---|---|---|---|
CLIENT_ID | 1 | string | Unique id for the client; if a client doesn't send this property then the server will just create id (client-host, client-port, server-host, server-port). | optional |
ClIENT_READ_TIMEOUT | 2 | int32 | The client will wait for ClIENT_READ_TIMEOUT for a server response. It's an optional property. | optional |
DIFFIE_HELLMAN_KEY | 3 | byte[] | The client Diffie-Hellman key is required to encrypt the credential. | If a server is configured with it then the client should send this. |
AuthRequest
The purpose of AuthRequest to authenticate the client connection. A client can send the auth request in the following format. Before sending the auth request a client can verify the server config by sending the ServerConfigRequest. A client can send a key-value pair of credentials to authenticate itself.
Those pair needs to serialized in following way. If Diffie-Hellman encryption is enabled on the server side then need to encrypt those serialized bytes. And then send those encrypted bytes to the server. The server will decrypt those bytes and create the key-value pair.
AuthRequest | isDiffieHellmanEnabled ( NumberOfProperties PropertyId PropertyValue{ PropertyId PropertyValue} | NumberOfEncryptedBytes EncryptedCredentials ) |
---|---|
isDiffieHellmanEnabled | fixedSize = 1 byte, type = boolean |
NumberOfProperties | fixedSize = 2 bytes, type = int16 |
Propertyid | bytes |
PropertyValue | bytes |
EncrptedCredentials | bytes |
AuthResponse –-> Success |
---|
Success => fixedSize = 1 byte, type = boolean |
Examples
PutRequest
string regionName = "ExampleRegion"
Key = 101
Value = "New Geode Client Server Protocol"
CallbackArg = Null
MessageHeader
| RequestHeader | PutRequest | |
---|---|---|---|
Size PartialMessage CorrelationId | RequestType apiVersion hasMetaData | RegionName Key CallbackArg | Value ( ValueHeader value ) |
Size = Size of Request (65) 0x00 0x00 0x00 0x42 | RequestType (PutRequestType = 3) 0x00 0x03 | RegionName(type:String, value:"ExampleRegion" ) len = 0x00 0x0d Utf Encoding = 0x45 0x78 0x61 0x6d 0x70 0x6c 0x65 0x52 0x65 0x67 0x69 0x6f 0x6e | Size = (number of serialized bytes = 35) 0x00 0x00 0x00 0x23 |
PartialMessage = (type = Boolean, value = false) 0x00 | apiVersion (1) 0x01 | Key (Serialzied using geode types, value = 101) Geode Int type = 0x39 Value = 0x00 0x00 0x00 0x65 | isPartialBytes = (It contains all serialized bytes, type = boolean) 0x00 |
CorrelationId = 1 0x00 0x00 0x00 0x01 | hasMetaData (false) 0x00 | CallbackArg (Serialzied using geode types, value = null) Value = 0x29 | value (Serialized as Geode String type, value = "New Geode Client Server Protocol") Geode String type = 0x57 Serialized Encoded length = 0x00 0x20 Encoded String = 0x4e 0x65 0x77 0x20 0x47 0x65 0x6f 0x64 0x65 0x20 0x43 0x6c 0x69 0x65 0x6e 0x74 0x20 0x53 0x65 0x72 0x76 0x65 0x72 0x20 0x50 0x72 0x6f 0x74 0x6f 0x63 0x6f 0x6c |
PutResponse
MessageHeader | ResponseHeader | PutResponse |
---|---|---|
Size PartialMessage CorrelationId | ResponseTypeId hasMetaData | Success |
Size = Size of Request (4) 0x00 0x00 0x00 0x04 | ResponseTypeId (FullResponse, type=int16, value =1) 0x00 0x01 | Success(type=boolean, value = true) 0x01 |
PartialMessage = (type = Boolean, value = false) 0x00 | hasMetaData (false) 0x00 | |
CorrelationId = 1 0x00 0x00 0x00 0x01 |
Messages
PutRequestMessage | PutResponseMessage | ||||
---|---|---|---|---|---|
|
| ||||
GetRequestMessage | GetResponseMessage | ||||
|
| ||||
PutAllRequestMessage | PutAllResponseMessage | ||||
|
| ||||
GetAllRequestMessage | GetAllResponseMessage | ||||
|
|