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

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, and it’s not even documented. That establishes the need for a new client-server protocol.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.

Connect 

The new protocol will be integrated with current Geode server. The new client driver can connect with Geode server by sending a protocol byte. Geode will support two protocol.

• byte - 110 : Message will contain the whole request or response. 
• byte - 111 : Request or Response can be divided into multiple messages, if those are large.

Request Type

Following table contains the request type and its corresponding Api id. The ApiId would recognize the API, which client want to invoke on the server. The request format will contain the 2-bytes(int16) for Api id. It will be marked as ApiId in request format.

API Version

API version will be associated with request api. The request fromat will contain 1-byte for version. It will be marked as ApiVersion in request format. Its current value will be 1.

...

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 request format. 

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. For the purpose of the request format, we would distinguish key type and value type.

ObjectKeyType

Geode supports only few object types as the region Key. The region key will be marked as Key in the request format.

ResponseType

ReponseType will indicate that whether the response is partial or complete. A client can process a partial response.  Response with FullResponse type id will indicate the completion of that request. 

The response format will contain the 2-bytes(int16) for response type. It will be marked as ResponseTypeId in the response format.

Error Codes

Error codes indicate the issue with the invocation of API at the server. We have following error code for various issues at the server. The response format will contain the 2-bytes(int16) for error codes. It will be marked as ErrorCode in the response format.

Format Grammer

Format is described using Extended Backus–Naur form grammer.

ProtocolType

The format contains following fixed and variable types. They need to serialize in Big Indian byte order as showed for the example.

...

A message is series of bytes which contains request or response. If the message is large, then we will have provision to divide the message into small messages. The message will be sent in following way.

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. 
• The Client would use correlation id to match the response to its request as well.

...

The request would contain the fixed size request header, optional metadata and request api parameters. 

RequestHeader

The request header contains the ApiId, ApiVersion, and hasMetaData flag to indicate whether the request contains some metadata.

Response Format

The response would contain the fixed size response header, optional metadata and return values.

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.

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 large number of bytes in more than one chunk. 

...

The value header contains the value bytes size and a flag indicates whether it contains all the value bytes. 

APIS

PutRequest

PutResponse

GetRequest

GetResposne

GetAllRequest

GetAllResponse

PutAllRequest

PutAllResponse

MetaData

The purpose of metadata to pass defined key value pair with request and response. 

Examples

PutRequest

string regionName = "ExampleRegion"

Key = 101

Value = "New Geode Client Server Protocol"

CallbackArg = Null

PutResponse

Messages

PutRequestMessage {
	MessageHeader {
  		Size, 4 byte, int32
 		isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
 	}
 
 	RequestHeader {
 		ApiId, 2 byte, int16
 		ApiVersion, 2 byte, int16
 	}
 	PutRequest {
 		regionName, varaible , String {
			len, 2 byte, int16
			variable, utf encoding		
		}
 		key, variable, bytes
		CallbaclArg, variable, bytes
 		Value {
 			ValueHeader {
				Size, 4 byte, int32
				hasPartialBytes, 1 byte, boolean
 			}
			value {
 				bytes, series of bytes
			}
 		}
 	}
}

PutResponseMessage {
	MessageHeader {
    	Size, 4 byte, int32
        isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
    }
  	Success, 1 byte, boolean
}

GetRequestMessage {
	MessageHeader {
  		Size, 4 byte, int32
 		isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
 	}
 
 	RequestHeader {
 		ApiId, 2 byte, int16
 		ApiVersion, 2 byte, int16
 	}
 	GetRequest {
 		regionName, varaible , String {
			len, 2 byte, int16
			variable, utf encoding		
		}
 		key, variable, bytes
		CallbaclArg, variable, bytes
 	}
}

GetResponseMessage {
	MessageHeader {
    	Size, 4 byte, int32
        isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
    }
  	Result, variable, bytes
}

PutAllRequestMessage {
	MessageHeader {
  		Size, 4 byte, int32
 		isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
 	}
 
 	RequestHeader {
 		ApiId, 2 byte, int16
 		ApiVersion, 2 byte, int16
 	}
 	PutRequest {
 		regionName, varaible , String {
			len, 2 byte, int16
			variable, utf encoding		
		}
		NumberOfKeyValuePair, 4 byte, int32 
		KeyValuePair  { 
	 		key, variable, bytes		
 			Value {
 				ValueHeader {
					Size, 4 byte, int32
					hasPartialBytes, 1 byte, boolean
 				}
				value {
 					bytes, series of bytes
				}
			}
 		}
		CallbaclArg, variable, bytes
 	}
}

PutAllResponseMessage {
	MessageHeader {
    	Size, 4 byte, int32
        isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
    }
  	Success, 1 byte, boolean
}

GetAllRequestMessage {
	MessageHeader {
  		Size, 4 byte, int32
 		isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
 	}
 
 	RequestHeader {
 		ApiId, 2 byte, int16
 		ApiVersion, 2 byte, int16
 	}
 	GetRequest {
 		regionName, varaible , String {
			len, 2 byte, int16
			variable, utf encoding		
		}
		NumberOfKeys, 4 byte, int32 
		keys {
 			key, variable, bytes
		}
		CallbaclArg, variable, bytes
 	}
}

GetAllResponseMessage {
	MessageHeader {
    	Size, 4 byte, int32
        isPartialMessage, 1 byte, boolean
		CorrelationId, 4 byte, int32
    }
  	NumberOfKeyValuePair, 4 byte, int32 
	KeyValuePair  { 
		key, variable, bytes		
 		Value {
 			ValueHeader {
				Size, 4 byte, int32
				hasPartialBytes, 1 byte, boolean
 			}
			value {
 				bytes, series of bytes
			}
		}
 	}
}

RPC and Message serialization Frameworks

 During the investigation into frameworks to help "lower the barrier of entry," it became evident that there are two types of external frameworks:

1. 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
2. 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.

1. Message serialization frameworks define the encoding/decoding of defined messages but not the transport or connectivity.
   
2. 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:

1. A Transport Layer (TCP, UDP, HTTP, etc..)
2. 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