CALL FOR: Multicast/Unicast
Called by: Nico Clasens Total tally on this call : +2 (+3 for 1.8)
START OF VOTING: 2004-09-22 23:00 END OF CALL: 2004-09-27 23:00
YEA (4) : Michiel Meeuwissen, Andre van Toly, Pierre van Rooden, Kees Jongenburger
YEA, 1.8 only (1) : Jaco de Groot, Gerard van Enk
ABSTAIN (0) :
NAY (2) : Rob van Maris, Rob Vermeulen, Rico Jansen
VETO (0) :
Packaging (name tbd): Called by: Pierre van Rooden Total tally on this call : +6
YEA (4) : Rico Jansen, Michiel Meeuwissen, Andre van Toly, Nico Clasens
YEA, 1.8 only (2) : Rob van Maris, Gerard van Enk
ABSTAIN (2) : Jaco de Groot, Rob Vermeulen, Kees Jongenburger
NAY (1) :
VETO (0) :
No votes, assumed abstained (16): Eduard Witteveen, Marcel Maatkamp, Johannes Verelst, Daniel Ockeloen, Mark Huijser, Ernst Bunders
Result:
The vote did not pass. While there is small minority for adding the code to 1.8 CVS HEAD, this is not without a number of demands that seem to warrant a project, or at least for teh various parties to agree on an implementation.
There is sufficient support for moving the multicast code to another package, but the definite name of that package (and any class names that may need changing) is not decided yet.
Sugegstiosn are org.mmbase.notification or org.mmbase.event.
The hack cannot be added at this moment. It can be re-submitted after suggested changes, or made into a project.
Nico Klasens wrote:
Hello Developers,
The past days I tried to get out of a political-loaded discussion with the network and firewall guys here at Vodafone. Our current production setup has an editserver and 2 frontend servers which are on different lans. The shared storage multicast implementation will not work so I had to make a unicast (direct connection) implementation. I moved the confusing multicast code around and came to the conclusion that it wouldn't be hard at all to rewrite it to a unicast implementation. I have now a multicast and unicast implementation which share most of the code. I removed the thread spawning in the implementations. The multicast implementation already used 2 queues for sending and receiving. The receiving queue was read by a thread which spawned for every message a new thread. I don't think that processing the messages in a serial way will affect much performance. The unicast implementation uses the mmservers table to lookup the active servers. It opens a connection to every server per message. This could be optimized in the future to combine the messages in the sendqueue.
Just A minute ago, I read http://www.mail-archive.com/[EMAIL PROTECTED]/msg04161.html and I think most of the stuff is covered in this implementation.
Changed source files
Moved to org.mmbase,module.core.change (new package, open for discussion) org.mmbase,module.core MMBaseChangeDummy MMBaseMultiCast MultiCastChangesReceiver MultiCastChangesSender MMBaseWaitNode (renamed from MMBaseMultiCastWaitNode) Deleted org.mmbase,module.core MMBaseMultiCastProbe Modified org.mmbase,module.builders MMServers org.mmbase,module.core MMBase MMBaseChangeInterface (Had some methods which were used only locally. Previous mails on this subject suggested to remove them.) config/modules mmbaseroot.xml (moved multicast settings to utils xml and added a sharedstorage property for an implementation class) New org.mmbase,module.core MMBaseSharedStorage MMBaseUniCast UniCastChangesReceiver UniCastChangesSender config/util multicast.xml unicast.xml
I made the changes on the 1.7 branch, because that is now running here in production. The changes can easily be applied to the HEAD.
I would like to add the changes to 1.7 and head. The code of the multicast is for 95% the same (code only moved around for readability and easy extension).
Committors: please choose one of the options below.
START OF CALL: 2004-09-22 END OF CALL: 2004-09-27
[_] +1 (YES) [_] +0 (ABSTAIN ) [_] -1 (NO), because : [_] VETO, because:
Nico Klasens
------------------------------------------------------------------------
<?xml version="1.0" encoding="iso-8859-1"?> <!DOCTYPE module PUBLIC "//MMBase - module//" "http://www.mmbase.org/dtd/module_1_0.dtd";> <!-- The MMBaseRoot module is used to configure the basic properties of mmbase. --> <module maintainer="mmbase.org" version="0">
<!-- <status> This module is always active. MMBase will not run without it. --> <status>active</status>
<classfile>org.mmbase.module.core.MMBase</classfile>
<!-- <properties> You can define properties to be used by the classfile. The properties described here are mandatory. --> <properties>
<!-- name="machinename" defines the name that is used in the mmbase cluster, it is used for the mmservers objects. Make sure that this is different for each node in your cluster. This is not the machines dns name (as defined by host as name or ip number). --> <property name="machinename">MMBaseserver</property>
<!-- name="storagemanagerfactory" defines what factory to use for accessing the storage devices. Currently. only DatabaseStorageManagerFactory is implemented, which gives access to various database devices using JDBC. Comment this property to use the old database support classes (which are deprecated). --> <property name="storagemanagerfactory">org.mmbase.storage.implementation.database.DatabaseStorageManagerFactory</property>
<!-- name="database" defines which database we are using as defined in your config databases directory (default : org/mmbase/config/default/databases/). It is defined by a xml file for example sql92.xml or mysql.xml. This should be set in combo with the jdbc.xml files (where you define the database server and how to connect to it.
sql92 for default SQL92 database (normally not used) mysql for MySQL (www.mysql.com) informix for Informix Universal Server (www.informix.com)
** remark : more database are supported or are easy to support, check www.mmbase.org's howto's on this we will complete this list as soon as possble **
MyQSL: mysql PostgrSQL: postgresql71 HyperSonic: hypersonic --> <!-- TODO: Why is this setting not in the jdbc.xml? --> <!-- property name="database">mysql</property -->
<!-- name="sharedstorage" the MMBaseChangeInterface which communicates with other MMBase instance which use the same storage --> <property name="sharedstorage">org.mmbase.module.core.change.MMBaseMultiCast</property>
<!-- name="multicastttl" sets the Time To Live for a datapackage send by a Multicast. Time to live determines the number of hops a package can make. The default, 1, is generally enough, but higher values may be needed on some networks. --> <property name="multicastttl">1</property>
<!-- name="host" the host or ip number of the machine this mmbase node is running on. Its important that this name is set correctly because its used for communication between mmbase nodes and external devices (xml or jini based). --> <property name="host">127.0.0.1</property>
<!-- name="authtype" defines what authorisation type is used, This is a plugin system at the moment we only support 2 types :
none (only perform name/password checks based on accounts.properties)
basic (use the default authorisation system, based on groups and relations see the install/example docs how to enable this DON'T set it before creating the needed tables/objects as defined in these docs). --> <property name="authtype">none</property>
<!-- name="dtdbase" defines the homebase for the DTD's used by the objects (urls, cdtracks, images etc etc). Normally this is set to www.mmbase.org but you can aim it to your own system if you defined extra objects yourself. Its not used at the moment for anything vital. --> <property name="dtdbase">http://www.mmbase.org/dtd/</property>
<!-- name="basename" You can have multiple mmbase systems inside your database if you want this can be very handy when testing of for running multiple setups inside one database its added as a preset to all your table names like : BASENAME=test will result in table names like test_object and test_urls. --> <property name="basename">mm</property>
<!-- name="language" defines the language for the gui. The standard gui information for the editors can be found in /config/modules/mmlanguage.xml. The gui information of a builder is provided by the builder itself (e.g. /config/builders/urls.xml). --> <property name="language">nl</property>
<!-- name="encoding"
The encoding to be used in the database (if the database layer needs to know), and for use as default for the pages. Recommended is 'UTF-8', since this can be used for virtually every language on the world, and is a superset of ASCII.
Default though, it is ISO-8859-1, to ensure backwards
compatibility. Perhaps this will change to UTF-8 once this is
tested well.
-->
<!-- since, when not mentioned it will be ISO-8859-1, all new systems will get utf-8 -->
<property name="encoding">UTF-8</property>
<!--
name="xmlbuilderwriterdir"
If specified, MMBase will write xml configuration files to this directory when loading builders.
This can be useful if you want to convert old format builder xmls to the new format.
-->
<!-- property name="xmlbuilderwriterdir">/home/guest/schooltv/tmpbul/</property -->
</properties> </module>
------------------------------------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE util PUBLIC "-//MMBase//DTD util config 1.0//EN" "http://www.mmbase.org/dtd/util_1_0.dtd";>
<util>
<!--
What is Multicast?
Multicast is essentially the ability to send one IP packet to multiple receivers. Multicast is often used
for audio and video conferencing systems. You often hear about the Mbone in reference to Multicast. The Mbone
is essentially a ``virtual backbone'' which exists in the Internet itself. If you want to send and/or receive
Multicast, you need to be ``on the Mbone.''
Things to remember:
1 Multicast tunnels/configurations/infrastructure are often unstable. You may lose multicast connectivity
but still have unicast connectivity.
2 Multicast does not reduce the number of ICP replies being sent around. It does reduce the number of ICP
queries sent, but not the number of replies.
-->
<properties>
<!--
name="multicasthost" mmbase nodes in a cluster use multicast to talk to
eachother this defines what 'channel' we are talking to its now set
to the default local network so unless you know what you are doing
leave it to ALL-SYSTEMS.MCAST.NET else use a multicat IP address like this
<property name="multicasthost">224.0.0.1</property>
-->
<property name="multicasthost"></property><!-- ALL-SYSTEMS.MCAST.NET -->
<!--
name="multicastport" on what port does this multicast talking between servers
take place, This can be set to any port but check if something else on
your network is allready using multicast when you have problems.
-->
<property name="multicastport">16080</property>
<!--
name="multicastTTL" The Multicast TTL determines how ``far'' your ICP queries will go.
In the Mbone, there is a certain TTL threshold defined for each network interface or tunnel.
A multicast packet's TTL must be larger than the defined TTL for that packet to be forwarded across that link. For example, the mrouted manual page recommends:
32 for links that separate sites within an organization.
64 for links that separate communities or organizations, and are
attached to the Internet MBONE.
128 for links that separate continents on the MBONE.
A good way to determine the TTL you need is to run mtrace and look at the last line. It will
show you the minimum TTL required to reach the other host. Mtrace can be downloaded from
Xerox PARC FTP site (ftp://parcftp.xerox.com/pub/net-research/ipmulti/)
If you set you TTL too high, then your ICP messages may travel ``too far'' and will be subject
to eavesdropping by others. If you're only using multicast on your LAN, as we suggest, then your
TTL will be quite small, for example ttl=4.
-->
<property name="multicastTTL">1</property>
<!--
name="dpsize" Datapacket receive size 64*1024
-->
<property name="dpsize">65536</property>
</properties> </util>
------------------------------------------------------------------------
<?xml version="1.0"?> <!DOCTYPE util PUBLIC "-//MMBase//DTD util config 1.0//EN" "http://www.mmbase.org/dtd/util_1_0.dtd";> <util> <properties> <!-- name="unicastport" on what port does this multicast talking between nodes take place, This can be set to any port but check if something else on your network is allready using multicast when you have problems. --> <property name="unicastport">16080</property> <!-- name="unicasttimeout" the time another MMbase server has to respond. --> <property name="unicasttimeout">10000</property> </properties> </util>
-- Pierre van Rooden Mediapark, C 107 tel. +31 (0)35 6772815 "Never summon anything bigger than your head."
