vrouted is normally registered as a service with inetd using the files /etc/services and /etc/inetd.conf.
An invocation of vroute runs on three nodes: the vroute client runs on a controller node (SSS-0 or SSS-1) and coordinates myrinet pings between a pair of sender and receiver targets both connected by myrinet and running the vrouted service.
Unless the -p option is used, all three nodes need to have a line like
vroute 8011/tcp
in their /etc/services file. Here, "8011" binds a specific port to vrouted service requests. The actual port number should be chosen as appropriate for a given site. In addition, the sender and receiver, i.e. the servers, should have a line like
vroute stream tcp nowait root /usr/sbin/vrouted vrouted -inetd
in their /etc/inetd.conf file. This way inetd can act as a proxy for vrouted. This simplifies operation of the client once the servers have been installed. Accordingly, the binary for vrouted should be installed in /usr/sbin on the server nodes.
As an alternative to registering vrouted as a service with inetd, it can also be run "by hand" on the sender and receiver by specifying a port with the -p switch. In this case, the vroute client should be run on the controller using the same switch.
vrouted servers learn their identity as either sender or receiver from the vroute client. Once contacted by a client the servers attempt to open a pair of devices, /dev/portals and /dev/rtscts, on the local node. Opening these devices requires that they exist as files with the appropriate permissions (normally read and write by world) and that the corresponding Linux kernel modules be loaded. vrouted also assumes that the rtscts MCP (Myrinet Control Program) is running on its local Lanai card.
When contacted, vrouted uses the portals device to find out its Cplant node id (nid), which it reports to the other server by way of the vroute client. Optionally, as determined by the client, it can verify the client's notion of the server's nid. Its main job though is, as sender, to initiate a myrinet ping or, as receiver, to check for receipt of such a message. These actions are performed by way of ioctl calls to the rtscts device. Optionally, the client may call for a follow-up ping in the reverse direction, i.e., from receiver to sender.