> Redis vs XML-RPC/JSON-RPC is a mismatch. It's more of a msgpack-RPC with Redis as broker vs XML-RPC or JSON-RPC: I used it as a sort of mental shortcut. Mess

> Redis vs XML-RPC/JSON-RPC is a mismatch. It's more of a msgpack-RPC with Redis as broker vs XML-RPC or JSON-RPC: I used it as a sort of mental shortcut. MessagePack is very similar in data model to JSON or what XML-RPC allows, so I treat them as essentially the same. I was comparing the architectures where the client connects directly to RPC server, as opposed to connecting to a third party (broker, Redis in this case), which is supposed to relay the communication. > 1. Most brokerless RPC protocols make it difficult to inspect the message on the fly. With Redis, you can open up redis-cli and subscribe to the appropriate channels to extract the raw messages. For most users this might not mean anything, but for others this could mean easier debugging, measuring performance, and so on. This sort of things is usually implemented using logging, but I agree that while usually it's not an important feature, there are cases when it is extremely useful. > 2. msgpack's serialized format is small. [...] Though this doesn't concern Redis, and could be a wire protocol over raw TCP. > [...] the idea of introducing Redis into the equation to use as the broker didn't seem like additional complexity to me because a lot of other network messaging protocols rely on a broker anyway. But we're not talking about messaging protocols, we're talking about RPC protocols/systems. You introduce two services (Redis + RPC server) for a task that usually was carried out by one. This is why I claim it's greater complexity than usual. > ZeroRPC, another popular RPC choice, uses ZMQ. I'm not sure it is that popular. Thrift, Protocol Buffers, and gRPC seem much more widely used, and XML-RPC is a little longer on the market, so it probably got a fair share of RPC use. And ZeroRPC doesn't seem use broker, just a ZeroMQ protocol. ZMQ is in this setting more like a transport protocol than a separate service to dispatch requests and responses. > The client and server don't even have to know each other's address and port, they just have to know which Redis instance to connect to and assume that there exists one of the other to work with. So instead of knowing an address and port of an RPC server, client needs to know address and port of Redis. This doesn't seem to be much of a gain. At best, Redis acts as something analogous to port mapper in this setting (though it relays all the communication instead of telling the client where to connect to). > Redis also provides the channel buffer and the queue instead of me having to write those as part of the client/server code, which means anyone else looking to implement the protocol in another language wouldn't have to deal with those as well. Job queueing is somewhat outside of the RPC protocol, though I agree it can be useful. The RPC system I mentioned I wrote does have a queue and we use it. Though I don't quite understand what you mean under "channel buffer" term.