WAMP V2 concept discussion

#1

I had another read of the spec, it is looking real good!

Looking at the general concepts, there is a dealer that routes stuff. I guess there is a central dealer in any deployment to which all other things connect? Forgetting for the moment the concept of rpc, the broker is what my clients connect to. My clients then engage in publish and subscribe, a broker routing the messages between them. Here is broker A. So far this is exactly like V1. Now, V2: the broker is also connected to the Dealer.

So, now I add another broker to the mix, connect it to the dealer, and it now hosts a happy party of publishers and subscribers. I think I get that. Let’s call this one broker B.

This is where I get a little unclear (unless the assertions above are already off base :-)) I am a client on brokerA, I subscribe to a message that will be published from a client on BrokerB. That just happens? Does that make the Dealer a router? The broker’s ‘advertise’ routes (like BGP)?

Given I am not too far off in the weeds. What if I add another Dealer (dang, weed and dealer in the same sentence)? Can a broker communicate with more than one dealer? Does this give us routing path redundancy?

Given that a Dealer can be a Broker, I can fan out my deployment model. Would I expect to see a lot of traffic in the center of that model, or, is it truly routing (all messages aren’t just being broadcast everywhere)? If it’s routing, that is pretty complicated, very similar to BGP/OSPF/etc. There would need to be the notion of routing tables at the Brokers?

-g

0 Likes

#2

I had another read of the spec, it is looking real good!

Looking at the general concepts, there is a dealer that routes stuff. I
guess there is a central dealer in any deployment to which all other
things connect? Forgetting for the moment the concept of rpc, the broker
is what my clients connect to. My clients then engage in publish and
subscribe, a broker routing the messages between them. Here is broker
A. So far this is exactly like V1. Now, V2: the broker is also
connected to the Dealer.

Brokers route events between publishers and subscribers.

Dealers route calls and results between callers and callees.

Routers is just the general term that encompasses both brokers and dealers.

So, now I add another broker to the mix, connect it to the dealer, and
it now hosts a happy party of publishers and subscribers. I think I get
that. Let's call this one broker B.

This is where I get a little unclear (unless the assertions above are
already off base :-)) I am a client on brokerA, I subscribe to a
message that will be published from a client on BrokerB. That just
happens? Does that make the Dealer a router? The broker's 'advertise'
routes (like BGP)?

No, router-to-router messaging which allows this kind of clustering on multiple nodes is not part of the WAMP spec., but specific to a given WAMP router implementation. The basic router that is included with Autobahn>Python doesn't do clustering. Crossbar.io will have that functionality.

Given I am not too far off in the weeds. What if I add another Dealer
(dang, weed and dealer in the same sentence)? Can a broker communicate
with more than one dealer? Does this give us routing path redundancy?

Yes, Crossbar.io will be able to route a call e.g. like this:

Caller ---> CB1 ---> CB2 ---> Callee

Given that a Dealer can be a Broker, I can fan out my deployment model.
  Would I expect to see a lot of traffic in the center of that model,
or, is it truly routing (all messages aren't just being broadcast
everywhere)? If it's routing, that is pretty complicated, very similar
to BGP/OSPF/etc. There would need to be the notion of routing tables at
the Brokers?

Crossbar.io is built around a fully connected mesh of router instances. The goals are scale-out and high-availability. So this is not like routing protocols which work across wide areas and multiple administrative domains, but a tightly connected cluster.

I am pretty aware that above description is in no way comprehensive and will trigger more questions;) Essentially, it will be in the docs for Crossbar.io ..

/Tobias

···

Am 08.02.2014 18:45, schrieb Greg Fausak:

-g

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

#3

I had another read of the spec, it is looking real good!

Looking at the general concepts, there is a dealer that routes stuff. I

guess there is a central dealer in any deployment to which all other

things connect? Forgetting for the moment the concept of rpc, the broker

is what my clients connect to. My clients then engage in publish and

subscribe, a broker routing the messages between them. Here is broker

A. So far this is exactly like V1. Now, V2: the broker is also

connected to the Dealer.

Brokers route events between publishers and subscribers.

Dealers route calls and results between callers and callees.

Ah, that clears it up.

Routers is just the general term that encompasses both brokers and dealers.

So, now I add another broker to the mix, connect it to the dealer, and

it now hosts a happy party of publishers and subscribers. I think I get

that. Let’s call this one broker B.

This is where I get a little unclear (unless the assertions above are

already off base :-)) I am a client on brokerA, I subscribe to a

message that will be published from a client on BrokerB. That just

happens? Does that make the Dealer a router? The broker’s ‘advertise’

routes (like BGP)?

No, router-to-router messaging which allows this kind of clustering on
multiple nodes is not part of the WAMP spec., but specific to a given
WAMP router implementation. The basic router that is included with
Autobahn>Python doesn’t do clustering. Crossbar.io will have that
functionality.

I see.

Given I am not too far off in the weeds. What if I add another Dealer

(dang, weed and dealer in the same sentence)? Can a broker communicate

with more than one dealer? Does this give us routing path redundancy?

Yes, Crossbar.io will be able to route a call e.g. like this:

Caller —> CB1 —> CB2 —> Callee

Given that a Dealer can be a Broker, I can fan out my deployment model.

Would I expect to see a lot of traffic in the center of that model,

or, is it truly routing (all messages aren’t just being broadcast

everywhere)? If it’s routing, that is pretty complicated, very similar

to BGP/OSPF/etc. There would need to be the notion of routing tables at

the Brokers?

Crossbar.io is built around a fully connected mesh of router instances.

The goals are scale-out and high-availability. So this is not like
routing protocols which work across wide areas and multiple
administrative domains, but a tightly connected cluster.

It seems to me that it would be extremely useful to connect together (dealer/broker) instances. Maybe a common client with the authority to do the inspection/reflection on each connected instance with some sort of rules on how/what to message between them.

Thanks for the follow up.

-g

···

On Sunday, February 9, 2014 2:44:00 PM UTC-6, Tobias Oberstein wrote:

Am 08.02.2014 18:45, schrieb Greg Fausak:

I am pretty aware that above description is in no way comprehensive and
will trigger more questions;) Essentially, it will be in the docs for
Crossbar.io

/Tobias

-g

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

#4

    Crossbar.io is built around a fully connected mesh of router instances.

    The goals are scale-out and high-availability. So this is not like
    routing protocols which work across wide areas and multiple
    administrative domains, but a tightly connected cluster.

It seems to me that it would be extremely useful to connect together
(dealer/broker) instances. Maybe a common client with the authority to
do the inspection/reflection on each connected instance with some sort
of rules on how/what to message between them.

Not sure if I can follow ..

The cluster interconnect with Crossbar.io already connects together multiple dealer/broker instances.

However, it makes a few assumptions like:

- all instances (nodes) do trust each other
- interconnect is direct and relatively fast
- cluster forms a single admnistrative domain

So given above, you still mean something else? Like routing between whole clusters which are under different administration? And hence more something like federation?

If so, could you explain the use case a little and what you are after?

/Tobias

0 Likes