Mailing-List: contact dev-help@geode.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.apache.org
Date: Tue, 11 Apr 2017 00:15:41 +0000 (UTC)
From: "Galen O'Sullivan (JIRA)" <jira@apache.org>
To: dev@geode.apache.org
Message-ID: <JIRA.13061206.1491243873000.252237.1491869741989@Atlassian.JIRA>
In-Reply-To: <JIRA.13061206.1491243873000@Atlassian.JIRA>
References: <JIRA.13061206.1491243873000@Atlassian.JIRA> <JIRA.13061206.1491243873709@jira-lw-us.apache.org>
Subject: [jira] [Updated] (GEODE-2746) Investigate and Evaluate Existing RPC
 frameworks.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 11 Apr 2017 00:15:47 -0000


     [ https://issues.apache.org/jira/browse/GEODE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Galen O'Sullivan updated GEODE-2746:
------------------------------------
    Description: 
There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects.

If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable.

A few contenders:
* [BERT|http://bert-rpc.org]
* [thrift|https://thrift.apache.org/]
* [gRPC|http://www.grpc.io/]

These are two not-entirely-common features we will need to have:
* support for SSL/TLS, ability to connect to a server with IP & port.
* support for push messages from the server without polling (this is needed for CQs).

This is one half of GEODE-2734.

  was:
There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects.

If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable.

A few contenders:
* [BERT|http://bert-rpc.org]
* [thrift|https://thrift.apache.org/]
* [gRPC|http://www.grpc.io/]

This is one half of GEODE-2734.


> Investigate and Evaluate Existing RPC frameworks.
> -------------------------------------------------
>
>                 Key: GEODE-2746
>                 URL: https://issues.apache.org/jira/browse/GEODE-2746
>             Project: Geode
>          Issue Type: Sub-task
>          Components: messaging
>            Reporter: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the structure of your protocol and the tool will generate code for talking over the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll design our own binary protocol. This protocol would define both what kind of messages can be sent and how they are encoded on the wire. How we encode the objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed for CQs).
> This is one half of GEODE-2734.


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)