To make the distributed architecture and the THOP mechanism transparent to the clients, it is necessary to modify
the source IP address and the TCP timestamp option
of the server response packets in such a way that they seem to be generated
by the Web switch.
The modification of the source IP address is obtained
in the following way. Each time a TCP connection is
cloned at the server, a special field in the TCP control
block, saddr, is filled with the source IP
address of the Web switch. On the other hand, ordinary TCP connections
leave this field empty.
When the server sends data over a TCP connection, it
checks the value of the saddr field in the corresponding
TCP control block. If it is not empty, the source IP address is changed
with the value contained in the saddr field because
the TCP connection has been cloned through
the TCP Handoff mechanism.
Another critical issue to preserve architecture transparency
concerns the use of the TCP PAWS algorithm .
The use of a timestamp encapsulated as a TCP option is very
useful for the detection of segments carrying wrapped
sequence numbers. As a consequence, the PAWS algorithm
is adopted by many TCP implementations, and must be taken
into account when sending responses transparently to the
clients. However, a key requirement of the PAWS algorithm
is that timestamps be always non decreasing. This is not
guaranteed in a clustered environment where switch
and server nodes have their own independent timestamps.
It must be guaranteed that the timestamp written in the
response packets be greater than the value stored at the
client. In our Web switch, this is achieved through the following approach.
To preserve the semantics of
PAWS, the server uses
its own timestamp. The server can transform
its timestamp into a value that is compatible with
the value expected by the client from the Web switch.
This transformation is a two-stage process
working as following. Let be the TCP timestamp
value at the switch node, when the TCP connection
is transferred. Moreover, let be the TCP timestamp
value at the server when the TCP connection is accepted
and the TCP timestamp value at the server when
a packet is transmitted. As soon as the server accepts a connection
request, it computes the temporal difference between the two
A non positive value of implies that
; hence, the client sees a non decreasing timestamp
and there is no need for spoofing it. A positive value of
. The use of the server TCP timestamps
would confuse the PAWS algorithm. For this reason,
when the server transmits a packet, it writes into the packet the
following, augmented timestamp :
Finally, when the server receives a client packet containing
a timestamp , it must convert that value (which, we recall, is
coherent with the switch) into its real value :