Design solutions for efficiency

In this section, we summarize the main design choices that aim to improve the operations of the Web cluster components. Other minor optimizations are possible during the implementation phase, and will be discussed in Section 4. Cluster architecture. The first important choice for an efficient content-aware distributor concerns the architecture of the cluster. We considered the TCP Handoff mechanism because it is a kernel-based one-way solution, which is intrinsically faster than two-way solutions, and makes up for a better scalability. We paid attention to optimizing most of the software components. To this purpose, we have chosen the Linux operating system kernel (version 2.4.18) as the implementation platform, also because of its efficiency and stability on SMP architectures. In particular, we exploited the spinlock primitives [26] to guarantee mutual access of different CPUs to kernel data structures. Forwarding mechanism. As already observed, the design of the forwarding mechanism is a crucial issue, as the speed of packet forwarding operations is one of the factors that can limit the performance of the entire cluster architecture. In particular, two operations must be performed really fast: discovery of transferred connections; checksum re-computation. To quickly determine whether a connection has been transferred or not, we choose to store information about transferred TCP connections in a hash table. Each entry in this table stores IP addresses and TCP ports characterizing a TCP connection. Figure 2 shows the idea for efficient lookup. Basically, the access to the hash table is carried out through a key, consisting of the source IP address and the source TCP port. The key is mapped by a hash function into the index of a list (better said, a bucket) of structures identifying transferred connections. If the hash function spreads uniformly different keys (i.e., different connections) into different buckets, then the accesses are usually carried out into several smaller lists. Hence, the usage of a hash table makes access operations (particularly, lookup operations) much more efficient than alternative implementations based on a single chained list. We add the following solution: each bucket is protected by a lock, so that different CPUs can access the table concurrently without incurring in mutual exclusion problems. The hash function is implemented through the 32-bit XOR operator, since it maps different client port numbers into different buckets (if the source IP is fixed):

$$key= \textrm{(src IP)} \oplus \textrm{(src TCP port)}.$$ (1)

With this design choice, successive requests from the same client are mapped into different buckets and may be handled in parallel on a multi-node switch.

Figure 2: Efficient lookup through a hash table.

Another critical issue is the re-computation of the IP and TCP checksums when a packet has to be forwarded to a Web server. We use the incremental checksum update described in [25] to avoid the re-computation of both checksums. Switch detection at runtime. In our design, the server does not need any a-priori configuration of the switch IP address. Indeed, this address is obtained from the Handoff request and is stored as in the socket structure pertaining to the connection. In such a way, the server is not tied to a single switch, but it may handle Handoff requests from multiple switches. Using many switches may increment the scalability and the fault-tolerance of the cluster.