Skip to content

MPProtocol

Jump to bottom
Yatao Li edited this page Aug 7, 2017 · 1 revision

id: MPProtocol title: Message Passing Protocols permalink: /docs/manual/TSL/MPProtocol.html prev: /docs/manual/TSL/accessor.html next: /docs/manual/TSL/RESTProtocol.html

For the dispersed machines, the only way that one machine talks to another is via message passing over network. We brought in the concept of protocol in TSL Basics. Three kinds of protocols form the foundation of all kinds of distributed computation paradigms on GE.

Message Handling Flow

GE adopts 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.

The browser does not support SVG.

The specification of the request/response message format and the server-side message handling logic together 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 request handling logic is performed remotely at the server side. The request/response can be either a user-defined data structure specified in TSL or void in a GE protocol.

// 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.

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.

The browser does not support SVG.

Here are a few synchronous protocol examples:

struct MyRequest
{
  string Value;
}

struct MyResponse
{
  int32 Result;
}

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

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 protocols, the server return an acknowledgement to the client immediately after it receives the message. A thread from a thread pool is then chosen to handle the received message as shown below in the sequence diagram.

The browser does not support SVG.

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 on 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 procedure call. It is the RESTful version of a Syn protocol. It has almost the same time sequence diagram with a Syn protocol, except that the request and response are Json structures.

The browser does not support SVG.

Here are a few HTTP API examples:

struct MyRequest
{
  string Value;
}

struct MyResponse
{
  int32 Result;
}

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

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.

Clone this wiki locally