Managing NFS and NIS, 2nd Edition - Mike Eisler [98]
% ps -eaf | grep rarpd
root 274 1 0 Apr 16 ? 0:00 /usr/sbin/in.rarpd -a
Some implementations of rarpd are multithreaded, and some will fork child processes. Solaris rarpd implementations will create a process or thread for each network interface the server has, plus one extra process or thread. The purpose of the extra thread or child process is to act as a delayed responder. Sometimes, rarpd gets a request but decides to delay its response by passing the request to the delayed responder, which waits a few seconds before sending the response. A per-interface rarpd thread/process chooses to send a delayed response if it decides it is not the best candidate to answer the request. To understand how this decision is made, we need to look at the process of converting Ethernet addresses into IP addresses in more detail.
The client broadcasts a RARP request containing its 48-bit Ethernet address and waits for a reply. Using the ethers and hosts maps, any RARP server receiving the request attempts to match it to an IP address for the client. Before sending the reply to the client, the server verifies that it is the best candidate to boot the client by checking the /tftpboot directory (more on this soon). If the server has the client's boot parameters but might not be able to boot the client, it delays sending a reply (by giving the request to the delayed responder daemon) so that the correct server replies first. Because RARP requests are broadcast, they are received and processed in somewhat random order by all boot servers on the network. The reply delay compensates for the time skew in reply generation. The server that thinks it can boot the diskless client immediately sends its reply to the client; other machines may also send their replies a short time later.
You may ask "Why should a host other than the client's boot server answer its RARP request?" After all, if the boot server is down, the diskless client won't be able to boot even if it does have a hostname and IP address. The primary reason is that the "real" boot server may be very loaded, and it may not respond to the RARP request before the diskless client times out. Allowing other hosts to answer the broadcast prevents the client from getting locked into a cycle of sending a RARP request, timing out, and sending the request again. A related reason for having multiple RARP replies is that the RARP packet may be missed by the client's boot server. This is functionally equivalent to the server not replying to the RARP request promptly: if some host does not provide the correct answer, the client continues to broadcast RARP packets until its boot server is less heavily loaded. Finally, RARP is used for other network services as well as for booting diskless clients, so RARP servers must be able to reply to RARP requests whether they are diskless client boot servers or not.
After receiving any one of the RARP replies, the client knows its IP address, as well as the IP address of a boot server (found by looking in the packet returned by the server). In some implementations, a diskless client announces its IP addresses with a message of the form:
Using IP address 192.9.200.1 = C009C801
A valid IP address is only the first step in booting; the client needs to be able to load the boot code if it wants to eventually get a Unix kernel running.
Getting a boot block
A local and remote IP address are all that are needed to download the boot block using a simple file transfer program called tftp (for trivial ftp). This minimal file transfer utility does no user or password checking and is small enough to fit in the boot PROM. Downloading a boot block to the client is done from