symmetric rpc question

#1

Howdy,

I am playing around a bit with symmetric rpc.
I set up a server.

Then, I connect a client (a python WampClient) and register like this:

class PgExecClientProtocol(WampCraClientProtocol):

@exportRpc(“hello”)

def hello(s):

return “hello yourself %s” % ( s, )

def onSessionOpen(self):

d = self.authenticate(authKey = ‘pgexec’, authExtra = None, authSecret = ‘#T0rget!’)

d.addCallbacks(self.onAuthSuccess, self.onAuthError)

self.registerForRpc(self, “http://test.com/dbfunc#”)

Then, I connect a client (javascript) and try to call the http://test.com/dbfunc#hello, no joy :frowning:

However, if I put basically the same code in my server I can get the rpc call to work.

Do I need to relay the rpc between the clients using the server?

-g

0 Likes

#2

However, if I put basically the same code in my server I can get the rpc
call to work.

Currently, symmetric RPC only works between client and server with roles exchanged.

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 server (ABPy).

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 tackle 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;)

/Tobias

0 Likes

#3

Tobias,

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 to one endpoint, so you could have redundant RPC endpoints. Are you thinking of a routing language, perhaps like IOS, that manages the RPC route tables?

-g

···

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 the rpc

call to work.

Currently, symmetric RPC only works between client and server with roles
exchanged.

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 server
(ABPy).

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 tackle
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;)

/Tobias

0 Likes

#4

Tobias,

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
route tables?

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!

Cheers,
Tobias

···

Am 27.11.2013 15:09, schrieb Greg Fausak:

-g

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
    the rpc
     > call to work.

    Currently, symmetric RPC only works between client and server with
    roles
    exchanged.

    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
    server
    (ABPy).

     >
     > 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
    tackle
    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;)

    /Tobias

--
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.

0 Likes