The arp Command Address Resolution ARP

All cached data are kept in the ARP table for only a certain period of time the time−out period, which lasts for a few seconds; once the time−out period expires, the corresponding entry is deleted. Once an entry is deleted, ARP must query for the very same data as if it had never been in the table. Permanent ARP table updating makes the ARP procedure independent of the changes in the network; otherwise, a simple replacement of a broken network card would not be possible an Ethernet address is a part of the network interface, so by replacing the network interface card, another Ethernet address is automatically associated with the corresponding IP address.

15.2.1 The arp Command

The arp command displays and controls the contents of the IP−to−Ethernet address translation table used by the ARP protocol. Several forms of the command are available: arp [−d] hostname arp −s hostname ethaddr [temp] [pub] [trail] arp −a arp −f filename where with no options, arp displays the current ARP entry for hostname. The options are: −a Display all of the current ARP entries by reading the table from the kernel. −d Delete an entry for hostname. −s Create an ARP entry for hostname with the Ethernet address ethaddr. The entry will be permanent unless the temp option is given in the command. If the pub option is given, the entry will be published; for instance, this system will respond to ARP requests for hostname even though the hostname is not its own. The trail option indicates that trailer encapsulations may be sent to this host. −f Read the file named filename and set multiple entries in the ARP table; entries in the file should be of the form: hostname ethaddr [temp] [pub] [trail] with the argument meanings as given above, under the −s option. Here are two examples: arp −a SunOSSolaris hcprophet 146.95.1.2 at 8:0:20:0:9b:4d rs01−ch 146.95.1.21 at 2:60:8c:2f:48:db ? 146.95.6.73 at 0:0:89:0:3e:4 bjl.ph.hunter.cuny.edu 146.95.8.11 at 0:0:1d:a:e5:6c pegasus.hunter.cuny.edu 146.95.1.12 at 8:0:20:1f:39:46 denboer.ph.hunter.cuny.edu 146.95.8.12 at 0:0:1d:b:53:e2 default 146.95.1.15 at 0:0:0:0:8b:8b indigo1.ch 146.95.6.15 at 8:0:69:6:b4:84 arp −a HP−UX levi.ph.hunter.cuny.edu 146.95.8.11 at 0:0:1d:a:e5:6c ether pegasus.hunter.cuny.edu 146.95.1.12 at 8:0:20:1f:39:46 ether denboer.ph.hunter.cuny.edu 146.95.8.12 at 0:0:1d:b:53:e2 ether hcgate1.hunter.cuny.edu 146.95.1.15 at 0:0:0:0:8b:8b ether physpc1.ph.hunter.cuny.edu 146.95.8.28 at 0:0:1d:b:45:6a ether 351 Remote Procedure Call RPC provides a mechanism for a host to make a procedure call that appears to be a part of the local process, while it is really executed on another, remote host in the network. The net effect is the impression that everything is executing strictly locally, although the requested resources are far apart and can be reached only through the network. Typically, the host on which the procedure call is executed has resources that are not available on the calling host. This distribution of computing services imposes a clientserver relationship on the two hosts: the host owning the resource is a server for that resource, and the calling host becomes a client that needs access to the resource. Procedure is a relatively closed program entity used in C programming, with well−defined input and output. It is very common to call a procedure from some other program to complete a certain task. Originally the calls were placed locally, and we used the term local procedure calls to identify them. Networking introduced a new distributed environment that offered to extend existing local applications over several remote hosts. The procedure was a logical choice for such an extension. By replacing the local procedure call with an equivalent remote procedure call, the rest of the application could remain more or less unchanged and still operational. Sun Microsystems recognized this idea, and the remote procedure call RPC became a standard used in networking; sometimes it is even referred to as Sun RPC. Figure 15.4 illustrates the difference between local and remote procedure calling. 352 RPC services may be built on either TCP or UDP transport protocols, although most are UDP−oriented. The reason is because RPC services are mostly centered on short−lived requests. Using UDP forces the RPC to contain enough context information for its execution, independent of any other RPC request, since UDP packets may arrive in any order, if at all. The client may also specify a time−out period in which the remote call must be completed. Various actions can be taken if a server does not reply in the predefined time interval; the action taken depends on the application itself. Once the concept of RCP is clear, the next logical question is: When should RCP be implemented? Does each network−based application rely on RPC, and what is a benefit of using an RPC? The following statement could help to explain these matters. A number of new network applications were created once networking become widely implemented; these applications were designed from scratch, respecting all network restrictions, specifications, and standards. These applications were run only in the distributed network environment. On another side, a number of existing local applications had to be extended and adapted to the new distributed environment. These applications were designed in a different way, they were locally oriented, and sometimes came from different host platforms; however, they had something in common: they were and are using local procedure calls in interprocess communications. The easiest way to extend them to the distributed environment and to keep full compatibility with the local environment has been to make procedures to circumvent the problem — to provide an appropriate program interface to adapt local applications to the network environment, and to keep local program characteristics intact. Thus the remote procedure call RCP was born. RPC services are usually connectionless UDP−oriented services, because RPC requests do not require the creation of a long−lived network connection between the client and the server. The client communicates with the server sends its request and receives a reply in a connectionless fashion. However, RPC can also run over TCP, in a connection−oriented fashion. The TCP protocol may be used with RPC services whenever a large amount of data needs to be transferred for example, NIS uses UDP, but it switches to TCP whenever it needs to transfer entire database to remote hosts. RPC servers are generally started during system booting and run as long as the system is up. An efficient RPC operation cannot tolerate the time overhead caused by the start of a new server process when such a service is required. As a result, RPC servers are single−treated, i.e., there is one server process for the RPC service, and it executes remote requests from the client one at a time. To achieve better performance, two or more copies of the same RPC server may be started during the system startup, but each server still handles only one request at a time. There may be many clients of the RPC server, but their requests wait in the RPC server queue and are processed in the order in which they are received. 353

15.3.1 The portmapper Daemon