Model at work

Dec 16, 2009 at 2:20 AM

While going through the Ping Pong sample, it appears that the event type is the key way of tying a publisher and a subscriber.  Is this a correct conclusion?

If so - I presume that you handle the scenario of controlling who handles the same event by the parent?  Do you then setup a topology of parents, e.g. a central parent that knows about everyone, and can be a sort of library lookup for the other systems, and then you say parentX will handle all eventZ that pertain to customers of group X, parentyY will handle all eventZ that pertain to group Y, and so on.

Btw, thanks for the quick replies to my other questions.  It has helped me to understand things quickly :-)

Dec 16, 2009 at 2:47 AM

The servers are in a pure tree hierarchy. B and C might have A as their parent. A might have D as its parent. E and F might also have D as their parent. When an application subscribes to an event (guid), a subscription event is essentially broadcast to all nodes to build up routing tables. You can have as many nodes subscribing to the same event as you want. When the event is published, it flowed throughout the node hierarchy as is necessary to reach all subscribers.

So arranging the servers (nodes) in a hierarchy simply creates the communication infrastructure. Subscriptions dynamically build up routing tables to effeciently route the events when they are published.

Also, the event ids (guids) can be set statically in your class or at run time by setting the property.

Dec 16, 2009 at 3:13 AM

Lets say that I had a generic Event like a progress event, and I wanted to pass progress percentages from machine C to machine F, and machine D to machine E -- where all machines have the same parent B.  Is there a way to make sure that E does not receive C's progress events, and that F does not receive D's -- and still use the same Event?  E.g. is there a way to mask or filter the recipients?

Dec 16, 2009 at 3:32 AM

You either have to assign guid1 for interaction between C and F and guid2 for interaction between D and E. Or you publish the same event type from C and D and E and F would have to do their own filtering. I though don't want to do content-based routing because of perf and complexity.

Dec 16, 2009 at 4:06 AM

Thanks, I was thinking something long the line of guid1/2, and treating the Event level as a transport level for the actual messages.  I have been looking at this after having found Zmq to be insufficient a few months back (primarily in reliability), and pleased that this system has been used in the wild for a while :-)  -- but also my questions will come from having had a system geared around that strategy.