Why doesn't WAMP support multicast RPC?

[GregRos]

A couple of days ago I was looking for a good solution for advanced local IPC and WAMP popped up. So far it's been really excellent for that task, with very low overhead and easy setup. I'm using it on Node.js, with turnpike as a router. (I looked at crossbar but was intimidated by its apparent complexity and long installation instructions).

I wish it supported multicast RPC though, where a peer sends an RPC call to multiple peers simultaneously and waits to receive responses from all callees. That's basically both the PubSub and RPC patterns together.

Is there any reason why the protocol doesn't support this?

In the end, I resorted to having several registrations for essentially the same action (with an ID suffix), one for each callee, and manually invoking these different RPC calls. E.g. rpc.1, rpc.2, etc. This works, but I feel it's really cumbersome and annoying in an otherwise really well-designed protocol. It also requires that the caller know how many callees there are, which is a downside.

Also, do you know any better workaround for doing this?

[KSDaemon]

Hi @GregRos! Thanks for ur interest in WAMP :)
Well, right now indeed it is not possible what you're asking.
There is a feature in WAMP Advanced profile, called Shared Registration, but it is designed for load-balancing and failover. You can have a look here: https://github.com/wamp-proto/wamp-proto/blob/master/rfc/text/advanced/ap_rpc_shared_registration.md

If i understand you right, what you are asking can be achieved with two pubsub topics, for one are subscribed all peers aka callees, and another one for results. One caveat in this case: you can not easily get status of your requests in case peer is down/broken/faulted.

[oberstet]

this is on the backlog of features, but we will eventually have it (it fits well into the design of WAMP, and is a logical extension): #103

[GregRos]

@oberstet That sounds great! I really hope it's added. It's a really useful feature to have.

@KSDaemon Sadly, your suggestion won't work :( There will be a problem if several peers make this sort of call at the same time. You won't be able to tell which results belong to which caller.

[KSDaemon]

@GregRos Actually, you are not right. There is a disclose_me flag, if you enable it, you can check publisher id upon receiving a message from topic. Hope it helps.

[GregRos]

@KSDaemon Still won't work if the same caller makes two calls in parallel.

Doing this would be the same as implementing WAMP's request-response RPC using any non-request-response protocol. It's not trivial and has many pitfalls. And if you do it like this, you end up implementing your own custom protocol on top of WAMP.

The method of making several RPC calls and tallying the results uses an existing request-response mechanism.

[gammazero]

As @KSDaemon suggested, it seems that a solution is to use two pub/sub topics: one that all peers (aka callees) are subscribed to, and another one for results to which the requester (aka caller) is subscribed.

The requester publishes a "status.request" event to all the clients (responders). The event can contain the topic URI that responses are to be sent to, so that the responders do not need to know this in advance. Each responder publishes its status to the response topic URI.

As @KSDaemon also states: "One caveat in this case: you can not easily get status of your requests in case peer is down/broken/faulted." This can be solved, if needed, by using the session meta api to see what sessions are present -- so that the requester knows who to expect responses from. If the requester does not see an expected response, then it can query (via direct RPC) that client for a response.

If this is a sufficient solution to your use case, then it may not be necessary to for the protocol and WAMP router implementations, to bear the complexity cost of doing essentially the same thing internally.

[oberstet]

FWIW, no, it cannot be properly simulated using PubSub

[oberstet]

How about:

---

"All" Calls

If CALL.Options.runon == "all", the call will be routed to all Callees that registered an implementing endpoint for the called procedure. The invocations will run in parallel and asynchronously.

If CALL.Options.runmode == "gather" (the default, when CALL.Options.runmode is missing), the Dealer will gather the individual results received via YIELD messages from Callees into a single list, and return that in RESULT to the original Caller - when all results have been received.

If CALL.Options.runmode == "progressive", the Dealer will call each endpoint via a standard INVOCATION message and immediately forward individual results received via YIELD messages from the Callees as progressive RESULT messages (RESULT.Details.progress == 1) to the original Caller and send a final RESULT message (with empty result) when all individual results have been received.

https://github.com/wamp-proto/wamp-proto/blob/master/_work/partitioned-registrations.md#all-calls

FWIW, there also is https://github.com/wamp-proto/wamp-proto/blob/master/_work/partitioned-subscriptions.md .. even less complete/hashed out;)