Server to server communication

[George Antoniadis]

Hey all.

I'm interested in using grpc to have some servers in golang talk to each other.

The concept would be to try and have a persistent connection between servers and use the same connection for requests on either end.

1. From what I understand it is possible for grpc to send requests from either side of the connection, is that right?

2. Is there a pattern/best-practice/or-something-else on how such a implementation would be done?

The easiest way I guess would be that when a server wanted to make a request to a server, it checks if the connection with that serer is active and if not it connects, but it seems kinda crude.

3. Finally, is grpc right for a server to server use or am I abusing it?

Thank you very much in advance and I do apologise if this is a bit off topic for this group.

George

[Louis Ryan]

Detailed notes below but my high level question would be what is your use case?

On Wed, Nov 18, 2015 at 4:33 AM, George Antoniadis <geo...@noodles.gr> wrote:

Hey all.

I'm interested in using grpc to have some servers in golang talk to each other.

The concept would be to try and have a persistent connection between servers and use the same connection for requests on either end.

1. From what I understand it is possible for grpc to send requests from either side of the connection, is that right?

Currently no. The protocol is designed to support request & response pattern where one side 'the client' is initiating work on 'the server'.  Currently the best way to do what you want is to have a pair of connections.

If you can't do something like that because of firewalls then you can often use bi-di streaming to achieve the desired effect:

- Client opens a stream

- Server sends a 'request' message on the stream

- Client 'responds' to that message on the same stream

We have talked about creating an 'inverter' where we use GRPC streaming to create a  virtual connection in the opposite direction but it wouldn't land any time soon and is just a way of dealing with firewalls

 

2. Is there a pattern/best-practice/or-something-else on how such a implementation would be done?

The easiest way I guess would be that when a server wanted to make a request to a server, it checks if the connection with that serer is active and if not it connects, but it seems kinda crude.

3. Finally, is grpc right for a server to server use or am I abusing it?

It most definitely is. Generally speaking 'servers' are also 'clients' so we tend to use that terminology pretty loosely.

 

Thank you very much in advance and I do apologise if this is a bit off topic for this group.

George

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/c08b52aa-58a5-4de1-a4a0-aaad9b327127%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[George Antoniadis]

Louis thank so very much for a detailed and prompt response.

As for the use case;

I'm considering grpc for use in a decentralised protocol that allows users to store json and binary objects in their home servers and share them with other users on remote servers.

Server must have their communication ports open to the world so there is no NAT issue there. I'm trying to simplify the connection between servers as depending on the users' relationships with others might end up opening quite a lot of connections. (Not an issue if a server only serves a single user but in case of multi-tenant servers this might get ugly).

My previous test implementations were using web sockets as I would like to have something that has wide language support but the lack of proper request/response without a ws sub protocol or annoying wrapper objects led me to scrap it.

I was thinking of using plain http2 but while the client can send proper request/responses, the server can only push attachments via the request promise or whatever it was called.

Grpc and Thrift are my latest attempts while in not to create yet another custom communication protocol, and I really enjoyed grpc the little I played with it.

@Louis, as you said creating a pair of connections is an option, it won't be the end of the world but I was just trying to see if there is any better alternative as servers will be identical and a single pipe would go a long way in a protocol specification.

If there is a draft or discussion on the inverter concept please let me know as it sounds very interesting.

Any ideas, reading material or suggestions are more than welcome.

George

[George Antoniadis]

Any information on a possible spec or even discussion of the inverter would be greatly appreciated.

I apologise for bumping this thread.

Thank you very much in advance,

George

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscribe@googlegroups.com.

[Louis Ryan]

Currently I don't have anything concrete to share about the inverter, a number of folks have asked about it but I doubt its something we would get to prior to getting to GA in Q1. 

Given your use-case why is bi-di streaming insufficient?

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

[George Antoniadis]

While having 2 connections for sending/receiving makes my implementation simpler it forces the need for proper nat-ing or hole-punching and I would be very interested in seeing how this could be avoided. As my nodes are all symmetric (same api) having a single connection would allow all nodes (nat-ted and behind firewalls) to be first-class citizens.

Once again thank you for all your help Louis,

I was asking about specs as I was just trying to understand how such an implementation would look like as on http2 I can't really wrap my head around it.

All I can guess is some kind of framing around server-pushed request promises of "application/grpc" but doesn't really make sense.

I don't expect this to be a priority or even in the roadmap for grpc as it is a very specific edge case.

Thanks again.

[Louis Ryan]

On Tue, Dec 1, 2015 at 2:41 AM, George Antoniadis <geo...@noodles.gr> wrote:

While having 2 connections for sending/receiving makes my implementation simpler it forces the need for proper nat-ing or hole-punching and I would be very interested in seeing how this could be avoided. As my nodes are all symmetric (same api) having a single connection would allow all nodes (nat-ted and behind firewalls) to be first-class citizens.

Once again thank you for all your help Louis,

I was asking about specs as I was just trying to understand how such an implementation would look like as on http2 I can't really wrap my head around it.

All I can guess is some kind of framing around server-pushed request promises of "application/grpc" but doesn't really make sense.

There are a couple of ways to skin this cat :

- emulate a socket over a single HTTP2 data stream and then run HTTP2 over that again

- have the client open N streams to the server that don't specify any call. The server would then respond with the 'request' headers to the client which now inverts and becomes the server. When the call is completed the 'client' side creates another stream for the server to use later.

[tim....@gmail.com]

I am interested in solving this too. In my case the client is behind a firewall and the server is in the cloud. The problem is that the server also needs to make RPC calls to the client, so they both act as server and client at the same time. From the client to the server it is easy, the client just dials the server normally. The other way is problematic because of the firewall, so the server cannot initiate a connection to the client.
Is it possible for the client to dial a connection to the server and be in charge of maintaining it (re-establishes it when it breaks, etc) and to use the socket with a Server on the client side, and the server side socket with a Client on the server side? What needs to happen for this to work? Custom dialer? Custom transport?
Ideally I'd like to use a single connection for bi-directional RPC calls, but if that's not possible, maintaining 2 connections (both started form the client side) would be fine too for now.

[jc...@nanometrics.com]

Hi,

We also have a similar issue here. 

Just read this thread, and still looking for a proper solution.

Cheers,

Jianping

[Eric Anderson]

On Thu, Jan 18, 2018 at 11:01 PM, <jc...@nanometrics.com> wrote:

We also have a similar issue here. 

Just read this thread, and still looking for a proper solution.

Just by happenstance, some other people (privately) were renewing interest for this in Java. One thing led to another and I just posted a working implementation for Java. There was also some work on the C side, which I reference in my PR.

There will need to be some coordination, like a gRFC, and some details to figure out like how core of a feature this will be. But things are looking good. I've create a tracking issue that you can watch for progress.

Aside: It's generally polite to avoid reviving old threads, unless you were on the original thread and need to update it (like if it is now fixed/complete). This thread had been inactive for two years. Instead, you can create a new thread and just reference the old one.