RPC Olympics – The Search for the Perfect RPC Protocol
perimeterx.com
RPC Olympics – The Search for the Perfect RPC Protocol
1–10 of 71 posts
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#2Strong recommendation for ZeroMQ as well. It's a thin layer on TCP, is very fast, offers bindings in many languages, and is fairly flexible as well.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#3Damn it, I just learned gRPC and now we're doing something different?
This is just as bad as front-end web dev!
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#4I performed the exact opposite migration at $DAYJOB recently - swapping an internal text-based protocol to HTTP (over a local IPC pipe).
The main benefit was we could suddenly reuse all the codegenerated routers/docs/authentication from the HTTP ecosystem. It significantly simplified/standardised our IPC layer and reduced the "weirdness" in the codebase.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#5No mention of authentication or encryption? I can’t believe that everyone is either using HTTPS with either client certificates or plain HTTP authentication, or using IPsec (or some form of IP tunneling) to make encryption transparent to the application.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#6No mention of authentication or encryption? I can’t believe that everyone is either using HTTPS with either client certificates or plain HTTP authentication, or using IPsec (or some form of IP tunneling) to make encryption transparent to the application.
That's a Layer 5 or 6 issue, or lower if you want to talk about IPSec, not a Layer 7 issue.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#7I wish capnproto was included in this.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#8Strong recommendation for ZeroMQ as well. It's a thin layer on TCP, is very fast, offers bindings in many languages, and is fairly flexible as well. https://zeromq.org/
especially when you use the router pattern on server side in order to have multiple sessions on the same socket.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#9If you're on the same machine then pipes, unix sockets and shared memory are even faster options.
Re: RPC Olympics – The Search for the Perfect RPC Protocol
#10My current rpc model for python is to pickle function name and args/kwargs and publish to redis for any subscribers that might be listening.
If the channel is marked as persisting, I put the message to a hashset with current nanosecond as the timestamp and just send a ping instead.
It is pretty fast with asyncio redis client clocking at an avg 15k rpc/s on a single core with uvloop on a lowly i7