5 IP: Global Software OrganizationOrganization
5.7 Table Maintenance
send(ippid, (pni-&nif[0]));
return OK;
}
Given a pointer to a buffer that contains a packet, ip_in calls enq to enqueue the packet on the queue in the interface. If the queue is full, ip_in increments variable IpInDiscards to record the queue overflow error and discards the packet. Finally, ip_in sends a message to the IP process in case it is blocked waiting for a datagram.
5.7 Table Maintenance
IP software needs a timing mechanism for maintenance of network data structures, including the IP routing table and fragment reassembly table. Our example implements such periodic tasks with a timer process. In fact, the timer is not limited to IP tasks — it also triggers ARP cache timeouts, and can be used for any other long-term periodic tasks that do not have stringent delay requirements. The code, in procedure slowtimer, shows how easily new tasks can be added to the list.
/* slowtimer.c - slowtimer */
#include <conf.h>
#include <kernel.h>
#include <proc.h>
#include <network.h>
#define STGRAN 1 /* Timer granularity (delay) in seconds */
* slowtimer - handle long-term periodic maintenance of network tables */
PROCESS slowtimer() {
long lasttime, now; /* previous and current times in seconds*/
int delay; /* actual delay in seconds */
signal(Net.sema);
gettime(&lasttime);
while (1) {
sleep(STGRAN);
gettime(&now);
delay = now - lasttime;
if (delay <= 0 || delay > 4*STGRAM)
delay = STGRAM; /* likely clock reset */
lasttime = now;
arptimer(delay);
ipftimer(delay);
rttimer(delay);
ospftimer(delay);
} }
As the code shows, slowtimer consists of an infinite loop that repeatedly invokes a set of maintenance procedures. A given maintenance procedure may take arbitrarily long to complete its chore, and the execution time may vary between one invocation and the next. Thus, slowtimer computes the actual delay between executions and reports it to the maintenance procedures as an argument.
5.8 Summary
To simplify the code, our implementation of IP executes as a single, independent process, and interaction with higher-level protocol software on the local machine occurs through a pseudo-network interface. When no datagrams are available, the IP process blocks. As soon as one or more datagrams are available from any source, the IP process awakens and processes them until they have all been routed. To make processing fair and avoid starvation, our implementation uses a round-robin policy among input sources, including the pseudo-interface that corresponds to the local machine. Thus, neither locally generated traffic nor incoming traffic from the network connections has priority.
Directed broadcasting means delivery to all hosts and gateways on the specified network. The protocol standard allows designers to decide whether to forward directed broadcasts that originate on foreign networks. If the gateway chooses to allow directed broadcasts, it routes them as usual. If the destination address specifies a directly connected network, IP must be sure that higher-level protocol software on the local machine receives a copy of the datagram. To increase its utility, our example implementation allows either the TCP/IP standard (all 1's) or 4.2 BSD UNIX (all 0's) forms of broadcast address. It creates a copy of a broadcast datagram and arranges for the network interface to broadcast the copy, while it routes the original to protocol
software on the local machine.
The IP checksum consists of a 16-bit 1's complement value that can be computed using 32-bit 2's complement arithmetic and carry propagation.
5.9 FOR FURTHER STUDY
The standard for IP is found in Postel [RFC 791]. Braden and Postel [RFC 1009]
summarizes requirements for Internet gateways. Mallory [RFC 1141] discusses incremental update of IP checksums. Braden, Borman, and Partridge [RFC 1071] gives an earlier discussion. Mogul and Postel [RFC 950] gives the standard for subnet addressing. Padlipsky [RFC 875], and Hinden and Sheltzer [RFC 823] describe early ideas about gateways.
5.10 EXERCISES
1. One's complement arithmetic tins two values for zero. Which will cksum return?
2. Rewrite cksum in assembly language. How does the speed compare to a version written in C?
3. Consider an implementation that uses a single input queue for all datagrams sent to IP. What is the chief disadvantage of such a solution?
4. Study the code in procedure ipproc carefully. Identify all instances where a datagram sent to/from the local machine it treated as a special case.
5. Can any of the special eases in the previous exercise be eliminated by requiring higher-level protocols to perform computation(s) when they enqueue a datagram for ouput?
6. Show that it is possible for ipproc to make one last iteration through all interfaces even though there are not datagrams waiting to be processed. Hint:
consider the timing between the IP process and a device driver that deposits a datagram and sends IP a message.
7. Consider the AT&T STREAMS mechanism used to build device driver and protocol software. Can it be used to implement IP? How?
8. What is the chief advantage of implementing IP in an independent process?
What is the chief disadvantage?
9. Procedure ipsend supplies a fixed value for the time-to-live field in the datagram header. Is this reasonable?
10. Look carefully at the initial value used for the datagram identification field.
Argue that if a machine boots, sends a datagram, crashes, quickly reboots and
sends a different datagram to the same destination, fragmentation can cause severe errors
11. Procedure ip_in discards an incoming datagram when it finds that an interface queue is full. Read the RFC to determine whether IP should generate an error message when the situation occurs.
12. Design a minor modification to the code for slowtimer that produces more accurate values in calls to maintenance procedures. What are the advantages and disadvantages of each implementation?