A task talks to its pvmd and other tasks through TCP sockets. TCP is used because it delivers data reliably. UDP can lose packets even within a host. Unreliable delivery requires retry (with timers) at both ends: since tasks can't be interrupted while computing to perform I/O, we can't use UDP.
Implementing a
packet service over TCP is
simple
because of its reliable delivery.
The packet header is shown in
Figure 
.
No sequence numbers are needed,
and only flags SOM and EOM
(these have the same meaning as in Section ).
Since TCP
provides no record marks to
distinguish back-to-back packets from one another,
the length is sent in the header.
Each side maintains a
FIFO of packets to send,
and switches between reading
the socket when data is available
and writing when there is space.
Figure: Pvmd-task packet header
The main drawback to TCP (as opposed to UDP) is that more system calls are needed to transfer each packet. With UDP, a single sendto() and single recvfrom() are required. With TCP, a packet can be sent by a single write() call, but must be received by two read() calls, the first to get the header and the second to get the data.
When traffic on the connection is heavy,
a simple optimization reduces the average number of reads back
to about one per packet.
If,
when reading the packet body,
the requested length is increased by the size of a
packet header,
the read may succeed in getting both the packet body
and header of the next packet at once.
We have the header for the next packet for free
and can repeat this process.
Version 3.3 introduced the use of Unix-domain stream sockets as an alternative to TCP for local communication, to improve latency and transfer rate (typically by a factor of two). If enabled (the system is built without the NOUNIXDOM option), stream sockets are used between the pvmd and tasks as well as between tasks on the same host.