We make numerous simplifying assumptions in this example implementation for the sake of brevity. Specifically, we do not actually send or receive packets over the network.
We simulate this with a packet trace. That is, we read from an input file representing a simplified packet record containing only the relevant fields of a packet. The fields include values from the IP header, TCP header, and certain application payload information. This allows us to focus on the parts of the application that we want to pipeline. Furthermore, for the application stages themselves, we implement only sufficient functionality to provide insight into the benefits of pipelining.
In terms of NAT, we implement only a simplified version of NAPT. We do not delete mapping entries in the table once a connection has been closed, which a real implementation would do in order to reuse port numbers.
In terms of ALG, we consider only an FTP ALG in this example. Specifically, we look at the PORT command in an active FTP connection wherein the client sends its IP address and port information in the packet payload. We do not update the check-sum and other header information that a real implementation would have to modify when the packet payload is modified.
Nevertheless, this example demonstrates how a pipeline class would be used and how it would benefit a programmer creating a real packet processing application.
Figure 11-20 through Figure 11-23 show how this router will need to process packets through with its three stages. The first figure shows the router sending out a packet and remembering the port it has assigned so that when responses come back, as shown in Figure 11-21, it can route them to the appropriate computer on the local network. Figure 11-22 shows the router doing similar processing but also tampering with the payload to complete the address translation.
