Does GRPC support setup service and client at same channel with a transport (TCP connection) about proposal

[Falco20019]

I‘m not sure if I understood your request correctly. You are looking for a way, to have the client connect to the server (so that the server knows how to send messages to the client without knowing the IP) but don‘t want to have any client API?

This would be realizable through Server-Side Streaming.

syntax = „proto3“;

import „google/protobuf/empty.proto“

service MyService
{
    rpc MyCall (google.protobuf.Empty) returns (stream MyResponse);
}

message MyResponse
{
    oneof response_type
    {
        string resp1 = 1;
        int resp2 = 2;
    }
}

You can have a oneof for your response to have multiple different responses on the active connection. These can be full messages. By using Empty as unary message on the client side, you have a dummy object to initiate the stream and the client will only iterate and wait for incoming messages from the server side until it gets the end of steam notification.

gRPC itself has a keep-alive mechanism to keep channels alive and also reconnection mechanisms with exponential backoff if the connect gets lost. So you don’t have to do this in your API.

[sufferpriest]

No, I mean is there another way, the grpc in a process like A run as both client and service at same time, also share same tcp connection. Thus, remote service B can call A like A call B.

[Falco20019]

AFAIK only by using a Bi-Directional Stream. You can have multiple services running on one endpoint. But using the same channel can only be done through one service. AFAIK there is also no other way to attach to an existing channel.

[chwarr]

If it's helpful, there has been some discussion of "tunneling" in gRPC Core issue #14101.

[sufferpriest]

WoW, wonderful, thanks everyone's feedback. My draft code try is following, please help review:
[pain points, and requirement description]
(1) for almost devices run in local/private nat which behide internet, it's really hard get a solution remote server call device's RPC. even, we can setup bi-stream of grpc to target it, I still get concern that if device call N remote services, it need maintain N bi-stream to target it. This is very resource waste.
(2) you know, if server want to send data to device side, need feed data to response in bi-stream, I don't like this style.
I really like server can call device RPC, like device call server.

[draft design]
X-s: the grpc service run in remote internet server.
X-s1: the grpc service1 run in remote internet server.
X-c: the grpc client run in remote internet server which connect to X-s and X-s1 by using any kinds of channel.

A-s: the grpc service run in device side
A-s1: the grpc service1 run in device side
A-c: the grpc client run in device side(such as mobile phone), which connect to remote X-s
A-c1: the grpc client1 run in device side(such as mobile phone), which connect to A-s and A-s1 use same local unix socket channel or innerprocess channel.

Following is the data flow:
(1) for device side, how to call remote server, this is normal behavor, so I ignore this part.
(2) for remote server side, how to call device's side.
a) first of all, we need let device A-c call X-s, and setup bi-stream, and setup heartbeat to maintain keeplive of channel.
notes: need provide device's uuid in metadata in call.
b) If server want to call some device's RPC, need know this device's uuid.
X-c (provide device's uuid in metadata) call X-s, once X-s get a call, check the metadata, query the real call from device's A-c, then clone a response to A-c.
in device side, once A-c get response, check the metadata, if it is call from service, query which service name is called, then will get A-c or A-c1, then clone a response to A-c or A-c1.
in device side, once A-s/A-s1, get response, it means it is ok server called client.