omdiscd(1)                                                                                                                   omdiscd(1)  <<

NAME

       omdiscd -The omdiscd is the auto-discovery daemon for openMosix cluster.




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.




SYNOPSIS

       omdiscd

       omdiscd [--interface]or[-i]<interface>[,<interface>[,<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 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.

       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  mul-
       ticast  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.

       omdiscd [--help]or[-h]
       displays basic usage.



DOCUMENTATION

       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 multicast 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 network interface(s) are configured up and openMosix is ready to operate.
       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.
       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  acknowledge-
       ments 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 routing 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 acknowledgement mes-
       sage.

       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 broadcast, 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  multicast  group.
       Upon receipt, nodes running the auto-discovery daemon send an "acknowledgment" message to the multicast group.
       Another  approach  would be for receiving nodes to send a single UDP datagram to the sending node.  This approach has two disad-
       vantages: (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).



AUTHOR

       the auto-discovery daemon was coded by Louis Zechter
       man page created by Matt Rechenburg <mosixview@t-online.de>



REPORTING BUGS

       http://sourceforge.net/tracker/index.php?group_id=46729&atid=447171
       openMosix Bug-tracker



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 solu-
       tion 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.




SEE ALSO

       openmosix(1),  cpujob(1),  fastdecay(1),  iojob(1),  joingroup(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)





the openMosix Auto-Discovery Daemon                            28.02.2003                                                    omdiscd(1)  <<