Saturday, May 20, 2017

1.16 Test Network

Figure 1.11 shows the test network that is used for all the examples in the text. This figure is
also duplicated on the inside front cover for easy reference while reading the book.
Figure 1.11 Test network used for all the examples in the text. All IP addresses begin with
140.252.
Most of the examples are run on the lower four systems in this figure (the author's subnet). All
the IP addresses in this figure belong to the class B network ID 140.252. All the hostnames
belong to the .tuc.noao.edu domain.(noao stands for "National Optical Astronomy
Observatories" and tuc stands for Tucson.) For example, the lower right system has a complete
hostname of svr4.tuc.noao.edu and an IP address of 140.252.13.34. The notation at the
top of each box is the operating system running on that system. This collection of systems and
networks provides hosts and routers running a variety of TCP/IP implementations.
It should be noted that there are many more networks and hosts in the noao.edu domain than
we show in Figure 1.11. All we show here are the systems that we'll encounter throughout the
text.
In Section 3.4 we describe the form of subnetting used on this network, and in Section 4.6 we'll
provide more details on the dial-up SLIP connection between sun and netb. Section 2.4
describes SLIP in detail.

Wednesday, April 10, 2013

1.15 Application Programming Interfaces

Two popular application programming interfaces (APIs) for applications using the TCP/IP protocols are called sockets and TLI (Transport Layer Interface). The former is sometimes called "Berkeley sockets," indicating where it was originally developed. The latter, originally developed by AT&T, is sometimes called XTI (X/Open Transport Interface), recognizing the work done by X/Open, an international group of computer vendors that produce their own set of standards. XTI is effectively a superset of TLI.
This text is not a programming text, but occasional reference is made to features of TCP/IP that we look at, and whether that feature is provided by the most popular API (sockets) or not. All the programming details for both sockets and TLI are available in [Stevens 1990].

1.14 Implementations

The de facto standard for TCP/IP implementations is the one from the Computer Systems Research Group at the University of California at Berkeley. Historically this has been distributed with the 4.x BSD system (Berkeley Software Distribution), and with the "BSD Networking Releases." This source code has been the starting point for many other implementations.
Figure 1.10 shows a chronology of the various BSD releases, indicating the important TCP/IP features. The BSD Networking Releases shown on the left side are publicly available source code releases containing all of the networking code: both the protocols themselves and many of the applications and utilities (such as Telnet and FTP).
Throughout the text we'll use the term Berkeley-derived implementation to refer to vendor implementations such as SunOS 4.x, SVR4, and AIX 3.2 that were originally developed from the Berkeley sources. These implementations have much in common, often including the same bugs!

1.13 The Internet

In Figure 1.3 we showed an internet composed of two networks - an Ethernet and a token ring. In Sections 1.4 and 1.9 we talked about the worldwide Internet and the need to allocate IP addresses centrally (the InterNIC) and the well-known port numbers (the IANA). The word internet means different things depending on whether it's capitalized or not.
The lowercase internet means multiple networks connected together, using a common protocol suite. The uppercase Internet refers to the collection of hosts (over one million) around the world that can communicate with each other using TCP/IP. While the Internet is an internet, the reverse is not true.

1.12 Standard, Simple Services

There are a few standard, simple services that almost every implementation provides. We'll use some of these servers throughout the text, usually with the Telnet client. Figure 1.9 describes these services. We can see from this figure that when the same service is provided using both TCP and UDP, both port numbers are normally chosen to be the same.
If we examine the port numbers for these standard services and other standard TCP/IP services (Telnet, FTP, SMTP, etc.), most are odd numbers. This is historical as these port numbers are derived from the NCP port numbers. (NCP, the Network Control Protocol, preceded TCP as a transport layer protocol for the ARPANET.) NCP was simplex, not full-duplex, so each application required two connections, and an even-odd pair of port numbers was reserved for each application. When TCP and UDP became the standard transport layers, only a single port number was needed per application, so the odd port numbers from NCP were used.