Chapter 9 Introduction to Network Programming

Introduction to Network Programming

Network programming is complex: one has to deal with a variety of protocols (IP, ICMP,
UDP, TCP etc), concurrency, packet loss, host failure, timeouts, the Sockets API for the
protocols, and subtle portability issues. The protocols are typically described in RFCs
using informal prose and pseudo-code to characterise the behaviour of the systems
involved. That informality has benefits, but inevitably these descriptions are somewhat
ambiguous and incomplete. The protocols are hard to design and implement correctly;
testing conformance against the standards is challenging; and understanding the many
obscure corner cases and the failure semantics requires considerable expertise.

Ideally we would have the best of both worlds: protocol descriptions that are
simultaneously:

1. Clear, accessible to a broad community and easy to modify;

2. Unambiguous, characterising exactly what behaviour is specified;
3. Sufficiently loose, characterising exactly what is not specified, and hence what is left
to implementers (especially, permitting high-performance implementations without over-
constraining their structure); and
4. Directly usable as a basis for conformance testing, not read-and-forget documents.

In this work we have established a practical technique for rigorous protocol specification,
in HOL, that makes this ideal attainable for protocols as complex as TCP. We describe
specification idioms that are rich enough to express the subtleties of TCP endpoint
behaviour and that scale to the full protocol, all while remaining readable. We also
describe novel tools for automated conformance testing between specifications and real-
world implementations.

To develop the technique, and to demonstrate its feasibility, we have produced a post-hoc
specification of existing protocols: a mathematically rigorous and experimentally
validated characterisation of the behaviour of TCP, UDP, and the Sockets API, as
implemented in practice. The resulting specification may be useful in its own right in
several ways. It has been extensively annotated to make it usable as a reference for
TCP/IP stack implementers and Sockets API users, supplementing the existing informal
standards and texts. It can also provide a basis for high-fidelity conformance testing of
future implementations, and a basis for design (and conceivably formal proof) of higher-
level communication layers.

Perhaps more significantly, the work demonstrates that it would be feasible to carry out
similar rigorous specification work for new protocols, in a tolerably light-weight style,
both at design-time and during standardisation. We believe the increased clarity and
precision over informal specifications, and the possibility of automated specification-
based testing, would make this very much worthwhile, leading to clearer protocol designs
and higher-quality implementations. We discuss some simple ways in which protocols
could be designed to make testing computationally straightforward.

Information Technology for B.Sc. IT Semester V Page 111

Chapter 9 Introduction to Network Programming

1.3. What are Sockets?

Sockets are just like "worm holes" in science fiction. When things go into one end, they
(should) come out of the other. Different kinds of sockets have different properties.
Sockets are either connection- oriented or connectionless. Connection-oriented sockets
allow for data to flow back and forth as needed, while connectionless sockets (also
known as datagram sockets) allow only one message at a time to be transmitted, without
an open connection. There are also different socket families. The two most common
are AF_INET for Internet connections, and AF_UNIX for Unix IPC (interprocess
communication). As stated earlier, this FAQ deals only with AF_INET sockets.

1.4. How do Sockets Work?

The implementation is left up to the vendor of your particular Unix, but from the point of
view of the programmer, connection-oriented sockets work a lot like files, or pipes. The
most noticeable difference, once you have your file descriptor is that read() or
write() calls may actually read or write fewer bytes than requested. If this happens, then
you will have to make a second call for the rest of the data. There are examples of this in
the source code that accompanies the faq.

Information Technology for B.Sc. IT Semester V Page 112