Versions Compared

Key

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

...

Protocol Requirements

In the evaluation or definition of any protocol, it expected that the evaluated protocol/framework meets the following requirements:

  • Version: This indicates the API versionVersioning: The protocol has to provide version information, in order to distinguish different protocol versions from one another.

  • Correlation Id: This should be different per request sent. It allows correlation of request and responsenumber is a unique identifier that allows the system to correlate requests and responses.

  • 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 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: It indicates client's messageResponse: It indicates server's message.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: Set of bytes which contain the 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

Approach

 During the investigation into frameworks that would "lower the barrier of entry," it became evident that there are two approaches that can be taken to solve the problem:

  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 and the generation of corresponding service stubs

From an architectural perspective, the protocol proposal can be broken into two areas of interest:

Connect 

In order to fit into the existing Geode client/server infrastructure, we will be leveraging the current Geode "cache server" component.  It accepts an initial byte that tells it what type of client is connecting to the server and how the client 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:

...