61–70 of 71 posts
* AMQP 1.0 - can also be used for RPC without a broker in between client and server. See https://qpid.apache.org/proton/
* Aeron - low latency, UDP based, see https://github.com/real-logic/aeron
Earlier quoted context omitted.
It's not a normal procedure call within the same process.
Right. Those are methods for I PC. I PC doesn't have to deal with all the same issues as R PC, and so those techniques are going to be faster as a result. You can't really compare them. It's like comparing communication between people physically located in the same room and people located on different continents.
Couple of protocols that would be nice to benchmark for comparison: * AMQP 1.0 - can also be used for RPC without a broker in between client and server. See https://qpid.apache.org/proton/ * Aeron - low latency, UDP based, see https://github.com/real-logic/aeron
- Suddenly you want to enable TLS between one or more components, meaning you need to wrap the socket inside a TLS channel.
- You discover that your client behaves poorly when servers go offline, so you add your own logic for keepalives/pings.
- At some point you want to add metrics to all of this, so you decide to manually add Prometheus metrics to the client/server.
- Later on you want to attach OAuth2 tokens to requests as well, so that you can do credential passing.
- In order to get more insight in your setup, you decide that you want to use this in combination with OpenTracing/Jaeger.
Once all of those features are added to your Redis-like protocol, you discover that you've basically reinvented gRPC... poorly.
Couple of protocols that would be nice to benchmark for comparison: * AMQP 1.0 - can also be used for RPC without a broker in between client and server. See https://qpid.apache.org/proton/ * Aeron - low latency, UDP based, see https://github.com/real-logic/aeron
Re proton: I tried to use it in point-to-point mode, but haven't been able to figure out how; Javadoc reference is useless for that. There exist only Python examples but Python APIs don't map 1:1 to Java APIs.
Example “blocking” client https://github.com/EnMasseProject/enmasse/blob/master/amqp-u... , but might give an idea of how to set “dynamic source” required for rpc.
In general though I think the Qpid python and c++ examples might be better.
I think it comes to no surprise that sending data through a plain TCP socket is faster than using gRPC. The only downside is that over time requirements will likely start to stack up: - Suddenly you want to enable TLS between one or more components, meaning you need to wrap the socket inside a TLS channel. - You discover that your client behaves poorly when servers go offline, so you add your own logic for keepalives…
If you're on the same machine then pipes, unix sockets and shared memory are even faster options.
Earlier quoted context omitted.
Quick reminder that rebuttals are more valuable than downvotes.
Rebuttals take much longer to write. Assuming that two endpoints are using the same or forward-compatible schemas, there's no "assumption" involved: if you sent a message of type T, it gets decoded as type T. There isn't protection against inauthentic messages, admittedly. Would you like to cite an RPC scheme that meets your definition of type safety.
Earlier quoted context omitted.
I did see the big warning labels everywhere. However, there is simply no replacement that is equally fast (protocol 5), easy to use (copyreg) and imports necessary modules when deserializing. So tradeoffs were made.
> imports necessary modules when deserializing This is one of the fundamental security issues.
Strong 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/
Last time I used ZeroMQ was ~7 months ago at my previous job, so maybe things have changed since then, but having to write hacks to see if the other side is still there or not is absolutely terrible.
Also, the Python bindings did not like fork() without exec, which yes is bad and all, but is still something that is done every so often in real world large programs.