omdiscd(1) omdiscd(1) >>
omdiscd -The omdiscd is the auto-discovery daemon for
openMosix cluster.
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.
omdiscd
omdiscd [--interface]or[-i]<interface>[,<inter-
face>[,<interface>]...]]:
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 notifica-
tions, 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 config-
ured as openMosix aliases. When this option is not speci-
fied, auto-discovery will allow the kernel to select a
default interface. This option is not necessary when a
host only has one configured interface.
omdiscd [--nodaemon]or[-n]
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.
omdiscd [--multicast-ttl]or[-m]
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 connect-
ing clusters. When it is specified, auto-discovery con-
figured with multiple interfaces will only send and
recieve notifications on one interface.
omdiscd [--help]or[-h]
displays basic usage.
Node-id Generation
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.
Routing
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 multi-
cast routing (e.g. mrouted) is recommended.
Messaging
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.
1. The new node is initialized, which means that its net-
work interface(s) are configured up and openMosix is ready
to operate.
2. The new node sends a "join" message to all other open-
Mosix nodes signifying its existence. Receiving nodes can
then add the sending to their map. OpenMosix has the con-
cept 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 iden-
tifier 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.
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.
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.
Message Structure
The structure of all messages (payload of each datagram)
sent by auto-discovery is as follows:
(This is a future structure, currently the mskX fields are
not there)
0000 0000 0011 1111 1111 2222 2222 2233 3333 3334 4444
4444 4544 5
0123 4567 8901 2345 6789 0123 4567 8901 2345 6890 1234
5678 9012 3
+----+----+----+----+----+----+----+----+----+----+----+----+----+-+
+mgcn|src |msk
|ifn1|msk1|ifn2|msk2|ifn3|msk3|ifn4|msk4|ifn5|msk5|t|
+----+----+----+----+----+----+----+----+----+----+----+----+----+-+
Definition of fields:
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.
2. src: the source address of the message. This is used
instead of the SRC in the IP header because it makes rout-
ing easier.
3. msk: the netmask for the source address.
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.
5. mskX: The respective netmask for each ifnX.
4. t: A type field describes the type of a message. Valid
types are 'j' for a join message, and 'a' for an acknowl-
edgement message.
Communication
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 broad-
cast, because all nodes will join the multicast group.
When a auto-discovery is activated (the auto-discovery
daemon is started), it sends a "join" message to the mul-
ticast group. Upon receipt, nodes running the auto-dis-
covery daemon send an "acknowledgment" message to the mul-
ticast group.
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.
Interaction with openMosix Kernel
The auto-discovery daemon communicates with the openMosix
kernel by reading and writing to /proc/mosix (/proc/hpc).
the auto-discovery daemon was coded by Louis Zechter
man page created by Matt Rechenburg <mosixview@t-
online.de>
http://source-
forge.net/tracker/index.php?group_id=46729&atid=447171
openMosix Bug-tracker
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.
Legal openMosix is Copyright (c) 2002, 2003 by Moshe Bar.
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.
openmosix(1), cpujob(1), fastdecay(1), iojob(1), join-
group(1), migrate(1), migrategroup(1), mosmon(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)
Last modified: Fri, 01 Oct 2004 - 15:24:14 CEST