Thrift bidirectional communication

[Dams <da...@nolyann.ch>]

Hello,

In the enterprise where I work, I evaluated Thrift. I didn’t know it before and am new to RPC and network contexts. I’m seduced by the quality of its architecture and of the C++ code! Great work!

But we have a special need: not only the client/server communication for a test system, but also a bidirectional communication, for applications running in the same environment. Thrift does not provide this second possibility if I’m not wrong. I found this example: https://github.com/JoelPM/BidiThrift described here: http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html. It is relatively old: 2009.

My questions:
 * Why doesn’t Thrift provide this possibility of bidirectional communication?
 * What do you think about this example? As far as I can understand, it seems to be well designed.
 * Do you intend to plan such a possibility?

Thanks in advance for your answers.
Dams

Re: Thrift bidirectional communication

["James E. King III" <jk...@apache.org>]

I implemented bi-directional support in thrift about 9 years ago, see THRIFT-66.
It was for a company I was working at, and it was only for C#.

This project never picked it up, but the general idea is that instead
of having a
Client and a Server, each end would be an Endpoint, and each end was free to
register a handler for a service, and each end was free to make client requests.
In that model, the Client and Server are only used to establish who is listening
and who is connecting; and it eliminates the current requirement that the party
that connects is the only one who can issue requests.

This generally worked quite well in C# and is in use in production
code at a major
firm, however it never made its way into the rest of thrift.  It's
unlikely I will have
the time to do it in the foreseeable future, but that's the general idea of it.

The file in THRIFT-66 called ThriftCSharpEndpointsChannels.zip did this, along
with adding support for multiplexed services before they became what they are
today, so I would suggest if you are going to look at that
implementation that you
mostly ignore the "channels" and focus on the Endpoint implementation.
I believe
that implementation also provided certificate authentication to the C#
layer at the
time which was also missing, it's a bunch of stuff rolled into one...

- Jim

On Sun, Mar 17, 2019 at 9:14 AM C Bergström <cb...@pathscale.com> wrote:
>
> Hah! I'm in need of exactly this and I may have some working Python
> code soon I can share (maybe). To be fair I'm porting really really
> messy C# implementation over to Python and the C# version *IS* working
> bi-directional. (So it should be possible, right?) By this I mean that
> the client logs in and establishes a connection and the local "server"
> is able listen and reply using that same connection. (You'd think this
> use case of client logging in and stuff would be super common)
>
> I'll watch this thread and post code if nobody else jumps in and gives
> more concrete details sooner.
>
> Good luck :D
>
> On Sun, Mar 17, 2019 at 9:08 PM Dams <da...@nolyann.ch> wrote:
> >
> > Hello,
> >
> > In the enterprise where I work, I evaluated Thrift. I didn’t know it before and am new to RPC and network contexts. I’m seduced by the quality of its architecture and of the C++ code! Great work!
> >
> > But we have a special need: not only the client/server communication for a test system, but also a bidirectional communication, for applications running in the same environment. Thrift does not provide this second possibility if I’m not wrong. I found this example: https://github.com/JoelPM/BidiThrift described here: http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html. It is relatively old: 2009.
> >
> > My questions:
> >  * Why doesn’t Thrift provide this possibility of bidirectional communication?
> >  * What do you think about this example? As far as I can understand, it seems to be well designed.
> >  * Do you intend to plan such a possibility?
> >
> > Thanks in advance for your answers.
> > Dams

Re: Thrift bidirectional communication

[C Bergström <cb...@pathscale.com>]

Hah! I'm in need of exactly this and I may have some working Python
code soon I can share (maybe). To be fair I'm porting really really
messy C# implementation over to Python and the C# version *IS* working
bi-directional. (So it should be possible, right?) By this I mean that
the client logs in and establishes a connection and the local "server"
is able listen and reply using that same connection. (You'd think this
use case of client logging in and stuff would be super common)

I'll watch this thread and post code if nobody else jumps in and gives
more concrete details sooner.

Good luck :D

On Sun, Mar 17, 2019 at 9:08 PM Dams <da...@nolyann.ch> wrote:
>
> Hello,
>
> In the enterprise where I work, I evaluated Thrift. I didn’t know it before and am new to RPC and network contexts. I’m seduced by the quality of its architecture and of the C++ code! Great work!
>
> But we have a special need: not only the client/server communication for a test system, but also a bidirectional communication, for applications running in the same environment. Thrift does not provide this second possibility if I’m not wrong. I found this example: https://github.com/JoelPM/BidiThrift described here: http://joelpm.com/2009/04/03/thrift-bidirectional-async-rpc.html. It is relatively old: 2009.
>
> My questions:
>  * Why doesn’t Thrift provide this possibility of bidirectional communication?
>  * What do you think about this example? As far as I can understand, it seems to be well designed.
>  * Do you intend to plan such a possibility?
>
> Thanks in advance for your answers.
> Dams