Message Routing Paradigms
Sun Dec 15 02:19:43 CET 2002
>Thank you; yes I saw those. I think my problem is different, however.
>Rather than having a table of values that I want to match with a single
>search pattern, I have a table of search patterns that I want to match
>with a single value.
>In other words:
>Given [a,b,c], ['_',b,c], and [x,y,z] as patterns I want to find out if
>the value [a,b,c] matches anything. I have a database of patterns. I
>do not have a database of values.
>I have 1000s of patterns where one is added and dropped once a second
>and I have 10,000 values per second. So the map structure changes once
>a second and I search through it 10,000 times per second.
This is exactly what CosNotification is all about. Delivering events to
subscribers according to filtering rules. It does support the FIFO-ordering
and as a bonus is CORBA-thing and so easily integrated into heterogenous
Unfortunately, the CosNotification is quite complicated and has several
processes utilised before any single event gets through it. Every supplier
is connected to a proxy object which the event is delivered. The proxy is
an erlang process. The proxy then forwards it to it's consumer
administrator object (an erlang process), which does filtering or QoS
mappings (if required - usually not) and delivers it to the channel object
(an erlang process). As there are several suppliers, so there are several
proxy objects. Any single consumer adminstrator object can handle several
proxy objects, if they (proxies) aren't requiring anything special
handling. If there are proxies, whose events should be filtered or mapped,
one should make suitable administrator with filter or mapping-filter object
attached to it. Naturally the channel object has one or more supplier
administrators attached to it.
On the down stream, there are several consumer administrators consuming
events from a channel. Usually there are several consumer administrators
with different kind of filters, that does some coarse grained level of
filtering, attached to a channel. And every consumer administrator object
has several proxy objects (that usually make more fine grained filtering on
the objects that gets through consumer administratos filters) attached to
it. Finally, these proxy objects forwards events to consumers separately or
in batches (which increases bandwidth utilisation).
So there's several processes and lots of message copying involved in the
path from supplier to consumer. Shared heap might help with copying, but
with single processor, things might get CPU bound anyways as the filtering
language is quite expressive. Perhaps making use of several nodes (in one
SMP machine, or in cluster of single CPU machines) one could assign one
node to run proxies, supplier administrators and the channel while other
machines would have one consumer administrator and several proxies each.
Event batching should help the network performance in clustering solution.
And it does help reduce context switching (between Erlang processes)
So this is what CosNotification might do for you, but I'm not quite sure,
it fits in the whole picture.
This figure propably explains CosNotification so much more clearly than my
babling, that it is worth to check:
Student. . . . . . . . . .University of Oulu, Dept. of EE
Assistant Researcher . . .Apricot Project
"Computing is a field which has one of the shortest collective memories
of any engineering or scientific discipline." - Marty Fouts, comp.distributed
More information about the erlang-questions