Message Passing Protocols

For the machines connected by a network, the only way that one machine talks to another is via message passing.

Message Handling Flow #

GE adopts the Request and Response communication paradigm. The program that plays the role of servicing requests is called server. Correspondingly, the program that sends requests to a server is called client. We use server or client to refer to the role played by a program. A program can act as both server and client at the same time.

We brought in the concept of protocol in TSL Basics. The specification of the request/response message format and the server-side message handling logic is called a GE protocol. The request and response of a protocol resembles the parameters and return value of a local function call, except that the message handling logic is performed remotely at the server side. The request/response in a GE protocol can be either a user-defined data structure specified in TSL or void.

// A local function definition
Response func(Request myReq)
{
  // Request handling logic
}

Three types of protocols are supported in GE: synchronous protocols, asynchronous protocols, and HTTP protocols. The three types of protocols form the foundation of all kinds of distributed computation paradigms on GE.

Synchronous Protocols #

A synchronous protocol is akin to a normal synchronous function call, except that the call is made across machine boundaries. It is usually used to perform a synchronous function on the server side and await the server side to response in a blocking manner as illustrated by the time sequence diagram shown below.

Here are a few synchronous protocol examples:

struct MyRequest
{
  string Value;
}

struct MyResponse
{
  int32 Result;
}

protocol mySynProtocol1
{
    Type: Syn;
    Request: MyRequest;
    Response: MyResponse;
}

protocol mySynProtocol2
{
    Type: Syn;
    Request: void;
    Response: void;
}

protocol mySynProtocol3
{
    Type: Syn;
    Request: MyRequest;
    Response: void;
}

protocol mySynProtocol4
{
    Type: Syn;
    Request: void;
    Response: MyResponse;
}

The request and response of a protocol can be void, as shown by mySynProtocol2, mySynProtocol3, and mySynProtocol4.

Asynchronous Protocols #

For an asynchronous protocol, the server returns an acknowledgement to the client immediately after it receives the message. A thread is then chosen from a thread pool to handle the received message as shown below in the sequence diagram.

Here are a few examples:

struct MyRequest
{
  string Value;
}

protocol myAsynProtocol1
{
    Type: Asyn;
    Request: MyRequest;
    Response: void;
}

protocol myAsynProtocol2
{
    Type: Asyn;
    Request: void;
    Response: void;
}

Asynchronous protocols cannot return any user-defined data to the client, because the server does not wait for the handler's completion before sending back the acknowledgement. Hence, the response of an asynchronous protocol must be void, while the request can be a user-defined message or void. From the perspective of a client, the fact that an asynchronous call returns only means the message is successfully received by the remote peer.

HTTP Protocols #

An HTTP protocol is a synchronous remote call. It is the RESTful version of Syn protocol. It has almost the same time sequence diagram with Syn protocol, except that the request and response are in the JSON format.

Here are a few HTTP protocol examples:

struct MyRequest
{
  string Value;
}

struct MyResponse
{
  int32 Result;
}

protocol myHttpProtocol1
{
    Type: Http;
    Request: MyRequest;
    Response: MyResponse;
}

protocol myHttpProtocol2
{
    Type: Http;
    Request: void;
    Response: void;
}

protocol myHttpProtocol3
{
    Type: Http;
    Request: MyRequest;
    Response: void;
}

protocol myHttpProtocol4
{
    Type: Http;
    Request: void;
    Response: MyResponse;
}

Just like Syn protocols, request and response can be void or user-defined data structures. GE will start a RESTful Http API endpoint for each Http protocol.

http://example.com/myHttpProtocol1/
http://example.com/myHttpProtocol2/
http://example.com/myHttpProtocol3/
http://example.com/myHttpProtocol4/

HTTP protocols are supposed to be used to provide RESTful service endpoints. They are not intended for inter-server communications. Whenever we need to do message passing between GE servers, we should use Syn or Asyn GE protocols: they are much more efficient than their RESTful counterparts for this purpose.