Question on possibility of multiple http/2 connections

[TE-JoakimElvander]

Since I can't see another way of asking this more in private, I'm posting this question here.

I have an issue with the single TCP connection established not having enough bandwidth due to the re-sending of TCP frames etc, and would like to experiment with setting up several service connections and see if I can force TurboLink and the underlying library to open more than one TCP connection to the server.
The reason is that we're moving from a request/response over http/1 to a gRPC stream. With the http/1 solution a new TCP socket was opened and closed with each request/response (normally a problem with http/1), meaning that we could actually parallelize connections this way by making several concurrent requests.
gRPC is designed to make use of a single http/2 connection and multiplexing all kinds of communication over that, which means that the limitations of a single TCP connection comes into play: network issues and many hops means that the TCP socket will spend significant time re-sending lost frames and what not.

Experimenting with your library, it's clear that only a single service should exist for an endpoint according to your design.
But the question is, if I change your code to actually allow more than one service object to be created to an endpoint/service, will that mean that multiple http/2 connections will be set up in the underlying layer? I'm asking since I'm having a hard time following the code to see what's going on in this case...

So sorry for not being able to trace down the answer myself in your code, and hope you have an answer for me :)

[thejinchao]

Sorry for taking so long, because I don't know the answer to your question. In my opinion, the grpc protocol is not suitable for large-traffic data transmission but is more suitable for smaller but more frequent message communication. For large-traffic network transmission, such as transferring relatively large files, it is generally recommended to use pure http protocol, and grpc is not suitable. So when I designed this plugin, the service was managed using a connection pool. Different calls of the same service on the client all used the same grpc::Channel to ensure that frequently used asynchronous grpc calls would not generate frequent tcp connect.
sorry can't help you right now, good luck！

[TE-JoakimElvander]

Thanks for answering! I've been hacking your component to try to force it to connect several channels to same endpoint, so far without success - it looks like even the underlying library may force this. We are now experimenting with having several ports open server-side to see if we can trick the library to establish multiple sockets that way.