Global Events

Question

Hi There,
I just wanted to clear something up in my mind about Forte Global Events.
By a Forte Global Event I mean an event that is posted in a method of an
EVSO.
Presumably there is no internal application logic to such a posting, as to
what machines it is destined to go to, ie, it is a straight Network
Broadcast (255.255.255.255)
1.
If this is the case, and your phsyical network consists of a number of
sub-nets, it could potentially be broadcast to all devices on all sub-nets,
assuming that your router didn't prevent this.
In order to prevent such broadcasts, presumably, the router would disable
all broadcasts destined to logical port X, which would be the port that Forte
communicates via, to all clients and servers.
Would this port X, be defined as the same port number that is used by the
NameService (?)
2.
If the above is true then presumably it would be considered better to
some application logic to direct the posting of a global event only to active
clients, ie, pass to a server cache, anchored objects from the Client, and loop through
these active clients posting an event to each.
- Carl

Answer 1

Event propagation is a favorite subject of mine.
So I'll join in this discussion.
My view is Forte Events is one of the coolest features of the
system. It is something you usually have to pay a lot
for elsewhere. But hidden in the details of Event propagation
and reception are deep issues where different vendors and
different implementation techiques can have enormously big
impacts on scalability. It turns something that seems rather
simple and benign (posting Events) into a big differentiating factor.
What Forte calls Events is called Publish/Subscribe elsewhere.
I divide Publish/Subscribe into two subclasses: Anonymous and Registered.
Anonymous Publish/Subscribe is where the publisher never knows
who is subscribed at any particular moment. The publisher
publishes blindly, as it were. Examples are Ethernet Multicast,
Radio, TV, Satellite Downlink, etc. Maybe no one is listening,
maybe the whole world. It doesn't matter to the publisher.
Registered Publish/Subscribe is where the publisher does keep
a list of subcribers and sends an individual message to each.
Examples are various forms of push technology, magazine and
periodical publishers, and Forte's event model.
Yes, Forte implements in its event model a form of Registered
Publish/Subscribe. They hide the details of the registration
and deregistration process from the programmer using their
"Post..." and "Event Loop ... When <event> " language
constructs and their sophisticated runtime system.
But everything about the registration is still there under
the covers. Forte is keeping a list of listeners and sending a
message to each one.
So what is the difference between Anonymous and Registered
publish/subscribe from a performance standpoint? From the
subscriber's vantage point, not much. You see the same message
regardless. From the network's point of view (and the publisher's)
there are big differences, especially if you are running over shared
media (such as ethernet).
With Registered Publish/Subscribe the network sees N copies
of the same message being sent, one to each registered listener.
For a large number of listeners this traffic can be
overwhelming and can choke your network.
From the publishers point of view, there is the enormous cost of creating and sending individual messages to each subscriber.
You could, if you were really clever about this, decide to
compute the message (serializing the object graphs and
all that) just once and then sending the message N times.
But I don't think Forte runtime is this clever. Nothing
prevents them from doing this in the future. In fact I
suspect this is one of the reasons Forte's designers hide
the fact of the registration process so well that you cannot
gain access to the list of registered listeners. This will allow
them in the future to tranparently swap out the costly
one-message per listener messaging
model and swap in a more efficient model based on true
Anonymous Publish/Subscribe without a change to the language.
Why is Anonymous Publish/Subscribe more efficient? Because
it uses just a single message broadcast to all destinations.
Much easier on the publisher (server) and the network.
Harder on the subscriber (client) since it receives all the
messages and must filter out the ones it is not interested in.
To solve the "all clients see everything" problem, you can
switch to multicast and provide a way to manage the mapping of
events into different multicast groups. TIBCO and other pub/sub
messaging vendors do this quite well on Ethernet to avoid flooding
every workstation with the entire multicast traffic. I'm not
trying to plug TIBCO here (they are a subsidiary of Reuters,
the company I work for). Just using them as an example of
how this can be done differently.
Footnote: of course, in order to construct the "event" message
just once and send it N times you have to implement a policy such
as "receiver makes right" or always sending "network byte order".
By definition you only generate one message. So it has to be
readable by clients of any byte order or machine architecture.
As Carl points out below, there are good reasons for using
a Registered Publish/Subscribe Model. This occcurs where you
want to perform something special for each client, such as to
send a different message or to not send (filter) the message at all.
These types of decision have to be made on a listener-by-listener
basis.
Fred Scholldorf
[email protected]
516 434 6230
Thanks to Dale V. Georg and David Bell for their quick reponses.
It appears that my assumptions were completely incorrect and that
when an object registers an event on another object in a remote
partition that Forte keeps track of this and when that event is posted,
Forte directs it to only those references.
With this in mind then, I presume that I am correct in assuming that,
1.
Global events are not as network traffic intensive, as I was lead to believe,
ie, you can actually use them, if the need arises.>
2.
it would mean that if you were to want to broadcast a global event
it would probably be more efficient to let Forte do the posting, and
not try yourself to build up a list of references to active client partitions
and post individually to them one at a time. The only time you would want
to really do this would be if you were to broadcast to a subset of
the active cilents, using a single event.
Thanks,
- Carl------------------------------------------------------------------------
Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Ltd.