.\"the openMosix Auto-Discovery Daemon by Louis Zechter .\"http://openmosix.sourceforge.net/ .\" .TH omdiscd 1 "28.02.2003" "the openMosix Auto-Discovery Daemon" .SH NAME omdiscd \-The omdiscd is the auto-discovery daemon for openMosix cluster. .SH DESCRIPTION The auto-discovery daemon is a user level program to allow multiple hosts on a single network (for now) to become aware of each other. When a host running auto-discovery becomes aware of another host's existence, it can inform the openMosix kernel. The openMosix kernel can then add it to its internal map of existing machines. .br .SH SYNOPSIS .P .B omdiscd .br .P .B omdiscd .RI [ --interface ] or [ -i ] [,[,]...]]: .br The interface option can be used to specify between one and six interfaces which will be used in the openMosix cluster. It is specified as a comma separated list. Each interface listed will receive and send multicast notifications, unless the "-m" or "--multicast-ttl" option is specified. In that case, only the first interface listed will send and receive messages, and others will be configured as openMosix aliases. When this option is not specified, auto-discovery will allow the kernel to select a default interface. This option is not necessary when a host only has one configured interface. .br .P .B omdiscd .RI [ --nodaemon ] or [ -n ] .br The nodaemon option causes auto-discovery to run in the foreground, and not as a daemon. All output will go to standard error, as opposed to syslog when running as a daemon. .br .P .B omdiscd .RI [ --multicast-ttl ] or [ -m ] .br When this option is specified, the value passed is used as the time-to-live (TTL) for multicast. This option assumes that multicast routing is configured on gateways connecting clusters. When it is specified, auto-discovery configured with multiple interfaces will only send and recieve notifications on one interface. .br .P .B omdiscd .RI [ --help ] or [ -h ] .br displays basic usage. .br .SH DOCUMENTATION .P .B Node-id Generation .br Node identifiers are generated by taking the last two octets of the IP address of a given machine. The obvious problem with this is potential node-id collisions, which I think will not arise in most clusters. .P .B Routing .br When auto-discovery is doing routing of messages between networks, there is no routing loop detection---in fact, the route that the auto-discovery messages take may be different than the traffic between the openMosix nodes. For anything but a very simple network, use of real multicast routing (e.g. mrouted) is recommended. .P .B Messaging .br The initial implementation of the node discovery protocol is minimal. When a new node is initialized (when node discovery is activated), the following sequence of events occurs. .br 1. The new node is initialized, which means that its network interface(s) are configured up and openMosix is ready to operate. .br 2. The new node sends a "join" message to all other openMosix nodes signifying its existence. Receiving nodes can then add the sending to their map. OpenMosix has the concept of interface aliases. If a host has can send packets with different source addresses on the same network, and would like other nodes on the network to recognize them as the same host, then an alias entry mapping one node identifier to two interface addresses can be specified. As part of a join message, up to six aliase entries can be specified. Hosts will keep track of these addresses in order to know how to set their "number of gateway" entries, as well as aliases. .br 3. Each receiving node can then respond by sending an "acknowledgment" broadcast message to all openMosix nodes signifying its existence. This broadcast helps nodes maintain more accurate maps. The same alias information can be passed with acknowledgements as with joins. .br 4. [ not implemented or decided ] Before a node becomes unavailable, it can send a "leaving" message to all other nodes. Other nodes can remove the departing node from their map, along with its aliases, and gateway entries. .br .P .B Message Structure .br The structure of all messages (payload of each datagram) sent by auto-discovery is as follows: .br (This is a future structure, currently the mskX fields are not there) .br 0000 0000 0011 1111 1111 2222 2222 2233 3333 3334 4444 4444 4544 5 .br 0123 4567 8901 2345 6789 0123 4567 8901 2345 6890 1234 5678 9012 3 .br +----+----+----+----+----+----+----+----+----+----+----+----+----+-+ .br +mgcn|src |msk |ifn1|msk1|ifn2|msk2|ifn3|msk3|ifn4|msk4|ifn5|msk5|t| .br +----+----+----+----+----+----+----+----+----+----+----+----+----+-+ .br .P Definition of fields: .br 1. mgcn: a magic number to aid in verifying integrity of a message. If a preset magic number is not the first four bytes of the payload of a packet, it is discarded. .br 2. src: the source address of the message. This is used instead of the SRC in the IP header because it makes routing easier. .br 3. msk: the netmask for the source address. .br 4. ifnX: Interface alias fields. Each of these fields is an interface which nodes should consider an alias for the source address of the datagram. If there are no aliases, these fields are set to zero. .br 5. mskX: The respective netmask for each ifnX. .br 4. t: A type field describes the type of a message. Valid types are 'j' for a join message, and 'a' for an acknowledgement message. .br .P .B Communication .br All nodes in the openMosix cluster will join a multicast group to be used for auto-discovery communication. In many clusters this will effectively be a routeable broadcast, because all nodes will join the multicast group. .br When a auto-discovery is activated (the auto-discovery daemon is started), it sends a "join" message to the multicast group. Upon receipt, nodes running the auto-discovery daemon send an "acknowledgment" message to the multicast group. .br Another approach would be for receiving nodes to send a single UDP datagram to the sending node. This approach has two disadvantages: (1) it does not necessarily reduce traffic because of potential ARP requests, and (2) does not have the benefit of aiding correction of other node maps, perhaps due to a lost datagram. .br .P .B Interaction with openMosix Kernel .br The auto-discovery daemon communicates with the openMosix kernel by reading and writing to /proc/mosix (/proc/hpc). .br .SH AUTHOR the auto-discovery daemon was coded by Louis Zechter .br man page created by Matt Rechenburg .SH REPORTING BUGS .B http://sourceforge.net/tracker/index.php?group_id=46729&atid=447171 .br openMosix Bug-tracker .br .SH LICENCE openMosix is the GPLv2, Open Source, project to extend the outstanding MOSIX project. New releases of MOSIX became proprietary software in late 2001 and openMosix was begun February 10, 2002 by Moshe Bar to keep this highly regarded Linux Clustering solution available as open source. .br Legal openMosix is Copyright (c) 2002, 2003 by Moshe Bar. .br Mosix is Copyright (c) 2002 by Amnon Barak. The Mosix is a trademark of Amnon Barak. Linux is a Registered Trademark of Linus Torvalds. openMosix is licensed under version 2 of the GNU General Public License as published by the Free Software Foundation. .br .SH SEE ALSO openmosix(1), cpujob(1), fastdecay(1), iojob(1), joingroup(1), migrate(1), migrategroup(1), mon(1), mosctl(1), mosrun(1), mps(1), mtop(1), nodecay(1), nomig(1), omdiscd(1), resetgroup(1), runhome(1), runon(1), setpe(1), showgroup(1), slowdecay(1) .br