The SWANS transport entity receives upcalls from the network entity with
packets of the appropriate network protocol and passes them on to the
appropriate registered transport protocol handler. It also receives downcalls
from the application entity, which it passes on to the network entity. The two
implemented transport protocols are UDP and TCP, which encapsulate packets
with the appropriate packet headers. UDP socket, TCP socket and TCP server
socket implementations actually exist within the application entity. The
primary reason for this decision is that these implementations are modeled
after corresponding Java classes, which force the use non-timeless objects.
The DatagramSocket, for example, uses a mutable DatagramPacket
to provide data. In all other respects, including correctness and performance,
this decision, to move the socket implementations into the application entity,
is inconsequential.

SWANS installs a rewriting phase that substitutes identical SWANS socket
implementations for the Java equivalents within node application code. This
allows existing Java networking applications to be run as-is over the
simulated SWANS network. The SWANS implementations use continuations and a
blocking channel in order to implement blocking calls. The entire application
is conveniently frozen, for example, at the point that it calls receive until its packet arrives through the simulated network. Thus, we have
a powerful Java simulation ``sandwich'': Java networking applications running
over SWANS, running over JiST, running within the JVM.

There is an interesting complexity in this transformation that is worth
mentioning. As discussed previously, since constructors can not be invoked
twice, they may not be continuable. However, certain socket constructors, such
as a TCP socket, have blocking semantics, since they require a connection
handshake. We circumvent this problem by rewriting constructor invocations
into two separate invocations. The internal socket implementation has a
non-blocking constructor, which does nothing more than store the
initialization arguments and a second blocking method that will always be
called immediately after the constructor. This second method can safely
perform the required blocking operations.