You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately gorpc architecture requires major redesign for decent bidirectional RPC support. This may break existing apps.
Currently I have plans to design and create yet another RPC package from scratch with bidirectional RCP support from the day one (it already has a name - fastrpc :) ). Fastrpc will have the following new features comparing to gorpc:
bidirectional RPC
lower CPU and memory overhead
network channels and byte streams with flow control (probably - this requires additional research).
For bidirectional RPC on the same connection, yamux or muxado could work well. They can also solve the problem where one side is behind a firewall/NAT and the other side is not and you can only establish connections in one direction only.
Powerfull code.
You have in your roadmap the bidirectional support.
-- x --
I work in an simple server that resolve transactions and route message between different peers in bidirectional mode.
You can imagine, the lots concerns and pitfalls when using tcpsockets, channels, goroutines and so on.
It's like many services with an central coordinator.
--- x ---
I can assign an port to each service, and set it's to server-RPC, and an client-RPC to Server-resolver.
Finally, the Server-resolver it's an client-RPC of all services.
Please, your comments.
Thank's.
JM
The text was updated successfully, but these errors were encountered: