Thanks for the reply. I like the idea of RPC routing (like layer 3 IP
routing). You might even have routing protocols (like RPC-BGP) between
cooperating WAMP servers. Also, like routing IP, you would only route
The plan is to integrate the exchange of (dynamic) routing information within an extension to WAMP itself. So that would also run over the same underlying WebSocket/TCP fundament. Of course "normal" WAMP clients should not be able to tamper with the routing info exchanged. We should not redo the security issues that BGP has (BGP can be fooled very easily, and attackers can takeover routes etc etc). But in principle, yes, something like BGP.
to one endpoint, so you could have redundant RPC endpoints. Are you
The goal is indeed broader than "only" have 1 registered endpoint for a given URI. E.g. have multiple endpoints for the same URI, the actual endpoint routed to for a single RPC then e.g. done round-robin for load-balancing. Another pattern: send RPC to _all_ endpoints registered for the URI.
thinking of a routing language, perhaps like IOS, that manages the RPC
Currently, I've been thinking in the direction of making it as automatic, self-managed and self-healing as possible. E.g. having to manually setup routes for RPC URIs to implementing endpoints sound like an administration nightmare;) In the spirit of WAMP, I'd try to come up with the most simple design that solves the core problem. I've been contemplating about a tree shaped overlay network. That is, all WAMP nodes form a tree. A RPC that cannot be handled purely local to a WAMP node is either trickled up (parent in tree) or routed down (one or more children of tree). This could work for PubSub also. E.g. one design constraint should (IHMO) be: this stuff (WAMP federation) must work over WAN .. plain old TCP (actually WebSocket). And WAMP nodes at leaves could reside behind NAT. Like I have edge nodes running on RaspberryPi's. Those might not be reachable from "outside" (the NAT issue etc). So the only way would be for them to connect upstream to a well-defined parent node. "Well-defined": e.g. specified as command line opt.
That being said, any input, ideas etc in this context of "how to design a sane, simple, capable" routing for federated/clustered WAMP nodes is very welcome!
Am 27.11.2013 15:09, schrieb Greg Fausak:
On Wednesday, November 27, 2013 2:24:25 AM UTC-6, Tobias Oberstein wrote:
> However, if I put basically the same code in my server I can get
> call to work.
Currently, symmetric RPC only works between client and server with
And it is only implemented in AutobahnPython (not AutobahnJS, not
AutobahnAndroid, nor any other WAMP implementation I'd be aware of).
In essence, that means: you can call 1) RPC endpoint on server (ABPy)
from client (ABPy) and 2) call RPC endpoint on client (ABPy) from
> Do I need to relay the rpc between the clients using the server?
Yes, there is no automatic relaying. To really have a full-featured
"symmetric RPC", we will need RPC routing. This may involve changes to
the protocol even (see the issue collection on the WAMP GitHub repo for
this and more WAMPv2 features/discussion). Hence, symmetric RPC as it
stands isn't the "complete deal".
The full flavored thing will come together with WAMPv2. I want to
it together with routing between WAMP server instances. Another problem
that then will need to be solved: dynamic endpoint registration. Since
clients that expose RPC endpoints might then come and go. And the
routing of RPCs needs to dynamically adjust to this. And so on. It's
again a incarnation o, "hey, symmetric RPC .. sounds easy enough" -
until you look into the gory details;)
You received this message because you are subscribed to the Google
Groups "Autobahn" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to autobahnws+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.