![The companion Web site contains all the source code for the book examples, the book
appendixes in HTML and Adobe's Portable Document Format (PDF), and socket
programming– related RFCs in HTML format.
Conventions Used in This Book
The following typographic conventions are used in this book:
• Code lines, commands, statements, variables, and any text you type or see
onscreen appears in a mono typeface. Bold mono typeface is often used to
represent the user's input.
• Placeholders in syntax descriptions appear in an italic mono typeface.
Replace the placeholder with the actual filename, parameter, or whatever
element it represents.
• Italic highlights technical terms when they're being defined.
• The å icon is used before a line of code that is really a continuation of the
preceding line. Sometimes a line of code is too long to fit as a single line on
the page. If you see å before a line of code, remember that it's part of the line
immediately above it.
• The text also includes references to the Internet standards documents called
Requests For Comment (RFCs). The reference citations are enclosed in
brackets with the RFC number, for example [RFC875].
1 Introducing the Cookbook Network Client
2 TCP/IP Network Language Fluency
3 Different Types of Internet Packets
4 Sending Messages Between Peers
5 Understanding the Network Layering Model
Chapter 1. Introducing the Cookbook Network
Client
IN THIS CHAPTER
• Connecting the World with Sockets
• Talking the Talk: TCP/IP Addressing Overview
• Hearing the Server: The Client's Basic Algorithm
• Summary: What's Going On Behind the Scenes?
That blasted CMOS RAM battery! Okay, what time is it? No clocks visible, I'll just
call Time. 1-614-281-8211. Ring. "...The time is eight twenty-three and forty
seconds." Click. Hurrumph! a.m. or p.m.? Do they expect me to look outside?
The computer you use probably is connected to a network of some kind. It could be a
full corporate intranet with firewalls into the Internet; it could be a couple of](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-6-320.jpg)
![the computers communicate. These are not physical; rather, they are abstractions of
the system. All information still goes through the network address like the primary
telephone number.
The standard written format for IP addresses is [0-255].[0-255].[0-255].[0-
255]—for example, 123.45.6.78. Note that zero and 255 are special numbers used in
network masks and broadcasting, so be careful how you use them (Chapter 2
discusses IP numbering in greater detail). Internet ports usually separate these
numbers with either a colon or a period:
[0-255].[0-255].[0-255].[0-255]:[0-65535]
For example, 128.34.26.101:9090 (IP=128.34.26.101, port=9090).
[0-255].[0-255].[0-255].[0-255].[0-65535]
For example, 64.3.24.24.9999 (IP=64.3.24.24, port=9999).
NOTE
The colon notation is more common for ports than the period notation.
Each IP address effectively offers about 65,000 port numbers that a socket may
connect to. See Chapter 2 for more information.
Hearing the Server: The Client's Basic Algorithm
The simplest client-socket connection is one that opens a connection to a server, sends
a request, and accepts the response. Some of the standard services don't even expect
any prompting. One example is the time-of-day service found on port 13.
Unfortunately, many Linux distributions do not have that service open without
revising the /etc/inetd.conf file. If you have access to a BSD, HP-UX, or Solaris
machine, you can try that port.
There are several services available to play with safely. You may try running Telnet
on your machine to connect to the FTP port (21):
% telnet 127.0.0.1 21
After connecting, the program gets the welcome message from the server. Using
Telnet to con nect with the FTP server does not work very well, but you can see the](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-11-320.jpg)
![basic interaction. The simple client example in Listing 1.1 connects to the server,
reads the welcome, and then disconnects.
Example 1.1. A Basic TCP Client Algorithm
/************************************************************/
/*** A basic client algorithm. ***/
/************************************************************/
Create a socket
Create a destination address for server
Connect to server
Read & display any messages
Close connection.
The algorithm in Listing 1.1 may seem overly simplified, and perhaps it is. However,
connecting to and communicating with a server is really that simple. The following
sections describe each of these steps. You can find the complete source for this
program at the end of the book and on the accompanying CD-ROM.
The Socket System Call: Procedures and Caveats
The single tool that creates your effective message receiver and starts the whole
process of sending and receiving messages from other computers is the socket()
system call. This call is the common interface between all protocols available on a
Linux/UNIX operating system. Just like the system call open() creates a file
descriptor to access files and devices on your system, socket() creates a descriptor to
access computers on your network. It requires information that determines what layers
you want to access. The syntax is as follows:
#include <sys/socket.h>
#include <resolv.h>
int socket(int domain, int type, int protocol);
The socket() system call accepts several different values. For a complete list, see
Appendix A, "Data Tables." For now, you'll find a few in Table 1.1.
Table 1.1. Selected socket() System Call Parameter Values
Parameter Value Description
domain PF_INET Internet IPv4 protocols; TCP/IP stack.
PF_LOCAL BSD-style locally named pipes. Typically used in the system
logger or a print queue.
PF_IPX Novell protocols.
PF_INET6 Internet IPv6 protocols; TCP/IP stack.
type SOCK_STREAM Reliable, sequential data flow (byte stream) [Transaction Control
Protocol (TCP)].
SOCK_RDM Reliable, packetized data (not yet implemented in most operating
systems).
SOCK_DGRAM Unreliable, packetized data (datagram) [User Datagram Protocol
(UDP)].
SOCK_RAW Unreliable, low-level packetized data.](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-12-320.jpg)
![struct sockaddr{ struct sockaddr_in {
unsigned short int sa_family; sa_family_t
sin_family;
unsigned char sa_data[14]; unsigned short int sin_port;
}; struct in_addr sin_addr;
unsigned char __pad[];
};
Note that sa_family and sin_family are common between the two structures. The
task every procedure call executes when it receives this record is to check the first
field. Please notice that this is the only field that is in host byte ordering (see Chapter
2). The padding field (named sa_data and __pad) may be common for each in the
sockaddr family. By convention, the generic sockaddr structure and the INET
sockaddr_in structure have to be 16 bytes long (the IPv6 structure, sockaddr_in6,
is 24 bytes). So, the padding field fills out the structure with any unused bytes.
You may notice that the length of the padding field in sockaddr_in is missing. This
is merely a convention. Since the padding has to be set to zero, the actual size is not
important. (In the case of this sockaddr_in definition, it is 8 bytes wide.) Some
implementations may define additional fields for internal computations. Don't worry
about them—and don't use them, because you can't guarantee the field's availability
from system to system and version to version. Any changes may break your code
when you use nonstandard fields. In all cases, initializing the entire structure instance
to zero is best.
The following table describes each field. It also gives examples of possible values.
Field Name Description Byte Ordering Example
sin_family The protocol family Host, Native AF_
sin_port The server's port number Network 13 (time of day)
sin_addr The server's numeric IP address Network 127.0.0.1 (localhost)
Before calling the connect() system call, the program fills each field. Linux has
masked the system call slightly, so it is not necessary to cast sockaddr_in to be a
sockaddr. For portability, you may still want to follow conventions and add the casts.
NOTE
With other UNIX-compatible OSs, you can cast any of the sockaddr_* family
members to sockaddr to avoid warnings. The examples here don't use any casting
merely for space (and because Linux allows it).
The code may look like Listing 1.2.
Example 1.2. Connect() Example](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-16-320.jpg)
![You're probably familiar with this call. Other than its special capability to use the
socket descriptor (sd) instead of the file descriptor (fd), everything else is almost the
same as reading from a file. You can even use the read() system call as in the
following code fragment:
...
int sd, bytes_read;
sd = socket(PF_INET, SOCK_STREAM, 0); /* create socket */
/**** Connect to host ****/
bytes_read = read(sd, buffer, MAXBUF); /* read the message */
if ( bytes_read < 0 )
/* report connection error; exit routine */
...
In fact, you could convert the socket descriptor into a FILE* for higher-level I/O. For
example, to use fscanf(), you could follow the example below. (The lines in bold
indicate the changes from the previous listing.)
char Name[NAME], Address[ADDRESS], Phone[PHONE];
FILE *sp;
int sd;
sd = socket(PF_INET, SOCK_STREAM, 0); /* create socket */
/**** Connect to host ****/
if ( (sp = fdopen(sd, "r")) == NULL ) /* convert to FILE* */
else if ( fscanf(sp, "%*s, %*s, %*s n", /* use as usual */
perror("FILE* conversion failed");
NAME, Name, ADDRESS, Address, PHONE, Phone) < 0 )
{
perror("FScanf");
...
Only stream-style sockets can be converted reliably into a FILE* stream. The reason
is simple: Datagram sockets are typically connectionless—a message is sent and that's
it. Also, streaming sockets provide data integrity and message reliability, whereas
datagrams are unreliable. Datagrams are similar to putting a message in an addressed
and stamped envelope that you send through the postal system: The message may not
arrive at all. A FILE* connection must be an open channel. If you try to convert a
datagram, you may lose critical data. For more information about streams versus
datagrams, see Chapter 3, "Different Types of Internet Packets."
FILE* socket connections provide excellent scanning and parsing resources for the
network programmer. However, when you use them, you must check all return values,
including *printf() and *scanf(). Note the preceding example: If the return value
of fscanf() is less than zero, there was an error.](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-18-320.jpg)
![IP addresses provide several advantages over the hardware-supplied MAC. First the
number can change (it is not fixed), so deploying consistent clusters of addresses is
easier, and laptops don't run into problems. The network can map the IP to the
hardware MAC using the Address Resolution Protocol (ARP). See the Request For
Comment #826 [RFC826] on the accompanying CD-ROM.
NOTE
The ARP is a simple translation table that takes the IP and fills in the associated
MAC. All messages on the network must have a MAC so that the adaptor (or
drivers) can pick up the message. The source may not know the MAC of the
destination host, which hides deeply behind several routers. The router instead
sends the message to routers that control the sub-networks (or subnets) defined in
the IP address. When the message gets to a router with ARP, it checks the tables. If
the router find the IP address, the packet's MAC gets the correct destination.
Otherwise, the router sends a broadcast into the subnet to resolve the IP address.
Internet ID Organization
The Internet ID uses a most-to-least–specific addressing scheme. Each ID is a four-
byte number, like the ethernet ID. The first number, reading from left to right, is the
network class. Look at Figure 2.1.
Figure 2.1. The IP address has several parts that identify network granularity.
The IP address acts as a general roadmap to the routers. Each part of the address
provides more specific information about where the destination is. Beginning with the
network class, the address ends with the host number. You could easily compare it to
an address on an envelope: The first line is the addressee, then the street address or
box number. The detail decreases in the address until the state or country.
Internet addressing has five basic address classes. Each class is a block of allocations
for very large to small networks. The Internet addressing plan is organized so that
companies may buy segments from the addressing space. The classes are labeled A–E:
Class Address Address Range, Description
0.0.0.0 to
0.255.255.255
(Reserved)](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-25-320.jpg)
![subnet. Propagation is very important: Simply receiving a packet, checking it, and
passing it on is not acceptable. Each bit that the router accepts means a delay on the
network. The router must delay no more bits than necessary to determine the
relevance. In other words, it must be invisible to propagation delays. For example,
typical telephone switching in the United States of America does not try to resolve the
whole phone number at once; the first three digits indicate an area or region, and the
next three digits indicate the station.
Subnetwork Masks
Some of the classes require more filtering. A network with 16 million nodes is
excessive if all are clumped in one space. As you set up your Linux computer and
configured the network, you may have noticed the term subnet mask. The introduction
of CIDR has helped to simplify the complexity of large subnets [RFC950].
The network subnet mask is specifically for identifying the group of contiguous
addresses an interface can reach. It provides an additional filter that permits only
specific messages to pass through. When a message arrives, the router uses the subnet
mask on the message's destination address. If it matches, the router passes the
message on. You may build mask any way you wish, but the least significant set bit
specifies the subnetwork.
For example, if you had a small network of eight machines, and you expected the
group to grow by no more than five machines, you could set your router subnet mask
to 187.35.209.176. The last bit in the address is in the 176 (1101,0000). The
address range is in 'X'part (active subnet) of 1101,XXXX. From here, you can dole out
the addresses: 187.35.209.176 (router), 187.35.209.177 (host #1), up to
187.35.209.222. You can have any combination, but the least significant set bit is
the marker.
NOTE
Using the network mask as a host address may cause conflict and lose packets.
This is due to the special address 0 (zero). The example, 187.35.209.0, has the
last eight bits as zeros. If the address matches the network mask, it is the zeroth
address. You should always reserve the zeroth address for the network address
mask. Likewise, you may have noticed that the example omits 187.35.209.223.
If you were to use that ID, that host may never see a message. The number 223 has
the active subnet as all ones: 1101,1111. This is a broadcast address. You should
not use that as a host address.
In most cases you do not need to worry about setting up routers, and the configuration
is beyond the scope of this book. Usually, when you see the subnetwork mask in the
network configuration, you can accept the mask that the script offers you.
Routers and Address Resolution](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-27-320.jpg)
![planning. The allocation of addresses exceeded 450 million nodes. The Board saw
increased allocations chewing up the available address space. However, only about
2% of the allocations were actually used. Where were all the remaining addresses?
IAB allocates address ranges to companies in whole blocks. The companies, in
anticipation of additional use and to keep their addresses as contiguous as possible,
buy larger ranges than they need.
NOTE
One small place I worked showed me its allocation of 128 addresses; only 30 were
in use at the time. They carved out 10 slots for me. I never used more than 2. To
this day, I think those addresses may still be allocated to me, even though I left the
company about four years ago.
In all, address exceptions and squandered allocations have eaten up most of the
address space. Recent estimates indicate that Class B and Class C networks are full.
ISPs are using more of Class A. Before long, the demand may use up all the addresses.
What is the Internet going to do with the lost address space? How can the current IP
addressing be better used? The IAB, now called Internet Corporation for Assigned
Names and Numbers (ICANN), cannot easily reclaim the unused slots sold to
companies, because the companies'IT departments have already allocated those
addresses within the organization.
Many companies now use Dynamic Host Configuration Protocol (DHCP) [RFC2131],
which allocates an IP address upon bootup. No host owns an IP address permanently.
DHCP also helps with security: Computer crackers love fixed IP addresses. If you
recall, bootp sends out a broadcast message to find a bootp server. When found, the
server issues an IP address. Similarly, a normal host loads its DHCP requestor during
bootup. The requestor sends a broadcast message to find a responsive DHCP server.
When found, the server allocates an address from its pool of available addresses and
passes it (along with the appropriate network mask) to the requestor.
The DHCP requestor accepts the information and configures the local host's network
protocols. In some cases this can take several seconds, due to network congestion.
Until the local host is properly configured, it may suffer from IP amnesia (the host
won't know its own address).
NOTE
Host or IP amnesia also occurs when network and host naming are not properly set
up. This can be a significant problem. Even ping 127.0.0.1 may not work. If
your host has amnesia, check your distribution. The RedHat Distribution (and
derivatives) use /etc/sysconfig/network and /etc/sysconfig/network-
scripts/ifcfg-* to define and set the values.](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-29-320.jpg)
![Another solution is to lengthen the IP address size itself. Introducing: IPv6
[RFC2460]! IPv6 in a nutshell is four times the size of an IP address: 128 bits versus
32 bits. IPv6 changed the appearance dramatically as well:
<$nopage>
001 8008:4523:F0E1:23:830:CF09:1:385
002 <$nopage>
The result is a not-so-memorable address.
The primary advantage of IPv6 is that it has a much larger address space to work with.
More than 3×1038
addresses probably removes any problem of address limitations for
a very long time. See Chapter 17, "Sharing Messages with Multicast, Broadcast, and
Mbone," for more information.
IP Host Port Numbers
All messages arrive at one or more recognized address. If a program accepts these
messages, it may receive information destined for other running programs. The
operating system has little regard for where the message goes, as long as it delivers.
The TCP/IP stack adds the concept of a port. One system can have several ports
available, all associated with the same address.
The TCP/IP stack adds the ports to abstract the network and ease programming for
you. These are not real, physical ports. They are channels that the networking
subsystem uses to redirect information to the appropriate program. All network
programs no longer receive all messages; they receive only the messages for their port.
Every typical IP data packet on your Internet-based network has the address of the
host and the port number. When a packet arrives from the network, the 16-bit field in
the packet header indicates the destined port number. The operating system reads this
field and places the new packet on the port's queue. From there, the program reads the
socket (with either the read() or recv() system call). Likewise, when the program
transmits a message (via the write() or send() system call), the operating system
places the data in the port's outgoing queue.
By default, only one program owns a port. In fact, if you attempt to run two programs
that allocate the same port number on the same computer, the system call returns an
EINVAL error code. You can elect to share a port using SO_REUSEADDR (see Chapter 9,
"Breaking Performance Barriers").
NOTE
The rule that no two sockets can share the same port applies to symmetric
processors as well. The reason is simple: The processors, like resources, share the
memory and operating system. If you were to have two operating systems running,
you could theoretically have two sockets in separately running programs with the
same port number, as long as they reside in different operating system spaces.](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-30-320.jpg)
![cannot be fragmented, or the program set the socket option for "don't
fragment."
• EAGAIN The socket is marked nonblocking and the requested operation would
block. This is not an error, merely a "not ready yet." Try sending again later.
• EPIPE The local end has been shut down on a connection-oriented socket. In
this case the process also receives a SIGPIPE unless MSG_NOSIGNAL is set.
(Same as EPIPE in the write() system call.)
You use the send() system call to prompt a server. For example, if you want to use
the network finger on a server, you open a channel to the server's port (79), send the
username, and read the response. This algorithm is typically what the client does.
You don't need any special options to do this task. However, you may want to read as
much information as the server sends you. Sometimes the reply may be larger than
your buffer size. The following program listing excerpt shows you the implementation
of the algorithm. You can get the complete program listing on the CD-ROM that
accompanies this book.
/************************************************************/
/*** Expanding the port tester – add the capability to ***/
/*** access any port and to send a message. ***/
/************************************************************/
int main(int count, char *strings[])
{ int sockfd;
struct sockaddr_in dest;
char buffer[MAXBUF];
/*--- Create socket and assign a port number ---*/
sockfd = socket(AF_INET, SOCK_STREAM, 0);
bzero(&dest, sizeof(dest));
dest.sin_family = AF_INET;
dest.sin_port = htons(atoi(strings[2]));
inet_addr(strings[1], &dest.sin_addr.s_addr);
/*--- Connect to server & send request ---*/
if ( connect(sockfd, &dest, sizeof(dest)) != 0 )
PANIC("connect() failed");
printf(buffer, "%s n", strings[3]);
send(sockfd, buffer, strlen(buffer), 0);
/*--- Clear buffer and read SHORT reply ---*/
bzero(buffer, MAXBUF);
recv(sockfd, buffer, MAXBUF-1, 0);
printf("%s", buffer);
close(sockfd);
return 0;
}
If you want to use this algorithm to get a long reply, you need to change the last
section to the following:
/************************************************************/
/*** Revising the code to get lengthy replies ***/](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-37-320.jpg)
![The Fundamental Network Packet
If you could actually see the bits that travel from one computer to the other, what
would you see? Each protocol is very different, but they all share one common
necessary feature: They all carry the program's message. Some protocols include a
source address, while some require a destination. You may think that not requiring a
destination is a little unusual, but some protocols (like UUCP) use the connection as
the address to the destination.
The Internet Protocol (IP) [RFC791] requires a packet to have three basic elements:
source, destination, and data. (The data payload includes its length.) These elements
provide the packet a level of autonomy. No matter where a packet is, you can identify
where it came from, where it's going, and how big it is.
The packet's autonomy is an important feature of the Internet. As long as the packet is
alive (the data is timely and relevant), routers can move data to its destination when
the packet is launched onto the network.
NOTE
Packet autonomy also has a downside. While a packet provides a way of getting to
anywhere from anywhere, a malicious programmer can easily trick the network.
The network does not require that the source host's address be validated. Aliasing
or spoofing (masking the true identity and assuming a different one) the hardware](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-41-320.jpg)
![address is difficult, but programs can alias other IDs. Please note that later Linux
kernels do not allow spoofing.
As discussed in Chapter 2, "TCP/IP Network Language Fluency," the network packet
is in network byte (or big endian) order. With that in mind, take a look at a structure
definition of how the network packet appears in Listing 3.1, and Figure 3.2 displays
the physical layout.
Figure 3.2. IP header layout.
Example 3.1. IP Structure Definition
/************************************************************/
/*** IP Packet definition ***/
/************************************************************/
#typedef unsigned int uint;
#typedef unsigned char uchar;
struct ip_packet {
uint version:4; /* 4-bit version [note] */
uint header_len:4; /* header length in words [note] */
uint serve_type:8; /* how to service packet [note] */
uint packet_len:16; /* total size of packet in bytes */
uint ID:16; /* packet ID [note] */
uint __reserved:1; /* always zero */
uint dont_frag:1; /* flag to permit fragmentation */
uint more_frags:1; /* flag for "more frags to follow"*/
uint frag_offset:13; /* to help reassembly */
uint time_to_live:8; /* permitted router hop cnt [note] */
uint protocol:8; /* ICMP, UDP, TCP [note] */
uint hdr_chksum:16; /* ones-comp. checksum of header */
uint IPv4_source:32; /* IP address of originator */
uint IPv4_dest:32; /* IP address of destination */](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-42-320.jpg)
![uchar options[]; /* up to 40 bytes [note] */
uchar data[]; /* message data up to 64KB [note] */
} ;
Notice that the packet structure includes many more fields than the basic four fields
discussed earlier in this chapter. The IP subsystem uses these additional fields for
controlling the packet. For example, the dont_frag field tells the network that,
instead of cutting up the message into smaller chunks, it should either accept the
message completely or drop it.
Most of the fields are simple enough that the comments next to them provide
sufficient description. The remaining fields require a longer description. The
following sections define the IP fields that you can modify or use. This text is not
exhaustive; if you want to learn more about each field, please refer to a good text on
TCP/IP protocols.
version Field
The first IP field is the version number for the IP protocol version. Most of the values
are either reserved or unassigned; for example, IPv4 places a 4 in this field. The few
defined values are listed in Table 3.1.
Table 3.1. version Field Values
Value Description/Use
4 IPv4
5 Stream IP Datagram mode (experimental IP)
6 IPv6
7 TP/IX (the "next" Internet Protocol)
8 The "P" Internet Protocol
9 TUBA
The only chance you have to fill this field is when you create a raw socket and you
elect to fill the header yourself (using socket option IP_HDRINCL). Even then, you
may set the field to 0. The zero flags the kernel to fill in the appropriate value for you.
header_len Field
This field tells the receiver the header length in 32-bit words. Since the value 0 is
reserved (and meaningless), the greatest length is 15 words or 60 bytes. Again, the
only circumstance in which you fill this field is with a raw socket packet and
IP_HDRINCL. Since all IP headers are at least 20 bytes, the minimum value for this
field is 5 (20/4) bytes.
serve_type Field
The serve_type field indicates how to manage the packet. It has two subfields: a
precedence subfield (ignored on most systems) and a type of service (TOS) subfield.
You normally set TOS with the setsockopt() system call. TOS has four options:
Minimum Delay, Maximum Throughput, Maximum Reliability, and Minimum Cost](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-43-320.jpg)
![Your message goes here and can include up to 65,535 bytes (minus 60 bytes, the
maximum size of the header). The data section includes any header information that
the higher protocols need. For example, ICMP requires 4 bytes, UDP requires 8 bytes,
and TCP requires 20–60 bytes.
The Internet packet system bases all its IPv4 packets on this structure. Each layer on
top of this adds features and reliability.
Dissecting the Various Packets
The Internet Protocol offers several packet protocols that range from very fast to very
reliable. All of them rest on the lowest layer—the basic IP packet. However, each
layer has evolved to solve specific problems. To select the correct packet type, you
must know about what you're transmitting.
The packet types most likely to be of interest are TCP, UDP, ICMP, and raw.
Knowing the advantages and disadvantages of each type can help you choose the most
appropriate for your application. Each packet type has different benefits, as
summarized in Table 3.2.
Table 3.2. Packet Type Benefits
Raw ICMP UDP TCP
Overhead (bytes) 20–60 20–60+[4] 20–60+[8] 20–60 +[20–60]
Message Size (bytes) 65,535 65,535 65,535 (unlimited)
Reliability Low Low Low High
Message Type Datagram Datagram Datagram Stream
Throughput High High Medium Low
Data Integrity Low Low Medium High
Fragmentation Yes Yes Yes Low
In this table, notice that each packet type contains comparisons. A reliability of Low
value only means that you cannot rely on the protocol to help reliability. While the
differences may seem extreme, remember that they are merely comparisons.
Considering the Packet's Issues
Each protocol addresses issues in the transmission. The following sections define each
issue and associated category from Table 3.2. This information can help you see why
certain protocols implement some features and skip others.
Protocol Overhead
Protocol overhead includes both the header size in bytes and the amount of interaction
the protocol requires. High packet overhead can reduce throughput, because the
network has to spend more time moving headers and less time reading data.
Strong protocol synchronization and handshaking increase interaction overhead. This
is more expensive on WANs because of the propagation delays. Table 3.2 does not
include this measurement.](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-46-320.jpg)
![Protocol Message Size
To calculate network throughput, you need to know the packet size and the protocol's
overhead. The transmission size gives you the maximum size of a sent message. Since
all but TCP use a single-shot message, this limitation is typically due to the limits of
IP packet (65,535 bytes). The amount of data your program transmits per packet is the
transmission size less the headers.
Protocol Reliability
Part of the problem with networks is the possibility of lost messages. A message could
be corrupted or dropped as it moves from one host or router to another, or the host or
router could crash or fail. In each case, a message may simply be lost, and your
program may need to follow up.
Also, you may need to make sure that the destination processes the packets in the
correct order. For example, you may compose a message that does not fit in one
packet. If the second packet arrives before the first, the receiver must know how to
recognize and correct the problem. However, the order is not important when each
message is independent and self- contained.
The packet's reliability indicates the certainty of safe arrival of messages and their
order. Low reliability means that the protocol can't guarantee that the packet gets to
the destination or that the packets are in order.
Protocol Message Type
Some messages are self-contained and independent from other messages. Pictures,
documents, email messages, and so on are a few examples that may fit the size of the
packet. Others are more in the form of a flowing stream, such as Telnet sessions,
HTTP's open channel [RFC2616], large documents, pictures, or files. The message
type defines which style best fits each protocol.
NOTE
HTTP 1.0 could effectively use UDP for transferring messages instead of TCP.
The client simply sends the request for a specific document, and the server replies
with the file. Effectively, no conversation occurs between client and server.
Protocol Throughput
The most noticeable aspect of data transmission is network throughput. Getting the
most out of your network is the best way to make your users happy. To get the best
performance, you need to know the throughput. Often, the bits-per-second is a small
part of the whole equation; it only indicates how the network could perform under
ideal circumstances.
The protocol throughput measures how much real data the originator can send to the
destination within a period of time. If the headers are large and the data small, the](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-47-320.jpg)
![Table 3.4. ICMP's Attributes
Message Size (bytes) 65,535 (65,511 max data payload)
Overhead (bytes) 24–64
Reliability Low (same as raw IP)
Message Type Datagram
Throughput High (same as raw IP)
Data Integrity Low (same as raw IP)
Fragmentation Yes (but unlikely)
You can reuse your socket to send messages to different hosts without reopening the
socket if you employ the ICMP in your own program. Send messages using the
sendmsg() or sendto() system call (described in the next chapter). These calls
require an address of the destination. With a single socket, you can send messages to
as many peers as you want.
The advantages and disadvantages of an ICMP packet are essentially the same as raw
IP (and other datagrams). However, the packet includes a checksum for data
validation. Also, the likelihood that the network may fragment an ICMP packet is
very small. The reason is because of the nature of ICMP messages: They are for
statuses, errors, or control. The message is not going to be very large, so it may never
require reassembly.
While you can use the ICMP for your own messages, it is usually for error messages
and control. All networking errors travel the network through an ICMP packet. The
packet has a header that holds the error codes, and the data part may contain a more
specific message describing the error.
Part of the IP protocol, ICMP gets an IP header and adds its own header. Listing 3.2
shows a definition of the structure.
Example 3.2. ICMP Structure Definition
/************************************************************/
/*** ICMP structure definition ***/
/*** Formal definition in netinet/ip_icmp.h ***/
/************************************************************/
typedef unsigned char ui8;
typedef unsigned short int ui16;
struct ICMP_header {
ui8 type; /* Error type */
ui8 code; /* Error code */
ui16 checksum; /* Message checksum */
uchar msg[]; /* Additional data description */
} ;
Figure 3.3. ICMP layout.](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-50-320.jpg)
![UDP offers the advantage of high speed. Moreover, you can increase its reliability
yourself in the following ways:
• Break up large packets. Take each message and divide it into portions and
assign a number (such as 2 of 5). The peer on the other end reassembles the
message. Bear in mind that more overhead and less sent data decrease
throughput.
• Track each packet. Assign a unique number to each packet. Force the peer to
acknowledge each packet because, without an acknowledgment, your program
resends the last message. If the peer does not get an expected packet, it
requests a resend with the last message number or sends a restart message.
• Add a checksum or CRC. Verify the data of each packet with a data
summation. A CRC is more reliable than a checksum, but the checksum is
easier to calculate. If the peer discovers that data is corrupted, it asks your
program to resend the message.
• Use timeouts. You can assume that an expired timeout means failure. Your
originator could retransmit the message, and your receiver could send a
reminder to the sender.
The Critical and Important data types require the reliability found in TCP or better.
Fault-Intolerant requires much more than any of these protocols offer. These outlined
steps mimic the reliability of TCP.
UDP relies on IP's features and services. Each UDP datagram packet receives an IP
and a UDP header. Listing 3.3 defines how the UDP structure appears.
Example 3.3. UDP Structure Definition
/************************************************************/
/*** UDP (datagram) structure definition ***/
/*** (Formal definition in netinet/udp.h) ***/
/************************************************************/
typedef unsigned char ui8;
typedef unsigned short int ui16;
struct UDP_header {
ui16 src_port; /* Originator's port number */
ui16 dst_port; /* Destination's port number */
ui16 length; /* Message length */
ui16 checksum; /* Message checksum */
uchar data[]; /* Data message */
} ;
Figure 3.4. UDP layout.](https://image.slidesharecdn.com/2658227-250529034800-840041f4/85/Download-full-ebook-of-Linux-Socket-Programming-Walton-Sean-instant-download-pdf-52-320.jpg)
Download full ebook of Linux Socket Programming Walton Sean instant download pdf
- 1. Linux Socket Programming Walton Sean download https://ebookbell.com/product/linux-socket-programming-walton- sean-5316454 Explore and download more ebooks at ebookbell.com
- 2. Here are some recommended products that we believe you will be interested in. You can click the link to download. Linux Command Line And Shell Scripting Bible 4th Edition Richard Blum https://ebookbell.com/product/linux-command-line-and-shell-scripting- bible-4th-edition-richard-blum-46090968 Linux The Complete Reference Sixth Edition 6th Richard Petersen https://ebookbell.com/product/linux-the-complete-reference-sixth- edition-6th-richard-petersen-46145398 Linux Basics For Hackers Occupytheweb https://ebookbell.com/product/linux-basics-for-hackers- occupytheweb-46410142 Linux Allinone For Dummies 7th Richard Blum https://ebookbell.com/product/linux-allinone-for-dummies-7th-richard- blum-46498774
- 3. Linux User Developer Issue 141 Gavin Thomas https://ebookbell.com/product/linux-user-developer-issue-141-gavin- thomas-46964020 Linux The Ultimate Guide 1st Edition Sufyan Bin Uzayr https://ebookbell.com/product/linux-the-ultimate-guide-1st-edition- sufyan-bin-uzayr-47210890 Linux Observability With Bpf David Calavera Lorenzo Fontana https://ebookbell.com/product/linux-observability-with-bpf-david- calavera-lorenzo-fontana-47440460 Linux In A Nutshell A Desktop Quick Reference 6th Stephen Figgins Ellen Siever Robert Love And Arnold Robbins https://ebookbell.com/product/linux-in-a-nutshell-a-desktop-quick- reference-6th-stephen-figgins-ellen-siever-robert-love-and-arnold- robbins-47487258 Linux Bible Christopher Negus https://ebookbell.com/product/linux-bible-christopher-negus-48248486
- 5. Book Organization This book delves into many particulars of network programming. It is organized into five specific parts, each part building upon earlier parts: • Part I: Network Programming from the Client Perspective This part introduces sockets and defines terms. It describes the different types of sockets, addressing schemes, and network theory. • Part II: The Server Perspective and Load Control Part II expands socket programming with servers, multitasking techniques, I/O control, and socket options. • Part III: Looking at Sockets Objectively C is not the only programming language that provides access to sockets. This part presents some object-oriented approaches and describes the advantages and limitations of object technology in general. • Part IV: Advanced Sockets—Adding Value This part introduces the large realm of advanced network programming techniques, including security, broadcast and multicasting, IPv6, and raw sockets. • Part V: Appendixes The appendixes consolidate much of the resource material relevant to sockets. The first appendix includes tables and listings too large for the chapters. The second and third appendixes describe the Socket and Kernel APIs.
- 6. The companion Web site contains all the source code for the book examples, the book appendixes in HTML and Adobe's Portable Document Format (PDF), and socket programming– related RFCs in HTML format. Conventions Used in This Book The following typographic conventions are used in this book: • Code lines, commands, statements, variables, and any text you type or see onscreen appears in a mono typeface. Bold mono typeface is often used to represent the user's input. • Placeholders in syntax descriptions appear in an italic mono typeface. Replace the placeholder with the actual filename, parameter, or whatever element it represents. • Italic highlights technical terms when they're being defined. • The å icon is used before a line of code that is really a continuation of the preceding line. Sometimes a line of code is too long to fit as a single line on the page. If you see å before a line of code, remember that it's part of the line immediately above it. • The text also includes references to the Internet standards documents called Requests For Comment (RFCs). The reference citations are enclosed in brackets with the RFC number, for example [RFC875]. 1 Introducing the Cookbook Network Client 2 TCP/IP Network Language Fluency 3 Different Types of Internet Packets 4 Sending Messages Between Peers 5 Understanding the Network Layering Model Chapter 1. Introducing the Cookbook Network Client IN THIS CHAPTER • Connecting the World with Sockets • Talking the Talk: TCP/IP Addressing Overview • Hearing the Server: The Client's Basic Algorithm • Summary: What's Going On Behind the Scenes? That blasted CMOS RAM battery! Okay, what time is it? No clocks visible, I'll just call Time. 1-614-281-8211. Ring. "...The time is eight twenty-three and forty seconds." Click. Hurrumph! a.m. or p.m.? Do they expect me to look outside? The computer you use probably is connected to a network of some kind. It could be a full corporate intranet with firewalls into the Internet; it could be a couple of
- 7. computers you connected in your spare time. The network connects workstations, servers, printers, disk arrays, faxes, modems, and so forth. And each network connection uses or provides a service. Some services provide information without any interaction. Just as in our example of calling Time, a basic network client connects with and listens to a server. What kinds of services do servers provide? Many. All services fit into four resource categories: common, limited or expensive, shared, and delegated. Here are some examples of each: Common Disk space (centrally backed up) Limited Printers, modems, disk arrays Shared Databases, project control, documentation Delegated Remote programs, distributed queries This chapter steps you through writing a basic client that connects to some server. This process helps you understand all that is involved in writing network programs. The client initially connects to the server's correct time service (or some other service that does not expect input first). Along the way, the chapter explains the different calls, their parameters, and common errors. The client program needs a send/receive interface and an address to connect to a server. Both clients and servers use sockets to connect and send messages independently of location. Consider the telephone example again: The handset has two parts, a microphone (transmission) and a speaker (reception). Sockets also have these two channels. In addition, the telephone number is essentially the unique address for the phone. The socket likewise has two parts or channels: one for listening and one for sending (like the read/write mode for file I/O). The client (or caller) connects with the server (or answerer) to start a network conversation. Each host offers several standard services (see /etc/services on the file system), like the correct time telephone number. NOTE You can run most of the book's program examples without being connected to a network, if you have networking enabled in the kernel and the inetd network server daemon running. In fact, many examples use the local (or loopback) address of 127.0.0.1. If you do not have the network drivers up and running, most Linux distributions include everything you need for at least loopback networking. Your client program must take several steps to communicate with a peer or server. These steps have to follow a particular sequence. Of course, you could ask: "Why not replace all the steps with fewer calls?" Between each step, your program can select from many options. Still, some steps are optional. If your client skips some steps, usually the operating system fills in the blanks for you with default settings.
- 8. You can follow a few basic steps to create a socket, set up the destination host, establish the channel to another network program, and shut down. Figure 1.1 graphically shows the steps the client takes to connect to a server. Figure 1.1. Each client interfaces with the operating system by making several calls in succession. The following list describes each step: 1. Create a socket. Select from the various network domains (such as the Internet) and socket types (stream).
- 9. 2. Set socket options (optional). You have many options that affect the behavior of the socket. The program can change these options anytime the socket is open. (See Chapter 9, "Breaking Performance Barriers," for more detail.) 3. Bind to address/port (optional). Accept connections from all or a single IP address, and establish port service. If you skip this, the operating system assumes any IP address and assigns a random port number. (Chapter 2, "TCP/IP Network Language Fluency," discusses addresses and ports in much greater detail.) 4. Connect to peer/server (optional). Reach out and establish a bidirectional channel between your program and another network program. If you skip this, your program uses directed or connectionless communication. 5. Partially close the connection (optional). Limit the channel to either sending or receiving. You may want to use this step after duplicating the channel. 6. Send/receive messages (optional). One reason to opt out of any I/O might include checking host availability. 7. Close the connection. Of course this step is important: Long-running programs may eventually run out of available file descriptors if the programs do not close defunct connections. The following sections describe some of these steps, defining the system calls and providing examples Connecting the World with Sockets Several years ago, networking involved a dedicated serial line from one computer to another. No other computers shared the same circuit, and UNIX used UUCP (UNIX- to-UNIX Copy) to move files around. As line transmission technology improved, the concept of sharing the transmission line became feasible. This meant that each computer needed to identify itself uniquely and take turns transmitting. There are several different methods for sharing time on the network, and many work rather well. At times, computers transmit simultaneously, causing a packet collision. The hardware and low-level drivers handle issues such as collisions and retransmission, now an artifact of past programming. This frees up your design to focus on transmission and reception of messages. The Socket API (Application Programming Interface) provides designers the conduit to receive or send messages. Socket programming differs from typical application or tool programming, because you work with concurrently running programs and systems. This means that you need to consider synchronization, timing, and resource management. Sockets link asynchronous tasks with a single bidirectional channel. This could lead to problems like deadlock and starvation. With awareness and planning, you can avoid most of these problems. You can read how to handle multitasking issues in Chapter 7, "Dividing the Load: Multitasking," and building robust sockets in Chapter 10, "Designing Robust Linux Sockets." Typically, an overloaded server slows down the Internet's perceived responsiveness. Timing and resource management reduce the server's burden, increasing network
- 10. performance. You can find many ideas for improving performance in Part II, "The Server Perspective and Load Control." The Internet was designed to be entirely packet switched. Each and every packet has to have all the necessary information it needs to get to the destination. Like a letter, a packet must include source and destination addresses. The packet switches from one computer to the next along the connections (or links). If the network loses a link while passing a message, the packet finds another route (packet switching), or the router bounces an error back to the originator if it fails to reach the host. This ensures a form of data reliability. Broken paths in the network result in network outages. You probably have encountered a few network outages yourself. Talking the Talk: TCP/IP Addressing Overview Networks support many different types of protocols. Programmers have geared some protocols to address specific issues such as radio/microwave; others attempt to solve the network reliability problems. TCP/IP (Transmission Control Protocol/Internet Protocol) focuses on the packet and the potential of lost communication channels. At any time, the protocol attempts to find a new route when a network segment fails. Packet tracking, loss detection, and retransmission are difficult algorithms, because timing is not the only indicator. Luckily, industry experience has proven the algorithms used in the protocol. Usually, you can ignore those issues during design, because the solutions are hidden deep in the protocol. TCP/IP is layered: Higher-level protocols provide more reliability but less flexibility, and lower levels offer greater flexibility but sacrifice reliability. With all the different levels of flexibility and reliability, the Socket API offers all the needed interfaces. This is a departure from the standard UNIX approach of every level having its own set of calls. The standard file I/O likewise uses a layered approach. Computers connected via TCP/IP use sockets predominantly to communicate with each other. This may seem strange, considering all the different protocol layers available to a program and having been taught that open() (which yields a file descriptor) and fopen() (which yields a file reference) are different and almost incompatible. All protocol layers are available through one call: socket(). This single call abstracts away all the implementation details of the different networks (TCP/IP, IPX, Rose). Fundamentally, each packet has the data, the originator address, and the destination address. Every layer in the protocol adds its own signature and other data (wrapper) to the transmission packet. When transmitted, the wrapper helps the receiver forward the message to the appropri ate layer to await reading. Every computer connected to the Internet has an Internet Protocol (IP) address, a unique 32-bit number. Without the uniqueness, there is no way to know the proper destination for packets. TCP/IP takes the addressing one step further with the concept of ports. Like the 3- to 5-digit telephone extensions, each computer address has several ports through which
- 11. the computers communicate. These are not physical; rather, they are abstractions of the system. All information still goes through the network address like the primary telephone number. The standard written format for IP addresses is [0-255].[0-255].[0-255].[0- 255]—for example, 123.45.6.78. Note that zero and 255 are special numbers used in network masks and broadcasting, so be careful how you use them (Chapter 2 discusses IP numbering in greater detail). Internet ports usually separate these numbers with either a colon or a period: [0-255].[0-255].[0-255].[0-255]:[0-65535] For example, 128.34.26.101:9090 (IP=128.34.26.101, port=9090). [0-255].[0-255].[0-255].[0-255].[0-65535] For example, 64.3.24.24.9999 (IP=64.3.24.24, port=9999). NOTE The colon notation is more common for ports than the period notation. Each IP address effectively offers about 65,000 port numbers that a socket may connect to. See Chapter 2 for more information. Hearing the Server: The Client's Basic Algorithm The simplest client-socket connection is one that opens a connection to a server, sends a request, and accepts the response. Some of the standard services don't even expect any prompting. One example is the time-of-day service found on port 13. Unfortunately, many Linux distributions do not have that service open without revising the /etc/inetd.conf file. If you have access to a BSD, HP-UX, or Solaris machine, you can try that port. There are several services available to play with safely. You may try running Telnet on your machine to connect to the FTP port (21): % telnet 127.0.0.1 21 After connecting, the program gets the welcome message from the server. Using Telnet to con nect with the FTP server does not work very well, but you can see the
- 12. basic interaction. The simple client example in Listing 1.1 connects to the server, reads the welcome, and then disconnects. Example 1.1. A Basic TCP Client Algorithm /************************************************************/ /*** A basic client algorithm. ***/ /************************************************************/ Create a socket Create a destination address for server Connect to server Read & display any messages Close connection. The algorithm in Listing 1.1 may seem overly simplified, and perhaps it is. However, connecting to and communicating with a server is really that simple. The following sections describe each of these steps. You can find the complete source for this program at the end of the book and on the accompanying CD-ROM. The Socket System Call: Procedures and Caveats The single tool that creates your effective message receiver and starts the whole process of sending and receiving messages from other computers is the socket() system call. This call is the common interface between all protocols available on a Linux/UNIX operating system. Just like the system call open() creates a file descriptor to access files and devices on your system, socket() creates a descriptor to access computers on your network. It requires information that determines what layers you want to access. The syntax is as follows: #include <sys/socket.h> #include <resolv.h> int socket(int domain, int type, int protocol); The socket() system call accepts several different values. For a complete list, see Appendix A, "Data Tables." For now, you'll find a few in Table 1.1. Table 1.1. Selected socket() System Call Parameter Values Parameter Value Description domain PF_INET Internet IPv4 protocols; TCP/IP stack. PF_LOCAL BSD-style locally named pipes. Typically used in the system logger or a print queue. PF_IPX Novell protocols. PF_INET6 Internet IPv6 protocols; TCP/IP stack. type SOCK_STREAM Reliable, sequential data flow (byte stream) [Transaction Control Protocol (TCP)]. SOCK_RDM Reliable, packetized data (not yet implemented in most operating systems). SOCK_DGRAM Unreliable, packetized data (datagram) [User Datagram Protocol (UDP)]. SOCK_RAW Unreliable, low-level packetized data.
- 13. protocol This is a 32-bit integer in network byte order (see the section on network byte-ordering in Chapter 2). Most connection types support only protocol = 0 (zero). The SOCK_RAW requires specifying a protocol value between 0 and 255. For now, the only parameters the example uses are domain=PF_INET, type=SOCK_STREAM, and protocol=0 (zero). NOTE This book uses the PF_* (protocol family) domains in the socket call, because PF_* domain constants are the proper form. However, most programs use the AF_* (address family) constants interchangeably. Be careful not to get confused when you see source code that uses the AF style. (The C-header files define the AF_* constants as PF_*.) If you want, using AF_* works just as well. However, this may cause incompatibilities in the future. An example for a streaming TCP/IP call looks like this: int sd; sd = socket(PF_INET, SOCK_STREAM, 0); The sd is the socket descriptor. It functions the same way as the file descriptor fd: int fd; fd = open(...); The call returns a negative value when an error occurs and places the error code in errno (the standard global variable for library errors). Here are some common errors you can get: • EPROTONOSUPPORT The protocol type or the specified protocol is not supported within this domain. This occurs when the domain does not support the requested protocol. Except for SOCK_RAW, most domain types support only a protocol of zero. • EACCES Permission to create a socket of the specified type or protocol is denied. Your program may not have adequate privileges to create a socket. SOCK_RAW and PF_PACKET require root privileges. • EINVAL Unknown protocol, or protocol family not available. This occurs when a value in either the domain or type field is invalid. For a complete list of valid values, refer to Appendix A. Of course, you need to know the important header files to include. For Linux, these are
- 14. #include <sys/socket.h> /* defines function prototypes */ #include <sys/types.h> /* standard system data types */ #include <resolv.h> /* defines needed data types */ The sys/socket.h file has the needed function definitions for the Socket API (including socket(), of course). sys/types.h carries many of the data types you use for sockets. NOTE This book uses the resolv.h file for defining the data types. Please note that other Linux distributions or UNIX versions may use the more standard include file sys/types.h. During the writing of this book, the examples were tested on Mandrake 6.0–7.0, which use the odd includes. (It appears that these distribution versions have a bad sys/types.h file that does not include the netinet/in.h file needed for the address types.) The socket() system call does nothing more than create the queues for sending and receiving data, unlike the system call for opening files, which actually opens the file and reads the first block. Only when your program executes a bind() system call does the operating system connect the queue to the network. Using the telephone example again, the socket is just the handset with no telephone or network connection. Executing bind(), connect(), or some I/O attaches the handset to a telephone and the telephone to the network. (If your program does not explicitly call bind(), the operating system implicitly makes the call for you. For more information, see Chapter 4, "Sending Messages Between Peers.") Making the Call: Connecting to the Server After creating the socket, you can get the first "hello?" by connecting to the server. The connect() system call is similar in several ways to calling someone on the telephone: • You identify the destination using a phone number. When you dial a phone number, you're identifying a specific telephone found on the telephone network anywhere in the world. The IP address likewise identifies the computer. Just as telephone numbers have a specific format, the connection requires a specific format to define which computer and how to connect. • The connection provides the channel for messages. Once the telephone is answered, there is a channel through which two or more people may converse. Your telephone number is not important unless the person has to call you back. • The path back to your handset is hidden inside the telephone system. The telephone network has several shared paths, like a computer network. So having a reverse path is important for getting the messages back to your
- 15. handset. The destination peer or server gets the address and port of your program so that it can reply using a similar path. • Your telephone number has to be published for others to call you. If your program is going to accept calls, you must specify a unique channel (or port) and publish it to your clients. The connect() system call's definition follows: #include <sys/socket.h> #include <resolv.h> int connect(int sd, struct sockaddr *server, int addr_len); The first parameter (sd) is the socket descriptor that you created with the socket() call. The last parameter is the length of the sockaddr structure. The second parameter points to different types and sizes of structures. This is important, because this is what makes the socket() calls different from the file I/O calls. Recall that the socket() system call supports at least two different domains (PF_INET and PF_IPX). Each network domain (PF_*) has its own structure to describe the address. They all have one common parent—the one you see in the connect() definition—struct sockaddr. For a complete list of all the structure declarations, see Appendix A. NOTE The sockaddr interface uses data abstraction. Data abstraction simplifies interfaces by asserting that while the data types may change, the algorithms remain the same. For example, a stack can contain different data types, but the function of the stack remains the same: push, pop, and so forth. To use an abstract interface, the first field of the sockaddr structure must have the same meaning. All structures have one common field: ..._family. The field's type is an unsigned 16-bit integer. The value this field holds determines what kind of network domain to use. NOTE The domain type you had set in the socket() system call must be the same value as the first field in the sockaddr family. For example, if your program created a PF_INET6 socket, the structure field must be AF_INET6 in order for the program to work correctly. For now, here is the generic record and the INET record for comparison (from the header files):
- 16. struct sockaddr{ struct sockaddr_in { unsigned short int sa_family; sa_family_t sin_family; unsigned char sa_data[14]; unsigned short int sin_port; }; struct in_addr sin_addr; unsigned char __pad[]; }; Note that sa_family and sin_family are common between the two structures. The task every procedure call executes when it receives this record is to check the first field. Please notice that this is the only field that is in host byte ordering (see Chapter 2). The padding field (named sa_data and __pad) may be common for each in the sockaddr family. By convention, the generic sockaddr structure and the INET sockaddr_in structure have to be 16 bytes long (the IPv6 structure, sockaddr_in6, is 24 bytes). So, the padding field fills out the structure with any unused bytes. You may notice that the length of the padding field in sockaddr_in is missing. This is merely a convention. Since the padding has to be set to zero, the actual size is not important. (In the case of this sockaddr_in definition, it is 8 bytes wide.) Some implementations may define additional fields for internal computations. Don't worry about them—and don't use them, because you can't guarantee the field's availability from system to system and version to version. Any changes may break your code when you use nonstandard fields. In all cases, initializing the entire structure instance to zero is best. The following table describes each field. It also gives examples of possible values. Field Name Description Byte Ordering Example sin_family The protocol family Host, Native AF_ sin_port The server's port number Network 13 (time of day) sin_addr The server's numeric IP address Network 127.0.0.1 (localhost) Before calling the connect() system call, the program fills each field. Linux has masked the system call slightly, so it is not necessary to cast sockaddr_in to be a sockaddr. For portability, you may still want to follow conventions and add the casts. NOTE With other UNIX-compatible OSs, you can cast any of the sockaddr_* family members to sockaddr to avoid warnings. The examples here don't use any casting merely for space (and because Linux allows it). The code may look like Listing 1.2. Example 1.2. Connect() Example
- 17. /************************************************************/ /*** Code snippet showing initialization and calling of ***/ /*** the connect() system call. ***/ /************************************************************/ #define PORT_TIME 13 struct sockaddr_in dest; char *host = "127.0.0.1"; int sd; /**** Create the socket & do other work ****/ bzero(&dest, sizeof(dest)); /* start with a clean slate */ dest.sin_family = AF_INET; /* select the desired network */ dest.sin_port = htons(PORT_TIME); /* select the port */ inet_aton(host, &dest.sin_addr); /* remote address */ if ( connect(sd, &dest, sizeof(dest)) == 0 ) /* connect! */ { perror("Socket connection"); abort(); } ... The connect() system call in this code requires several preparatory steps before you connect the socket to the server. First, create a sockaddr_in structure. Use the server address for the second line. If you want to connect to a different server, place the appropriate IP address in this string. The program proceeds with other initializations, including the socket() system call. When you start working with the structure, zero it out with bzero(). The program sets the family to AF_INET. Next, the program sets the port and the IP address. The htons() and inet_aton() conversion tools used here are covered in Chapter 2. The next call is the connection to the server. Please note that the code fragment checks the return values for every procedure call. That policy is one of many keys to making your network programs robust. After the program establishes the connection, the socket descriptor, sd, becomes a read/write channel between the two programs. Most servers we are accustomed to offer single transactions and then hang up (for example, an HTTP 1.0 server sends the requested file, then closes the connection). To interface with these types of server, your program has to send the request, get the reply, and close the connection. Getting the Server's Reply The socket is open and the channel is established. Now, you can get the first "hello." Some servers initiate the conversion lik e the person answering the phone. This message may include the server's name and some instructions for connection. Once your connection is open, you can use the standard library low-level I/O calls for communication. Here is the read() system call: #include <unistd.h> ssize_t read(int fd, void *buf, size_t count);
- 18. You're probably familiar with this call. Other than its special capability to use the socket descriptor (sd) instead of the file descriptor (fd), everything else is almost the same as reading from a file. You can even use the read() system call as in the following code fragment: ... int sd, bytes_read; sd = socket(PF_INET, SOCK_STREAM, 0); /* create socket */ /**** Connect to host ****/ bytes_read = read(sd, buffer, MAXBUF); /* read the message */ if ( bytes_read < 0 ) /* report connection error; exit routine */ ... In fact, you could convert the socket descriptor into a FILE* for higher-level I/O. For example, to use fscanf(), you could follow the example below. (The lines in bold indicate the changes from the previous listing.) char Name[NAME], Address[ADDRESS], Phone[PHONE]; FILE *sp; int sd; sd = socket(PF_INET, SOCK_STREAM, 0); /* create socket */ /**** Connect to host ****/ if ( (sp = fdopen(sd, "r")) == NULL ) /* convert to FILE* */ else if ( fscanf(sp, "%*s, %*s, %*s n", /* use as usual */ perror("FILE* conversion failed"); NAME, Name, ADDRESS, Address, PHONE, Phone) < 0 ) { perror("FScanf"); ... Only stream-style sockets can be converted reliably into a FILE* stream. The reason is simple: Datagram sockets are typically connectionless—a message is sent and that's it. Also, streaming sockets provide data integrity and message reliability, whereas datagrams are unreliable. Datagrams are similar to putting a message in an addressed and stamped envelope that you send through the postal system: The message may not arrive at all. A FILE* connection must be an open channel. If you try to convert a datagram, you may lose critical data. For more information about streams versus datagrams, see Chapter 3, "Different Types of Internet Packets." FILE* socket connections provide excellent scanning and parsing resources for the network programmer. However, when you use them, you must check all return values, including *printf() and *scanf(). Note the preceding example: If the return value of fscanf() is less than zero, there was an error.
- 19. NOTE Security and reliability are of the utmost importance when you create network programs. At the time of writing this book, Microsoft operating systems have faced several fundamental security problems, several involving network connections. When you write your programs, make sure that buffers cannot be overflowed and all return values are checked. In a software bazaar setting, you can solicit input from others on your source code. The peer review of the software bazaar is a vast resource of knowledge and experience—use it. Referring back to the read() system call, you may get the following common errors: • EAGAIN Nonblocking I/O is selected, and no data is available. This error instructs the program to try the call again. • EBADF fd is not a valid file descriptor or is not open for reading. This can occur if the socket call was unsuccessful or the program closed the input pipe (making it write-only). • EINVAL fd is attached to an object that is unsuitable for reading. The read() system call provides no special control over the way it uses the socket. Linux offers another standard system call, recv(). You can use recv() directly with the socket descriptor for getting information while providing you with more control: #include <sys/socket.h> #include <resolv.h> int recv(int sd, void *buf, int len, unsigned int flags); The recv() call is no different from the read() call except for the flags. The flags give you more control over what you get or even flow control. These values can be arithmetically ORed together (FLAG1 | FLAG2 | ...). Under normal circumstances, the parameter is set to zero. You may wonder why not use the read call if it's no different than read() when the flags are zero. Just as a suggestion, use recv() instead of read()—it may help you later as your program becomes more complex. Also, generally speaking, it's better to use one tool set rather than mixing tools. Finally, read() checks what kind of I/O descriptor you sent and executes the appropriate system call. Here are a few useful flags you can use to control the recv() system call. You can find a more complete listing in Appendix B, "Networking API." • MSG_OOB Process out-of-band data. Used for higher priority messages. Some protocols allow you to choose between a normal and a high priority when you send a message. Set this flag to have the queue manager look for and return out-of-band messages instead of normal data. See Chapter 10 for more information.
- 20. • MSG_PEEK Read nondestructively. Used to tell the queue manager to read the message queue without moving the read-index pointer. (In other words, a subsequent read yields at least the same data each time. See the box on the next page.) • MSG_WAITALL Used so that your message doesn't return until the supplied buffer is filled. Sometimes you get only a partially filled buffer, because the remaining data is in transit. If you know how much information the server is sending and you don't want to reassemble it yourself, use this flag to fill the buffer (or wait forever). • MSG_DONTWAIT Used so that your message doesn't block if the queue is empty. Similar to setting the nonblocking feature on the socket, only requiring this option on this recv()system call exclusively. Normally, if no message data is available, the process waits (blocks) until some data arrives. If you use this flag and the queue has no data available at the time of the call, the system call returns immediately with an EWOULDBLOCK error code. (Linux does not currently support this option in the recv() call. You can use O_NOBLOCK with the fcntl() system call. This makes the socket always nonblocking.) NOTE Your programs are going to execute much faster than the network does. Sometimes a packet arrives at the computer in pieces, because the network routers fragmented it to fit more limited networks. If you call recv() when this occurs, you may get an incomplete message. This is one reason why MSG_PEEK could give you different results with consecutive calls: The first call may yield 500 bytes, and the second could be 750 bytes. Likewise, this is why there's a MSG_WAITALL flag. The recv() system call is more flexible than read(), letting you use the different flags to modify behavior. Do a normal read from socket pipe (equivalent to read()): int bytes_read; bytes_read = recv(sd, buffer, MAXBUF, 0); ... Read nondestructively from socket pipe: int bytes_read; bytes_read = recv(sd, buffer, MAXBUF, MSG_PEEK); ... Read nondestructively out of band data from socket: int bytes_read;
- 21. bytes_read = recv(sd, buffer, MAXBUF, MSG_OOB | MSG_PEEK); ... The first statement gets the information from the server supplying a buffer, length, and no flags. The next statement displays the information. There is an intentional flaw here: What if the server sends more information than the buffer can accept? This is not a critical defect; nothing is going to crash. The algorithm simply may lose the data it doesn't read. The recv() system call yields similar error codes to read() along with the following extensions: • ENOTCONN sd not connected. The supplied socket descriptor is not connected to the peer or server. • ENOTSOCK sd not a socket. The supplied socket descriptor does not have the signatures indicating that it came from a socket() system call. Note that if you use the read() system call, you can still get these error codes when using a socket descriptor, because the read() call is just a portal to the recv() call. Closing the Connection You have the information you need from the server, everything went well, and now you want to close the connection. There are again two ways you can close the connection. Most programs use the standard I/O close() system call: #include <unistd.h> int close(int fd); Again, the socket descriptor (sd) may substitute for the file descriptor (fd). It works the same. If successful, the return value is zero. NOTE Make it a point always to close descriptors manually, particularly sockets. By default, the operating system closes all descriptors and flushes buffers for you. If the descriptor refers to a file, the process works without affecting other systems. Sockets, on the other hand, can linger longer than necessary, tying up resources and making it difficult for other clients to connect. This call yields only one error: • EBADF fd isn't a valid open file descriptor.
- 22. The shutdown() system call gives you more control over closing the channels, because you can close either the incoming or outgoing channels. This call is especially helpful when using sockets to replace stdin or stdout. NOTE The shutdown() system call is different from the shutdown command (section 8 of online UNIX manuals) for bringing down the operating system. With the shutdown() system call, you can close different directions of data flow in the communication path, making the path read-only or write-only: #include <sys/socket.h> int shutdown(int s, int how); The how parameter can have three values: Value Function 0 (zero) Write only (think of "O" in "output") 1 (one) Read only (think of "I" in "input") 2 Close both input and output Summary: What's Going On Behind the Scenes? Several things occur behind the scenes when the program opens a socket and connects to a TCP server. All the socket call does is create a message queue. Things really happen when the program connects. (You can get the complete program listing on the companion CD.) Table 1.2 shows what happens on the client and server sides. Table 1.2. Steps of Creating a Socket and Connecting Client's Actions Server's Actions 1. Calls socket(): Creates a queue; sets flags for communication protocols. (Waiting for connection) 2. Calls connect(): The operating system assigns a temporary port number if the socket doesn't have an assigned port number through bind(). (Waiting) 3. Sends a message to the server requesting a connection, telling the server which port the client is using. (Waiting for server) 4. Places the connection request on the listening queue. (Waiting) 5. Reads the connection queue, accepts a connection, and creates a unique socket channel. (Waiting) 6. Creates (sometimes) a unique task or thread to
- 23. interact with your program. (Waiting) 7. Sends back a confirmation that the connection is accepted. Either sends a message to your port or awaits a request from your program. The server may close the channel after sending the data, if it provides simple bulletin messages (like time-of-day). 8. Begins data correspondence. That's quite a bit for a simple connect() call. This process could get much more complicated, especially for the routing computers in between (such as routing management, packet verification, fragmentation and defragmentation, protocol translation, tunneling, and so on). The Socket API considerably simplifies network communication. The network requires a particular language and algorithm in order to establish a connection. First and foremost, the socket() system call starts the ball rolling by creating the telephone handset. This handset allows a program to send and receive messages it is connected to. The program may use regular read() and write() as used in pipes and file descriptors. Alternatively, you can use the more specialized system calls like recv(). The IP network has several features that require further explanation. The next chapter expands IP numbering, ports, and byte ordering. It explains very useful tools to convert the information, simplifying your programming efforts. Chapter 2. TCP/IP Network Language Fluency IN THIS CHAPTER • An IP Numbering Overview • IP Host Port Numbers • Network Byte Ordering • Different Kinds of sockaddr • UNIX Named Pipes • Summary: Applying IP Numbering and Tools Working with the Internet requires you to know how to address messages so that they arrive correctly. Addressing is an important part of creating messages. Like the telephone, a computer must have an address or ID so that it can get the right messages and other computers can direct the traffic accordingly. The previous chapter introduced you to the socket. This chapter expands the topic with more of the Socket API. First it discusses the IP numbering system, how routing works at an abstract level, correct binary formats, and different socket types. An IP Numbering Overview The IP numbering uses a fixed-length address. This restriction required a great deal of planning when the protocol was designed. The protocol provided solutions to several
- 24. issues during its lifetime: computer identification, network organization, routing, and address resolution. Now it faces new issues such as explosive growth and address loss. Computer Identification Networks involve sharing a single resource (the network cable) with several computers. Because of all the information that could flow on a network medium, each computer must accept the information. However, if every computer on your network were named Bert or Ernie, other hosts would not be able to determine the actual destination. Every network computer requires a unique identification (ID). But that is not all. NOTE A workstation does not work very well with the network when it shares an address (address collision). Anyone who has tried to track down an address collision can attest that it is pretty hard to fix. It's even worse when one of the computers is supposed to be using some dynamic address allocation (like DHCP). The most obvious (and laborious) way to solve this problem is to look at each computer in the area. Networks are dynamic and tend to increase in complexity. The computer has to be easily locatable by its ID as the network expands. All information placed on the network consumes a portion of that valuable real estate, so no unnecessary information should be included in the message. Some networking systems include a routing map in the message. Each server in the list gets the message and passes it on to the next server. This approach reduces the throughput of the network by lowering the ratio of header to real data. If you encode the directions to the destination in the address itself, the routing map becomes unnecessary. Network-connected computers already have a unique ID called the Media Access Control (MAC); one example is the ethernet ID. Your computer uses this ID to do network booting (diskless systems that only have RAM and all permanent storage is on a server). The ethernet ID is six bytes long, and you usually see it written in hexadecimal: 00:20:45:FE:A9:0B. Every ethernet card has one, and it is unique. Unfortunately, you cannot use that ID for identifying your computer exclusively. It has two fundamental problems. First, every routing server must acquire every ID on the network. The database of IDs could get very large and could significantly slow the routing time for each message. Second, not every interface has a MAC (PPP, for example). The computer ID could have a built-in mechanism for routing the message. This mechanism is like addressing a letter: most general to most specific. Internet IDs solve the uniqueness issues while providing hints for the routing issues.
- 25. IP addresses provide several advantages over the hardware-supplied MAC. First the number can change (it is not fixed), so deploying consistent clusters of addresses is easier, and laptops don't run into problems. The network can map the IP to the hardware MAC using the Address Resolution Protocol (ARP). See the Request For Comment #826 [RFC826] on the accompanying CD-ROM. NOTE The ARP is a simple translation table that takes the IP and fills in the associated MAC. All messages on the network must have a MAC so that the adaptor (or drivers) can pick up the message. The source may not know the MAC of the destination host, which hides deeply behind several routers. The router instead sends the message to routers that control the sub-networks (or subnets) defined in the IP address. When the message gets to a router with ARP, it checks the tables. If the router find the IP address, the packet's MAC gets the correct destination. Otherwise, the router sends a broadcast into the subnet to resolve the IP address. Internet ID Organization The Internet ID uses a most-to-least–specific addressing scheme. Each ID is a four- byte number, like the ethernet ID. The first number, reading from left to right, is the network class. Look at Figure 2.1. Figure 2.1. The IP address has several parts that identify network granularity. The IP address acts as a general roadmap to the routers. Each part of the address provides more specific information about where the destination is. Beginning with the network class, the address ends with the host number. You could easily compare it to an address on an envelope: The first line is the addressee, then the street address or box number. The detail decreases in the address until the state or country. Internet addressing has five basic address classes. Each class is a block of allocations for very large to small networks. The Internet addressing plan is organized so that companies may buy segments from the addressing space. The classes are labeled A–E: Class Address Address Range, Description 0.0.0.0 to 0.255.255.255 (Reserved)
- 26. A 1.0.0.0 to 126.255.255.255 224 –2 or 16,777,214 nodes for each allocation segment. This class has 126 segments. Used in very large organizations that subnet as needed, such as Internet service providers (ISPs). 127.0.0.0 to 127.255.255.255 (Reserved for loopback interface) B 128.XXX.0.0 to 191.XXX.255.255 216 –2 or 65,534 nodes for each allocation segment. This class has 64×256 available segments. Used in large organizations such as companies and universities. They may create subnets. The XXX is the allocated and assigned subnet (for example, 129.5.0.0 is an allocated subnet). Note: This address space is almost used up. C 192.XXX.XXX.0 to 223.XXX.XXX.255 28 –2 or 254 nodes for each allocation segment. This class has 32×65,536 available segments. Small companies or individual. The address has several slots available here. D 224.0.0.0 to 239.255.255.255 228 –2 or 268,435,454 nodes. These addresses are not allocated but are reserved for multicasting addresses. E 240.0.0.0 to 255.255.255.255 228 –2 or 268,435,454 nodes. These are reserved for future use. Please note that 255.255.255.255 is a general broadcast IP address. It is never a legal address. The network classes are numbered peculiarly, because the addressing uses the first bits of the address to determine the class. For example, the Class A network has a zero in the first bit of the address. Likewise, the Class B has a one in the first bit and a zero in the second bit: Class A: 0 (0000,0000) to 126 (0111,1110) Class B: 128 (1000,0000) to 191 (1011,1111) Class C: 192 (1100,0000) to 223 (1101,1111) Class D: 224 (1110,0000) to 239 (1110,1111) Class E: 240 (1111,0000) to 255 (1111,1111) Using this approach historically, the routers on the network can quickly determine (within four bits) whether to let the message enter the gate. Today the routing is more efficient, using Classless Internet Domain Routing (CIDR). These new definitions (found in RFCs 1517–1519) identify the location and route of a host using the upper bits of the address. The IP protocol introduced this numbering scheme for computer identification to cluster these computers in an efficient way. With it, a router can quickly determine whether to block a packet or move it to the interface that leads to the destination
- 27. subnet. Propagation is very important: Simply receiving a packet, checking it, and passing it on is not acceptable. Each bit that the router accepts means a delay on the network. The router must delay no more bits than necessary to determine the relevance. In other words, it must be invisible to propagation delays. For example, typical telephone switching in the United States of America does not try to resolve the whole phone number at once; the first three digits indicate an area or region, and the next three digits indicate the station. Subnetwork Masks Some of the classes require more filtering. A network with 16 million nodes is excessive if all are clumped in one space. As you set up your Linux computer and configured the network, you may have noticed the term subnet mask. The introduction of CIDR has helped to simplify the complexity of large subnets [RFC950]. The network subnet mask is specifically for identifying the group of contiguous addresses an interface can reach. It provides an additional filter that permits only specific messages to pass through. When a message arrives, the router uses the subnet mask on the message's destination address. If it matches, the router passes the message on. You may build mask any way you wish, but the least significant set bit specifies the subnetwork. For example, if you had a small network of eight machines, and you expected the group to grow by no more than five machines, you could set your router subnet mask to 187.35.209.176. The last bit in the address is in the 176 (1101,0000). The address range is in 'X'part (active subnet) of 1101,XXXX. From here, you can dole out the addresses: 187.35.209.176 (router), 187.35.209.177 (host #1), up to 187.35.209.222. You can have any combination, but the least significant set bit is the marker. NOTE Using the network mask as a host address may cause conflict and lose packets. This is due to the special address 0 (zero). The example, 187.35.209.0, has the last eight bits as zeros. If the address matches the network mask, it is the zeroth address. You should always reserve the zeroth address for the network address mask. Likewise, you may have noticed that the example omits 187.35.209.223. If you were to use that ID, that host may never see a message. The number 223 has the active subnet as all ones: 1101,1111. This is a broadcast address. You should not use that as a host address. In most cases you do not need to worry about setting up routers, and the configuration is beyond the scope of this book. Usually, when you see the subnetwork mask in the network configuration, you can accept the mask that the script offers you. Routers and Address Resolution
- 28. Local area networks (LANs) can become very burdened by all the messages between hosts. Every computer on the Internet potentially could hear every message. But with all the traffic, the networks become very cluttered, packets collide with others (simultaneous transmissions), and throughput drops to near nothing. LANs use addressing and submasking to limit the traffic within groups (or clusters) of computers. Beyond passing messages to the appropriate interfaces, routers act as information control gates that localize the traffic. Local traffic stays inside the cluster, and external traffic passes through. The host uses the subnet mask to determine if it must pass a message to the router. All messages destined for the outside pass through the router, and local messages remain inside the subnetwork. This process reduces congestion on the network backbone. Routers also direct messages toward the destination using their routing tables. Each router tells others on the network what it can accept for directing traffic. Wide area networks (WANs) use this feature to deliver messages. Each step along the way between the source and the destination looks at the IP address, comparing the networks with the routing tables. The routers move your message toward a more and more specific destination. The first hop tries to resolve it in the cluster, the second moves the message up to resolve in the subnetwork, and so on, until it resolves the class. As soon as a router finds a match (either general or specific), it moves your message in that direction, using the MAC address to send the message to the next router. Eventually the matched cluster gets the message, and the router's ARP replaces the router MAC with the destination MAC. An ethernet network adapter accepts only messages with its ID. As soon as the host boots up and stabilizes, it tells everyone else on the subnetwork its ethernet ID and IP address. This is the function of ARP, as mentioned previously. Special and Dwindling Addresses As mentioned earlier, there are some reserved addresses. The active subnet of a subnetwork mask has two reserved addresses: all zeros (network) and all ones (broadcast). This means that when you count how many address you have at your disposal, you must subtract 2 from that number. Consider this: If you create 100 subnetworks, you effectively lose 200 addresses. This loss is just the beginning. Two large blocks of addresses are reserved for internal use: 0.0.0.0 to 0.255.255.255 and 127.0.0.0 to 127.255.255.255. The first address group means "this network" in IP shorthand (see the shaded note that follows). If you have a network address of 128.187.0.0, using 0.0.25.31 in a message results in 128.187.25.31, implicitly. In 1992, the Internet Activities Board (IAB—see RFC1160 for the design, engineering, and management of the Internet), became very concerned with the explosive growth of the Internet—even with all the addressing techniques and careful
- 29. planning. The allocation of addresses exceeded 450 million nodes. The Board saw increased allocations chewing up the available address space. However, only about 2% of the allocations were actually used. Where were all the remaining addresses? IAB allocates address ranges to companies in whole blocks. The companies, in anticipation of additional use and to keep their addresses as contiguous as possible, buy larger ranges than they need. NOTE One small place I worked showed me its allocation of 128 addresses; only 30 were in use at the time. They carved out 10 slots for me. I never used more than 2. To this day, I think those addresses may still be allocated to me, even though I left the company about four years ago. In all, address exceptions and squandered allocations have eaten up most of the address space. Recent estimates indicate that Class B and Class C networks are full. ISPs are using more of Class A. Before long, the demand may use up all the addresses. What is the Internet going to do with the lost address space? How can the current IP addressing be better used? The IAB, now called Internet Corporation for Assigned Names and Numbers (ICANN), cannot easily reclaim the unused slots sold to companies, because the companies'IT departments have already allocated those addresses within the organization. Many companies now use Dynamic Host Configuration Protocol (DHCP) [RFC2131], which allocates an IP address upon bootup. No host owns an IP address permanently. DHCP also helps with security: Computer crackers love fixed IP addresses. If you recall, bootp sends out a broadcast message to find a bootp server. When found, the server issues an IP address. Similarly, a normal host loads its DHCP requestor during bootup. The requestor sends a broadcast message to find a responsive DHCP server. When found, the server allocates an address from its pool of available addresses and passes it (along with the appropriate network mask) to the requestor. The DHCP requestor accepts the information and configures the local host's network protocols. In some cases this can take several seconds, due to network congestion. Until the local host is properly configured, it may suffer from IP amnesia (the host won't know its own address). NOTE Host or IP amnesia also occurs when network and host naming are not properly set up. This can be a significant problem. Even ping 127.0.0.1 may not work. If your host has amnesia, check your distribution. The RedHat Distribution (and derivatives) use /etc/sysconfig/network and /etc/sysconfig/network- scripts/ifcfg-* to define and set the values.
- 30. Another solution is to lengthen the IP address size itself. Introducing: IPv6 [RFC2460]! IPv6 in a nutshell is four times the size of an IP address: 128 bits versus 32 bits. IPv6 changed the appearance dramatically as well: <$nopage> 001 8008:4523:F0E1:23:830:CF09:1:385 002 <$nopage> The result is a not-so-memorable address. The primary advantage of IPv6 is that it has a much larger address space to work with. More than 3×1038 addresses probably removes any problem of address limitations for a very long time. See Chapter 17, "Sharing Messages with Multicast, Broadcast, and Mbone," for more information. IP Host Port Numbers All messages arrive at one or more recognized address. If a program accepts these messages, it may receive information destined for other running programs. The operating system has little regard for where the message goes, as long as it delivers. The TCP/IP stack adds the concept of a port. One system can have several ports available, all associated with the same address. The TCP/IP stack adds the ports to abstract the network and ease programming for you. These are not real, physical ports. They are channels that the networking subsystem uses to redirect information to the appropriate program. All network programs no longer receive all messages; they receive only the messages for their port. Every typical IP data packet on your Internet-based network has the address of the host and the port number. When a packet arrives from the network, the 16-bit field in the packet header indicates the destined port number. The operating system reads this field and places the new packet on the port's queue. From there, the program reads the socket (with either the read() or recv() system call). Likewise, when the program transmits a message (via the write() or send() system call), the operating system places the data in the port's outgoing queue. By default, only one program owns a port. In fact, if you attempt to run two programs that allocate the same port number on the same computer, the system call returns an EINVAL error code. You can elect to share a port using SO_REUSEADDR (see Chapter 9, "Breaking Performance Barriers"). NOTE The rule that no two sockets can share the same port applies to symmetric processors as well. The reason is simple: The processors, like resources, share the memory and operating system. If you were to have two operating systems running, you could theoretically have two sockets in separately running programs with the same port number, as long as they reside in different operating system spaces.
- 31. All the standard services have assigned port numbers. You can see the complete list in /etc/services, in Appendix A, "Data Tables," and on your Linux workstation. Here are a few standard ports: Port Service Name, Alias Description 1 tcpmux TCP port service multiplexer 7 echo Echo server 9 discard Like /dev/null 13 daytime System's date/time 20 ftp-data FTP data port 21 ftp Main FTP connection 23 telnet Telnet connection 25 smtp, mail UNIX mail 37 time, timeserver Time server 42 nameserver Name resolution (DNS) 70 gopher Text/menu information 79 finger Current users 80 www, http Web server You can find a more complete list in Appendix A. You probably recognize a few of these services. The file's format is clear: Port Number, Service Name, Alias, and Description. You can interact with many of them using Telnet or the program listed earlier. Note that even though /etc/services may list a server, the computer may not have the associated server running (for example, the Mandrake distribution does not enable the time services). All the ports listed in the /etc/services file are reserved, so any use may cause conflicts. Your sockets-based program uses some local port for all communication: This is bind()'s primary responsibility. Even if you do not use the bind() system call, as soon as your program uses the socket for any I/O, the operating system assigns an available local port to the socket. NOTE As part of the kernel's security, ports with values less than 1024 require root or privileged access. For example, if you wanted to create a time server (port 13), root would have to run that program (or SUID root). SUID is an acronym for "set user ID." Each program in the file system can allow users to run it as if the owner were running it. Normally, when a user runs a program, the program has the same rights as the user. Sometimes the program needs different or extra rights. By switching the user ID, the program can run as if the owner were running the program. For example, /usr/bin/at requires accessing the cron tables (owned by root). For this to occur, /usr/bin/at must switch automatically to root access. For more information, refer to standard UNIX documentation. Warning: SUID root is a potential source of security risks. Never create or set the SUID while you are root, unless you know the program very well and know all the risks.
- 32. As noted previously, if you do not assign a port to a socket, the operating system assigns one for you. These automatically or dynamically assigned ports are called ephemeral ports. Linux appears to follow the BSD style in port assignment: It assigns port 1024 and greater to ephemeral ports. NOTE When experimenting with different ports, you may want to follow these simple rules: Program, run, and debug as a regular user (not as root). Use ports and addresses that do not affect others or cause security risks. Log the source of all incoming messages. Network Byte Ordering Many different types of computers may reside on a network, but they may not all use the same processor. Not all processors store their binary numbers in the same way. Computers use two basic types of binary number storage: big-endian and little-endian. Simply, big-endian numbers read from left to right; little-endian numbers read from right to left. For example, consider the number 214,259,635. In hexadecimal, the number reads as #0CC557B3. A big-endian processor stores this value like this: Address: 00 01 02 03 04 Data: 0C C5 57 B3 ... Note that the most significant byte (0C) is listed first. The little-endian processor stores it in reverse: Address: 00 01 02 03 04 Data: B3 57 C5 0C ... Note that the least significant byte (B3) is listed first. Usefulness of the different endianness is a long-debated topic. This is not to resurrect these discussions, only to point out the important uses and differences. Of course, why couldn't you just use hexadecimal ASCII? The representation is inefficient, essentially doubling the number of needed bytes. For computers on a heterogeneous network to communicate efficiently, they have to use binary and must settle on one endianness. The endianness of the computer or host is the host-byte order. Likewise, the endianness of the network is called network-byte order. The network byte order is always big-endian.
- 33. Using Internet Conversion Tools Many years ago, the network protocol chose to speak big-endian. That's just fine for big-endian processors, but what about little-endian ones? Several tools are available that help do the conversion. Network programs use these tools all the time for filling the struct sockaddr_* structure, regardless of the process's endianness. Now, for another hitch: Not all fields in the structure are network ordered. Some are host ordered. Consider the code excerpt from Chapter 1, "Introducing the Cookbook Network Client": /************************************************************/ /*** Conversion tools example: filling sockaddr_in ***/ /************************************************************/ struct sockaddr_in dest; char *dest_addr = "127.0.0.1"; ... dest.sin_family = AF_INET; dest.sin_port = htons(13); /* port #13 (time server) */ if ( inet_aton(dest_addr, &dest.sin_addr) == 1 ) { ... The code is filling three fields: sin_family, sin_port, and sin_addr. sin_family is a host-ordered field, so it does not need conversion. The other two are network ordered. The two-byte field sin_port converts port 13 using htons(). There are several converters like this: Call Meaning Description htons Host to Network Short Converts 16-bit binary to big-endian. htonl Host to Network Long Converts 32-bit binary to big-endian. ntohs Network to Host Short Converts 16-bit to host format. ntohl Network to Host Long Converts 32-bit to host format. Appendix B, "Networking API," lists these functions with greater detail. You may be interested to know that using these tools does not cost anything in CPU time if your computer is already big-endian (network-byte ordered). The next call in the example, inet_aton(), converts the ASCII IP address (using dot-notation) into the equivalent binary. It also converts into the network ordering (you don't need to call htonl() on the result). Here are a few others: Call Description inet_aton() Converts dot-notation (###.###.###.###) into network-ordered binary. It returns zero if it fails and nonzero if the address is valid. inet_addr() Obsolete (same as inet_aton). It does not handle errors correctly. If an error occurs, it returns -1 (255.255.255.255—the general broadcast address). inet_ntoa() Converts a binary, network-ordered IP into ASCII dot-notation. gethostbyname() Asks the name server to convert the name (such as http://www.linux.org) into one or more IP address.
- 34. getservbyname() Gets the port and associated protocol for a service in the /etc/services file. The libraries offer you many more function tools than these. This book covers only a few that are consistently useful. For more information on these function calls, see Appendix B. NOTE For those of you who think that you may not have to worry about these conversion tools, consider this: The whole idea of writing Linux software is to make it compatible with all systems, right? It does not hurt anything to use these calls despite the platform. Generally it's good programming practice to program as if it were to be ported to another processor. If you are trying to convert one format to another, you may find the appropriate converter in some library. That's the beauty of using established technology like POSIX compatibility. Of course, that means that there are many tools to look through. It helps to have the tools grouped by function. (That is why this book includes several relevant manual pages in the appendices.) Applying the Tools and Extending the Client The next step is to extend the time reader's functionality with the capability to send a message and get the reply. Again, the socket descriptor is interchangeable with the file descriptor. Just as you can use read(), you can use write(): #include <unistd.h> ssize_t write(int fd, const void *buf, size_t count); Here are some common errors you may encounter: • EBADF fd is not a valid file descriptor or is not open for writing. For example, the program already closed the socket descriptor, or the socket was never properly opened (check the return value of the socket() call). • EINVAL fd is attached to an object that is unsuitable for writing. This might happen if the program had previously shut down the writing channel. • EFAULT An invalid user space address was specified for a parameter. The buf pointer is not pointing to legal space. When the call tried to access the memory region, it got a segmentation violation. • EPIPE fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process receives a SIGPIPE signal; if it catches, blocks, or ignores this, the error EPIPE is returned. This error occurs only upon the second write() call. A scenario might be 1. A client connects to the server and sends some data.
- 35. 2. The server reads part of the message, then closes the connection (or crashes). 3. Not knowing any problem, the client sends the next block of data. Likewise in the write() call, you can substitute the file descriptor (fd) with the socket descriptor (sd). As an example, here is a snippet showing a typical socket output with write(): int sd, bytes_written = 0, retval; sd = socket(AF_INET, SOCK_STREAM, 0); ... /*** Connect to host ***/ while ( bytes_written < len ) /* repeat sending until all */ { /*...bytes of message are sent */ retval = write(sd, buffer+bytes_written, len); if ( retval >= 0 ) bytes_written += retval; else /*---report connection error---*/ } On the other hand, here is a snippet showing a typical socket output with fprintf() by converting the socket descriptor into a FILE*: FILE *sp; int sd; sd = socket(AF_INET, SOCK_STREAM, 0); ... /*** Connect to host ***/ sp = fdopen(sd, "w"); /* create FILE* from socket */ if ( sp == NULL ) perror("FILE* conversion failed"); fprintf(sp, "%s, %s, %s n",Name, Address, Phone); Note that in the first example, the program has to loop on the write() to get all the bytes out. Even though this is a socket stream, you cannot guarantee that the program sends all the bytes at once. The second instance does not have that limitation, because FILE* has its own data-buffering subsystem. When you write to a FILE* buffer, the subsystem forces you to wait until it sends all the bytes. There is, of course, a dedicated socket write call: send(). Like the recv() call, send() gives the programmer more control over the execution of the transmission. The prototype declaration is #include <sys/socket.h> #include <resolv.h> int send(int sd, const void *msg, int len, unsigned int flags);
- 36. All the parameters are the same as write() except for the last—flags. The send() system call has several options that help revise the call's behavior: • MSG_OOB Send "Out Of Band" data. As used above, it allows you to send one byte to the peer, client, or server indicating an urgent condition. The receiver has only one byte dedicated for OOB data; subsequent OOB messages overwrite the last message. When an OOB message arrives, the operating system issues a SIGURG (urgent signal) to the responsible program. • MSG_DONTROUTE Don't allow routing the packet. This causes the packet to bypass the routing tables, forcing the network to try to contact the receiver directly. If the destination is inaccessible directly, the call yields an ENETUNREACH (network unreachable) error. Only diagnostic or routing programs use this option. • MSG_DONTWAIT Don't wait for send() to finish. This option allows the program to proceed as if the send() were done (or delegated). If used, the operating system issues a SIGIO signal, indicating a completed write() operation. If the operation blocks because the send() queue is full, the call returns an error and sets errno to EAGAIN. • MSG_NOSIGNAL Don't issue a SIGPIPE signal. If the other end closes early, and if your program sends another message, your may get a SIGPIPE signal. If you are not prepared for this signal, your program aborts. Using the send() system call is similar to using recv(). If you want to aggregate the flags, you use the arithmetic OR operator: /************************************************************/ /*** Do a normal write to socket pipe ***/ /************************************************************/ int bytes_sent; bytes_sent = send(sd, buffer, MAXBUF, 0); ... /*--------Send any out of band data from socket pipe--------*/ int bytes_sent; bytes_sent = send(sd, buffer, MAXBUF, MSG_OOB | MSG_NOSIGNAL); ... The second example selects MSG_OOB and MSG_NOSIGNAL. Remember that these examples differ from the write() system call by adding a new parameter for controlling the socket. Also, the socket must be connected to the server or host in order to use write(). Here are some errors you may encounter: • EBADF An invalid descriptor was specified. The likely cause is the program did not check the return value of the socket() call. • ENOTSOCK The argument is not a socket. Perhaps it mixes file and socket descriptors. • EMSGSIZE The socket requested the kernel to send the message atomically, and the size of the message to be sent made this impossible. Broadcast messages
- 37. cannot be fragmented, or the program set the socket option for "don't fragment." • EAGAIN The socket is marked nonblocking and the requested operation would block. This is not an error, merely a "not ready yet." Try sending again later. • EPIPE The local end has been shut down on a connection-oriented socket. In this case the process also receives a SIGPIPE unless MSG_NOSIGNAL is set. (Same as EPIPE in the write() system call.) You use the send() system call to prompt a server. For example, if you want to use the network finger on a server, you open a channel to the server's port (79), send the username, and read the response. This algorithm is typically what the client does. You don't need any special options to do this task. However, you may want to read as much information as the server sends you. Sometimes the reply may be larger than your buffer size. The following program listing excerpt shows you the implementation of the algorithm. You can get the complete program listing on the CD-ROM that accompanies this book. /************************************************************/ /*** Expanding the port tester – add the capability to ***/ /*** access any port and to send a message. ***/ /************************************************************/ int main(int count, char *strings[]) { int sockfd; struct sockaddr_in dest; char buffer[MAXBUF]; /*--- Create socket and assign a port number ---*/ sockfd = socket(AF_INET, SOCK_STREAM, 0); bzero(&dest, sizeof(dest)); dest.sin_family = AF_INET; dest.sin_port = htons(atoi(strings[2])); inet_addr(strings[1], &dest.sin_addr.s_addr); /*--- Connect to server & send request ---*/ if ( connect(sockfd, &dest, sizeof(dest)) != 0 ) PANIC("connect() failed"); printf(buffer, "%s n", strings[3]); send(sockfd, buffer, strlen(buffer), 0); /*--- Clear buffer and read SHORT reply ---*/ bzero(buffer, MAXBUF); recv(sockfd, buffer, MAXBUF-1, 0); printf("%s", buffer); close(sockfd); return 0; } If you want to use this algorithm to get a long reply, you need to change the last section to the following: /************************************************************/ /*** Revising the code to get lengthy replies ***/
- 38. /************************************************************/ /* do --- Clear buffer and read SHORT reply ---*/ { bzero(buffer, MAXBUF); bytes = recv(sockfd, buffer, MAXBUF, 0); printf("%s", buffer); } while ( bytes > 0 ); close(sockfd); This addition works correctly if the server closes the connection after sending you the data. Otherwise, your program waits indefinitely for data. Waiting for information is a particular problem with socket programming. Sometimes you can trust the server to close the connection when it is done sending. However, some servers expect to leave the channel open until the client closes it. Be aware that if your program waits for a long time, you may be facing that type of problem. Different Kinds of sockaddr The network supports several different types of protocols. Each protocol has specific functions and features. To the network, it is all just packets. Packet types include Named Sockets PF_LOCAL Actually does not connect to the network. This is strictly for processing queues using the file system. Internet Protocol PF_INET (Already demonstrated.) Novell Protocol PF_IPX For communicating with Novell networks. AppleTalk PF_APPLETALK To communicate with AppleTalk networks. You can find more of the defined and supported protocols in Appendix A. Each type uses its own naming systems and conventions, and all of them use the Socket API. This should make programming them rather straightforward. Regrettably, there is too much to include here, so this text primarily focuses on the Internet Protocol. UNIX Named Pipes Just briefly, consider how syslog works. Here's the problem: how do you coordinate several applications that may issue errors or messages at different times? The syslog is a tool that accepts messages like these. The Socket API already has this coordination built in. Named sockets allow several local programs to submit messages (or packets). They are named, because they actually create a file in the file system. The communication is local only; nothing passes through the network, and no network client can connect to it.
- 39. It works like a regular socket: You can create a stream connection or a datagram connection. The only difference is, as stated earlier, the sockaddr. Here is how you set up the named pipe: /************************************************************/ /*** Unix named socket example ***/ /************************************************************/ #include <sys/un.h> int sockfd; struct sockaddr_un addr; sockfd = socket(PF_LOCAL, SOCK_STREAM, 0); bzero(&addr, sizeof(addr)); addr.sun_family = AF_LOCAL; strcpy(addr.sun_path, "/tmp/mysocket"); /* Assign name */ if ( bind(sockfd, &addr, sizeof(addr)) != 0 ) perror("bind() failed"); Everything should look relatively familiar. The sun_path field allows a path of up to 104 bytes (including the NULL termination). From here, you can use all the regular API calls. This is the same for all supported protocols. After you run this fragment, you can look in /tmp to see the new file. Be sure to delete this file before running the program again. Summary: Applying IP Numbering and Tools The Socket API is a very flexible interfacing tool for network programming. It supports several different protocols, allowing you to connect to and interconnect with other networking protocols. The Internet Protocol uses addressing that builds in routing messages and clustering groups of computers. This makes each message autonomous from the originator: A message dropped on the network can get to the destination through routing and ARP tables. However, because of the addressing flexibility and sparse allocation, the addressing allocation is losing blocks of legal addresses. Part of the TCP/IP stack abstracts the network with ports. The majority of connections use ports to communicate with specific programs on other network computers as if they own the network connection. This feature eases programming and reduces the flood of messages that your program could actually receive. The network uses specific types and byte-orders (endianness) to hand messages back and forth. sockaddr defines the protocol, address, and port of the connection. Because of all these different data formats, the Socket API offers you many conversion tools for addressing (for example, inet_addr(), inet_aton(), inet_ntoa()) and endianness (htons(), ntohs(), htonl()). TCP and UDP offer different interfacing levels to your program. The next chapter defines the different types and capabilities of each protocol within the IP.
- 40. Chapter 3. Different Types of Internet Packets IN THIS CHAPTER • The Fundamental Network Packet • Dissecting the Various Packets • How the IP Protocols Fit Together • Snooping the Network with Tcpdump • Writing a Custom Network Snooper • Summary: Choosing the Best Packets for Sending Messages The physical network supports different types of logical networks like Novell (IPX), Microsoft (NetBEUI), AppleTalk, and of course, TCP/IP. Each logical network uses discrete data messages called packets, as defined in the last chapter. The packets can be actual messages on the transmission line (which has a lot more information included) or simply the message you're sending. The logical network packet at the generic level consists of information about the source, destination, and data payload. Each logical network offers varying degrees of features and interfaces (protocols). All packet types and protocols are available with network programming. Each type has significant strengths and weaknesses. Like shopping for tools, your choice of packet type depends on how you use it. You can choose from four basic Internet packet protocols: raw IP, ICMP, UDP (unreliable messaging), and TCP (streaming) all layered on top of the physical network (see Figure 3.1). This chapter describes each type and presents their advantages, disadvantages, and typical uses. Figure 3.1. The Sockets API provides different levels of reliable messages.
- 41. The Fundamental Network Packet If you could actually see the bits that travel from one computer to the other, what would you see? Each protocol is very different, but they all share one common necessary feature: They all carry the program's message. Some protocols include a source address, while some require a destination. You may think that not requiring a destination is a little unusual, but some protocols (like UUCP) use the connection as the address to the destination. The Internet Protocol (IP) [RFC791] requires a packet to have three basic elements: source, destination, and data. (The data payload includes its length.) These elements provide the packet a level of autonomy. No matter where a packet is, you can identify where it came from, where it's going, and how big it is. The packet's autonomy is an important feature of the Internet. As long as the packet is alive (the data is timely and relevant), routers can move data to its destination when the packet is launched onto the network. NOTE Packet autonomy also has a downside. While a packet provides a way of getting to anywhere from anywhere, a malicious programmer can easily trick the network. The network does not require that the source host's address be validated. Aliasing or spoofing (masking the true identity and assuming a different one) the hardware
- 42. address is difficult, but programs can alias other IDs. Please note that later Linux kernels do not allow spoofing. As discussed in Chapter 2, "TCP/IP Network Language Fluency," the network packet is in network byte (or big endian) order. With that in mind, take a look at a structure definition of how the network packet appears in Listing 3.1, and Figure 3.2 displays the physical layout. Figure 3.2. IP header layout. Example 3.1. IP Structure Definition /************************************************************/ /*** IP Packet definition ***/ /************************************************************/ #typedef unsigned int uint; #typedef unsigned char uchar; struct ip_packet { uint version:4; /* 4-bit version [note] */ uint header_len:4; /* header length in words [note] */ uint serve_type:8; /* how to service packet [note] */ uint packet_len:16; /* total size of packet in bytes */ uint ID:16; /* packet ID [note] */ uint __reserved:1; /* always zero */ uint dont_frag:1; /* flag to permit fragmentation */ uint more_frags:1; /* flag for "more frags to follow"*/ uint frag_offset:13; /* to help reassembly */ uint time_to_live:8; /* permitted router hop cnt [note] */ uint protocol:8; /* ICMP, UDP, TCP [note] */ uint hdr_chksum:16; /* ones-comp. checksum of header */ uint IPv4_source:32; /* IP address of originator */ uint IPv4_dest:32; /* IP address of destination */
- 43. uchar options[]; /* up to 40 bytes [note] */ uchar data[]; /* message data up to 64KB [note] */ } ; Notice that the packet structure includes many more fields than the basic four fields discussed earlier in this chapter. The IP subsystem uses these additional fields for controlling the packet. For example, the dont_frag field tells the network that, instead of cutting up the message into smaller chunks, it should either accept the message completely or drop it. Most of the fields are simple enough that the comments next to them provide sufficient description. The remaining fields require a longer description. The following sections define the IP fields that you can modify or use. This text is not exhaustive; if you want to learn more about each field, please refer to a good text on TCP/IP protocols. version Field The first IP field is the version number for the IP protocol version. Most of the values are either reserved or unassigned; for example, IPv4 places a 4 in this field. The few defined values are listed in Table 3.1. Table 3.1. version Field Values Value Description/Use 4 IPv4 5 Stream IP Datagram mode (experimental IP) 6 IPv6 7 TP/IX (the "next" Internet Protocol) 8 The "P" Internet Protocol 9 TUBA The only chance you have to fill this field is when you create a raw socket and you elect to fill the header yourself (using socket option IP_HDRINCL). Even then, you may set the field to 0. The zero flags the kernel to fill in the appropriate value for you. header_len Field This field tells the receiver the header length in 32-bit words. Since the value 0 is reserved (and meaningless), the greatest length is 15 words or 60 bytes. Again, the only circumstance in which you fill this field is with a raw socket packet and IP_HDRINCL. Since all IP headers are at least 20 bytes, the minimum value for this field is 5 (20/4) bytes. serve_type Field The serve_type field indicates how to manage the packet. It has two subfields: a precedence subfield (ignored on most systems) and a type of service (TOS) subfield. You normally set TOS with the setsockopt() system call. TOS has four options: Minimum Delay, Maximum Throughput, Maximum Reliability, and Minimum Cost
- 44. (monetary). No special service selected means normal management. (See Chapter 9, "Breaking Performance Barriers," for details on setsockopt() and its values.) ID Field The IP subsystem gives each packet a unique ID. With only a 16-bit field, you can imagine that the numbers get used up quickly. Nevertheless, by the time the IP subsystem reuses an ID, the previous packet of the same value will probably have expired. The ID helps reassemble fragmented packets. If you elect to manage the header (IP_HDRINCL), you must manage the IDs yourself. NOTE Keep in mind that your program is not the only one that may send messages if you choose to manipulate the header yourself. The IP subsystem keeps track of the IDs. You must use caution (and extra programming) to reduce the likelihood of selecting an ID that the subsystem recently used or may use. dont_frag, more_frags, frag_offset Flags and Field These flags manage how (or if) your packet fragments. If while traversing the network a lengthy packet has to go through a constricted network segment (one that cannot support the frame size), the router may try to break up the packet into smaller pieces (fragmentation). A fragmented packet remains fragmented until it arrives at the destination. Because each fragment adds its own IP header, the overhead diminishes performance. NOTE You can choose to reassemble fragmented packets with the Linux kernel when the host is a router. This option is part of the firewall/router section in the kernel configu ration. Please note that it takes time to reassemble packets, especially if they are scattered and arrive at different times. However, since the destination has to reassemble the packet anyway, selecting this option reduces traffic on the network inside the firewall. The dont_frag bit tells the router or host not to break up the packet. If you set this bit and the packet is too large for a constricted network segment, the router drops the packet and returns an error (ICMP) packet. The more_frags bit tells the destination to expect more pieces of the fragmented packet. The last fragment sets this bit to 0. (A nonfragmented packet sets this bit to 0.) If you are configuring the header manually, always set this bit to 0.
- 45. The frag_offset field indicates where in the packet the fragment belongs. Because packet fragments may travel through different routes in the network, they may arrive at different times. The destination has to reassemble the packet, and it uses the offset to place the fragment in its proper location. The frag_offset field is only 13 bits long—far too short for a packet that can be up to 64KB. The offset is multiplied by 8 to place the actual byte position in the packet. This means that each fragment (except the last) must be a multiple of 8. The IP subsystem completely manages the fragmentation and reassembly of your packet; you don't need to worry about it. With these fields and the packet ID, the IP subsystem can fragment and reassemble your packet. If the subsystem cannot get all the pieces within a specified time, it drops the packet and sends an error back to the originator. time_to_live (TTL) Field This field originally counted the number of seconds a packet could survive on the network during transit. Later, the meaning changed to the number of router hops. A hop is the transition through a host or router (node) where the node actively moves a packet from one network to another. This 8-bit field permits up to 255 router hops before being discarded. When a router or forwarding host gets the packet, it decrements this field by one. If the field equals zero before arriving at the destination, the node drops the packet and sends an error to the source. The TTL field keeps the network from bouncing a packet around indefinitely. Use the IP_TTL socket option to set this value (see Chapter 9). Alternatively, you can set it directly if you elect direct IP header manipulation (IP_HDRINCL). protocol Field Every packet on the Internet has an assigned protocol value, and ICMP (IPPROTO_ICMP or 1), UDP (IPPROTO_UDP or 17), and TCP (IPPROTO_TCP or 6) each own a code. The protocol tells the system how to treat the incoming packet. You can set this value with the SOCK_RAW option in the socket() system call. The protocol value is the last parameter of the call. The kernel's netinet/in.h header file lists many more. (Remember that even though the kernel includes a protocol definition, it might not support it.) options Field The IP subsystem can pass several options with each packet. These options include routing information, timestamps, security measures, routing record, and route alerts. This field can be up to 40 bytes long. Because some of the options are system dependent, you are unlikely to ever touch these options directly. data Field
- 46. Your message goes here and can include up to 65,535 bytes (minus 60 bytes, the maximum size of the header). The data section includes any header information that the higher protocols need. For example, ICMP requires 4 bytes, UDP requires 8 bytes, and TCP requires 20–60 bytes. The Internet packet system bases all its IPv4 packets on this structure. Each layer on top of this adds features and reliability. Dissecting the Various Packets The Internet Protocol offers several packet protocols that range from very fast to very reliable. All of them rest on the lowest layer—the basic IP packet. However, each layer has evolved to solve specific problems. To select the correct packet type, you must know about what you're transmitting. The packet types most likely to be of interest are TCP, UDP, ICMP, and raw. Knowing the advantages and disadvantages of each type can help you choose the most appropriate for your application. Each packet type has different benefits, as summarized in Table 3.2. Table 3.2. Packet Type Benefits Raw ICMP UDP TCP Overhead (bytes) 20–60 20–60+[4] 20–60+[8] 20–60 +[20–60] Message Size (bytes) 65,535 65,535 65,535 (unlimited) Reliability Low Low Low High Message Type Datagram Datagram Datagram Stream Throughput High High Medium Low Data Integrity Low Low Medium High Fragmentation Yes Yes Yes Low In this table, notice that each packet type contains comparisons. A reliability of Low value only means that you cannot rely on the protocol to help reliability. While the differences may seem extreme, remember that they are merely comparisons. Considering the Packet's Issues Each protocol addresses issues in the transmission. The following sections define each issue and associated category from Table 3.2. This information can help you see why certain protocols implement some features and skip others. Protocol Overhead Protocol overhead includes both the header size in bytes and the amount of interaction the protocol requires. High packet overhead can reduce throughput, because the network has to spend more time moving headers and less time reading data. Strong protocol synchronization and handshaking increase interaction overhead. This is more expensive on WANs because of the propagation delays. Table 3.2 does not include this measurement.
- 47. Protocol Message Size To calculate network throughput, you need to know the packet size and the protocol's overhead. The transmission size gives you the maximum size of a sent message. Since all but TCP use a single-shot message, this limitation is typically due to the limits of IP packet (65,535 bytes). The amount of data your program transmits per packet is the transmission size less the headers. Protocol Reliability Part of the problem with networks is the possibility of lost messages. A message could be corrupted or dropped as it moves from one host or router to another, or the host or router could crash or fail. In each case, a message may simply be lost, and your program may need to follow up. Also, you may need to make sure that the destination processes the packets in the correct order. For example, you may compose a message that does not fit in one packet. If the second packet arrives before the first, the receiver must know how to recognize and correct the problem. However, the order is not important when each message is independent and self- contained. The packet's reliability indicates the certainty of safe arrival of messages and their order. Low reliability means that the protocol can't guarantee that the packet gets to the destination or that the packets are in order. Protocol Message Type Some messages are self-contained and independent from other messages. Pictures, documents, email messages, and so on are a few examples that may fit the size of the packet. Others are more in the form of a flowing stream, such as Telnet sessions, HTTP's open channel [RFC2616], large documents, pictures, or files. The message type defines which style best fits each protocol. NOTE HTTP 1.0 could effectively use UDP for transferring messages instead of TCP. The client simply sends the request for a specific document, and the server replies with the file. Effectively, no conversation occurs between client and server. Protocol Throughput The most noticeable aspect of data transmission is network throughput. Getting the most out of your network is the best way to make your users happy. To get the best performance, you need to know the throughput. Often, the bits-per-second is a small part of the whole equation; it only indicates how the network could perform under ideal circumstances. The protocol throughput measures how much real data the originator can send to the destination within a period of time. If the headers are large and the data small, the
- 48. result is low throughput. Requiring acknowledgment for each message dramatically reduces throughput. By default, high reliability and integrity result in low throughput and vice versa. Protocol Data Integrity The networking technology currently has a lot of safeguards for data integrity. Some network interfaces include a checksum or cyclical redundancy check (CRC) for each low-level message. They also include special hardware technology that can filter out noise and get to the real message. Additionally, each protocol includes measures to detect errors in the data. These errors may or may not be important to you. The importance of data integrity depends on the data; that is, some data requires very careful oversight, while less important data is less critical. Here are some types of data: • Fault-Intolerant—Life-critical data. Anything that can affect public or private health/life. For example, life signs and vital signs from medical equipment and missile launch commands. • Critical—Important and reliable data. Data that if out of sequence or faulty can cause harm to property or security. For example, financial transactions, credit cards, PIN numbers, digital signatures, electronic money, trade secrets, virus scanner updates, and product updates. • Important—Data that requires proper functionality. Any loss can cause malfunction. For example, X11 connections, FTP downloads, Web pages, server/router addresses, and Telnet connections. • Informational—Data that can be less than 100% reliable for proper functionality. For example, email, news feeds, advertisements, and Web pages. • Temporal—Data that is date/time bound. Unless the program uses the information within a specific time, its importance lessens. For example, weather data, surveillance data, and time. • Lossy—Data that can degrade without loss of usefulness. These are typically audio or visual. For example, movies, audio files, photos, and spam (of course). Prior to choosing the packet type or protocol, try to categorize data according to this list. Also include the additional (or external) constraints of the program. These may be regulatory constraints as well. Protocol Fragmentation Large messages on slow networks can frustrate other users. All networks place a maximum frame size so those large messages don't dominate the network. Keep in mind that the routing host may still carve up, or fragment, large messages that go through a constricted network. Each protocol has a different likelihood of fragmentation. Since reassembling fragmented messages is part of IP, the reassembly may be transparent to the higher protocols. Certain circumstances, however, may require the packet's wholeness. This is particularly important for network performance. When routers carve up the packet into smaller chunks, the router has to take the time to chop up the message, and the
- 49. resulting packet overhead increases. By blocking fragmentation, the network drops the packet and returns a message-too-big error to your program. Packet Types The following sections describe each packet, showing its statistics and header definition (if there is one). Each section uses a quick-reference style to help you quickly see the features of each protocol. Use this style to help you choose the right packet for your applications. The Raw Packet A raw packet has direct access to an IP packet and header. It is useful in writing special or custom protocols. Its attributes are listed in Table 3.3. Table 3.3. Raw Packet Attributes Message Size (bytes) 65,535 (65,515 max data payload) Overhead (bytes) 20–60 Reliability Low (network may drop or rearrange packets) Message Type Datagram Throughput High (low system overhead) Data Integrity Low (system does not validate message) Fragmentation Yes Linux provides the option to work with different layers in the Internet Protocol stack (refer to Chapter 5, "Understanding the Network Layering Model," for a complete definition of the layers and IP stack). The most basic TCP/IP message is the raw IP message. It has no information other than the most basic. You can use the IP packet itself to create the most basic layer to create your own custom protocols. Access the IP packet by selecting SOCK_RAW in the socket() system. For security, you must have root privileges to run a raw socket program. The raw socket lets you play with the guts of the IP packet. You can configure the socket to work on two levels of detail: data only or data and header manipulation. Data manipulation is like UPD data transfers but does not support ports. In contrast, header manipulation lets you set the header fields directly. Using this message has both advantages and disadvantages. As a datagram message, it offers no guarantees of arrival or data integrity. However, you can send and receive messages nearly at network speed. For more information on raw packet manipulation, see Chapter 18, "The Power of Raw Sockets." IP Control and Error Messaging (ICMP) The Internet Control Message Protocol (ICMP) is one of the layers built on top of the basic IP packet. All Internet-connected computers (hosts, clients, servers, and routers) use ICMP for control or error messages. It is used for sending error or control messages. Some user programs also employ this protocol, such as traceroute and ping. ICMP's attributes are listed in Table 3.4.
- 50. Table 3.4. ICMP's Attributes Message Size (bytes) 65,535 (65,511 max data payload) Overhead (bytes) 24–64 Reliability Low (same as raw IP) Message Type Datagram Throughput High (same as raw IP) Data Integrity Low (same as raw IP) Fragmentation Yes (but unlikely) You can reuse your socket to send messages to different hosts without reopening the socket if you employ the ICMP in your own program. Send messages using the sendmsg() or sendto() system call (described in the next chapter). These calls require an address of the destination. With a single socket, you can send messages to as many peers as you want. The advantages and disadvantages of an ICMP packet are essentially the same as raw IP (and other datagrams). However, the packet includes a checksum for data validation. Also, the likelihood that the network may fragment an ICMP packet is very small. The reason is because of the nature of ICMP messages: They are for statuses, errors, or control. The message is not going to be very large, so it may never require reassembly. While you can use the ICMP for your own messages, it is usually for error messages and control. All networking errors travel the network through an ICMP packet. The packet has a header that holds the error codes, and the data part may contain a more specific message describing the error. Part of the IP protocol, ICMP gets an IP header and adds its own header. Listing 3.2 shows a definition of the structure. Example 3.2. ICMP Structure Definition /************************************************************/ /*** ICMP structure definition ***/ /*** Formal definition in netinet/ip_icmp.h ***/ /************************************************************/ typedef unsigned char ui8; typedef unsigned short int ui16; struct ICMP_header { ui8 type; /* Error type */ ui8 code; /* Error code */ ui16 checksum; /* Message checksum */ uchar msg[]; /* Additional data description */ } ; Figure 3.3. ICMP layout.
- 51. Type and code define what error occurred. msg can be any additional information to help detail what went wrong. For a complete list of types and codes, see Appendix A. User Datagram Protocol (UDP) The User Datagram Protocol (UDP) is used mostly for connectionless (independent messages) communications. It can send messages to different destinations without re- creating new sockets and is currently the most common connectionless protocol. UDP's attributes are listed in Table 3.5. Table 3.5. UDP Attributes Message Size (bytes) 65,535 (65,507 max data payload) Overhead (bytes) 28–68 Reliability Low Message Type One-shot Throughput Medium Data Integrity Medium Fragmentation Yes Each layer up the IP stack provides more focus on data and less on the network. UDP hides some of the details about error messages and how the kernel transmits messages. Also, it reassembles a fragmented message. A message you send via UDP is like an email message: The destination, origin, and data are all the information it needs. The kernel takes the message and drops it on the network but does not verify its arrival. As with the ICMP packet, you can send to multiple destinations from a single socket, using different send system calls. However, without the verification, you can experience near-maximum throughput. Without arrival verification, the network can lose data reliability. The network can lose packets or fragments and corrupt the message. Programs that use UDP either track the message themselves or don't care if something gets lost or corrupted. (Please note that, while datagrams are unreliable, it does not mean that something will go wrong. It just means that the protocol makes no guarantees.) Of the different data types (previously defined), Informational, Temporal, and Lossy best fit the UDP services. The primary reason is their tolerance for loss. If your Web camera fails to update every client, the end user is unlikely to either notice or care. Another possible use is a correct time service. Because correct time is Temporal, a host may drop a couple of clock ticks without losing integrity.
- 52. UDP offers the advantage of high speed. Moreover, you can increase its reliability yourself in the following ways: • Break up large packets. Take each message and divide it into portions and assign a number (such as 2 of 5). The peer on the other end reassembles the message. Bear in mind that more overhead and less sent data decrease throughput. • Track each packet. Assign a unique number to each packet. Force the peer to acknowledge each packet because, without an acknowledgment, your program resends the last message. If the peer does not get an expected packet, it requests a resend with the last message number or sends a restart message. • Add a checksum or CRC. Verify the data of each packet with a data summation. A CRC is more reliable than a checksum, but the checksum is easier to calculate. If the peer discovers that data is corrupted, it asks your program to resend the message. • Use timeouts. You can assume that an expired timeout means failure. Your originator could retransmit the message, and your receiver could send a reminder to the sender. The Critical and Important data types require the reliability found in TCP or better. Fault-Intolerant requires much more than any of these protocols offer. These outlined steps mimic the reliability of TCP. UDP relies on IP's features and services. Each UDP datagram packet receives an IP and a UDP header. Listing 3.3 defines how the UDP structure appears. Example 3.3. UDP Structure Definition /************************************************************/ /*** UDP (datagram) structure definition ***/ /*** (Formal definition in netinet/udp.h) ***/ /************************************************************/ typedef unsigned char ui8; typedef unsigned short int ui16; struct UDP_header { ui16 src_port; /* Originator's port number */ ui16 dst_port; /* Destination's port number */ ui16 length; /* Message length */ ui16 checksum; /* Message checksum */ uchar data[]; /* Data message */ } ; Figure 3.4. UDP layout.
- 53. UDP creates a virtual network receptacle for each message in the form of ports. With the port, IP can rapidly shuffle the messages to the correct owner. Even if you don't define a port with bind(), the IP subsystem creates a temporary one for you from the ephemeral port list (see Chapter 2). Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) is the most common socket protocol used on the Internet. It can use read() and write() and requires re-creating a socket for each connection. TCP's attributes are listed in Table 3.6. Table 3.6. TCP Attributes Message Size (bytes) (unlimited) Overhead (bytes) 40–120 Reliability High (data receipt checked) Message Type Stream Throughput Low (compared to other protocols) Data Integrity High (includes checksums) Fragmentation Unlikely Taking reliability one step further requires ensuring that the destination gets the exact message the originator sent. UDP has the speed but does not have the reliability that many programs require. TCP solves the reliability problem. The network, however, has several fundamental problems that make it unreliable. These problems are not limitations. Instead, they are inherent in the design of the network. To get reliable, streamable messages through the tangled Web, TCP/IP has to incorporate many of the ideas to improve reliability suggested in the section on UDP. The Internet has three hurdles: dynamic connections, data loss, and constricted paths, as discussed in the following sections. Dynamic Connections One host sends a message to another host. That message travels the networks, going through various routers and gateways. Each message sent may use a different path. Networking segments (connections between computers) often appear and disappear as servers come up and go down. The power of the Internet is its capability to adapt to these changes and route the information accordingly.
- 54. Adaptability is one of the driving forces behind the Internet. Your computer can make a request, and the network tries possible avenues to fill the order. Unfortunately, this advantage means that the path between your computer and the server or peer can change, lengthening and shortening the distance. As the path lengthens, propagation times increase. This means that your program could send successive messages and many would arrive at different times, often out of order. TCP ensures that the destination has correctly received the last message before it sends the next message. Compare this to a series of numbered messages (this is really how TCP works). Your program may send 10 messages in succession. TCP takes each message, attaches a unique number, and sends it off. The destination accepts the message and replies with an acknowledgment. Upon receiving the acknowledgment, TCP lets your program send the next message. NOTE TCP uses a better technique than the send/wait (or ACK/NACK) protocol, which is too slow for anyone's patience. Instead, it uses a sliding window: It gauges when and how often to reply with an ACK. Slower or dirtier connections may increase the acknowledge messages. Connections that are faster and lose less allow more messages to ship before expecting acknowledgments. This is part of the Nagle Algorithm. You can disable this using socket options (see Chapter 9). Data Loss When the destination gets your message, it determines the integrity of the data. The data may travel along less-than-optimal communication paths that may drop or corrupt message bits. Remember that the network sends every message one bit at a time. TCP sends with the message a checksum to verify the data. TCP is the last layer that can detect and remedy corrupted data. If the destination detects any errors, it sends back an error, requesting a retransmittal from your program. Likewise, if your computer does not get an acknowledgment within a specific amount of time, the TCP subsystem automatically resends the message without your program's intervention. Constricted Paths Going back to the single message sent to a particular host, suppose that the message is too long for the intervening segments. The problem that the packet encounters as it passes through the network is the different technologies and transmission carriers. Some networked computers permit lengthy packets; others place limits on the size. UDP tries to send the largest message that it can. This can be a problem with the constricted data paths. The IP algorithms anticipate that the routers may fragment data. Likewise, IP expects that it has to reassemble the incoming message.
- 55. Random documents with unrelated content Scribd suggests to you:
- 56. But Æneas, fearing the words of Jupiter, stood with eyes that relented not. At the last he spake: “I deny not, O Queen, the benefits that thou hast done unto me, nor ever, while I live, shall I forget Dido. I sought not to fly by stealth; yet did I never promise that I would abide in this place. Could I have chosen according to my will, I had built again the city of Troy where it stood; but the gods command that I should seek Italy. Thou hast thy Carthage: why dost thou grudge Italy to us? Nor may I tarry. Night after night have I seen my father Anchises warning me in dreams. Also even now the messenger of Jupiter came to me—with these ears I heard him—and bade me depart.” Then, in great wrath, with eyes askance, did Dido break forth upon him: “Surely no goddess was thy mother, nor art thou come of the race of Dardanus. The rocks of Caucasus brought thee forth, and an Hyrcanian tigress gave thee suck. For why should I dissemble? Was he moved at all my tears? Did he pity my love? Nay, the very gods are against me. This man I took to myself when he was shipwrecked and ready to perish. I brought back his ships, his companions from destruction. And now forsooth comes the messenger of Jupiter with dreadful commands from the gods. As for thee, I keep thee not. Go, seek thy Italy across the seas: only, if there is any vengeance in heaven, thou wilt pay the penalty for this wrong, being wrecked on some rock in their midst. Then wilt thou call on Dido in vain. Aye, and wherever thou shalt go I will haunt thee, and rejoice in the dwellings below to hear thy doom.” Then she turned, and hasted to go into the house. But her spirit left her, so that her maidens bear her to her chamber and laid her on her bed. Then Æneas, though he was much troubled in his heart, and would fain have comforted the Queen, was obedient to the heavenly word, and departed to his ships. And the men of Troy busied themselves in making them ready for the voyage. Even as the ants spoil a great heap of corn and store it in their dwellings against winter, moving in a black line across the field, and some carry the
- 57. great grains, and some chide those that linger, even so did the Trojans swarm along the ways and labor at the work. But when Dido saw it, she called to Anna, her sister, and said, “Seest thou how they hasten the work along the shore? Even now the sails are ready for the winds, and the sailors have wreathed the ships with garlands, as if for departure. Go thou—the deceiver always trusted thee, and thou knowest how best to move him—go and entreat him. I harmed not him nor his people; let him then grant me this only. Let him wait for a fairer time for his journey. I ask not that he give up his purpose; only that he grant me a short breathing space, till I may learn how to bear this sorrow.” And Anna hearkened to her sister, and took the message to Æneas, yet profited nothing, for the gods shut his ears that he should not hear. Even as an oak stands firm when the north wind would root it up from the earth—its leaves are scattered all around, yet doth it remain firm, for its roots go down to the regions below, even as far as its branches reach to heaven—so stood Æneas firm, and, though he wept many tears, changed not his purpose. Then did Dido grow weary of her life. For when she did sacrifice, the pure water would grow black and the wine be changed into blood. Also from the shrine of her husband, which was in the midst of her palace, was heard a voice calling her, and the owl cried aloud from the house-top. And in her dreams the cruel Æneas seemed to drive her before him; or she seemed to be going a long way with none to bear her company, and be seeking her own people in a land that was desert. Therefore, hiding the thing that was in her heart, she spake to her sister, saying, “I have found a way, my sister, that shall bring him back to me or set me free from him. Near the shore of the Great Sea, where the Æthiopians dwell, is a priestess, who guards the temple of the daughters of Hesperus, being wont to feed the dragons that kept the apples of gold. She is able by her charms to loose the heart from care or to bind it, and to stay rivers also, and to turn the courses of the stars, and to call up the spirits of the dead. Do thou, therefore—for this is what the priestess commands—
- 58. build a pile in the open court, and put thereon the sword which he left hanging in our chamber, and the garments he wore, and the couch on which he lay, even all that was his, so that they may perish together.” And when these things were done—for Anna knew not of her purpose—and also an image of Æneas was laid upon the pile, the priestess, with her hair unbound, called upon all the gods that dwell below, sprinkling thereon water that was drawn, she said, from the lake of Avernus, and scattering evil herbs that had been cut at the full moon with a sickle of bronze. Dido also, with one foot bare and her garments loosened, threw meal upon the fire, and called upon the gods, if haply there be any, that look upon those that love and suffer wrong. In the meantime Æneas lay asleep in the hind part of his ship, when there appeared to him in a dream the god Mercury, even as he had seen him when he brought the commandment of Jupiter. And Mercury spake, saying, “Son of Venus, canst thou sleep? seest thou not what perils surround thee, nor hearest how the favorable west wind calls? The Queen purposes evil against thee. If thou lingerest till the morning come thou wilt see the shore covered with them that wish thee harm. Fly, then, and tarry not; for a woman is ever of many minds.” Then did Æneas in great fear start from his sleep, and call his companions, saying, “Wake, and sit on the benches, and loose the sails. ’Tis a god thus bids us fly.” And even as he spake he cut the cable with his sword. And all hasted to follow him, and sped over the sea. And now it was morning, and Queen Dido, from her watch- tower, saw the ships upon the sea. Then she smote upon her breast and tore her hair, and cried, “Shall this stranger mock us thus? Hasten to follow him. Bring down the ships from the docks, make ready sword and fire. And this was the man who bare upon his shoulders his aged father! Why did I not tear him to pieces, and slay his companions with the sword, and serve up the young Ascanius at
- 59. his meal? And if I had perished, what then? for I die to-day. O Sun, that regardest all the earth, and Juno, that carest for marriage bonds, and Hecate, Queen of the dead, and ye Furies that take vengeance on evil-doers, hear me. If it be ordered that he reach this land, yet grant that he suffer many things from his enemies, and be driven from his city, and beg for help from strangers, and see his people cruelly slain with the sword; and, when he shall have made peace on ill conditions, that he enjoy not long his kingdom, but die before his day, and lie unburied on the plain. And ye, men of Tyre, hate his children and his people for ever. Let there be no love or peace between you. And may some avenger arise from my grave who shall persecute the race of Dardanus with fire and sword. So shall there be war for ever between him and me.” Then she spake to old Barcé, who had been nurse to her husband Sichæus. “Bid my sister bathe herself in water, and bring with her beasts for sacrifice. And do thou also put a garland about thy head, for I am minded to finish this sacrifice which I have begun, and to burn the image of the man of Troy.” And when the old woman made haste to do her bidding, Queen Dido ran to the court where the pile was made for the burning, and mounted on the pile, and drew the sword of Æneas from the scabbard. Then did she throw herself upon the bed, and cry, “Now do I yield up my life. I have finished my course. I have built a mighty city. I have avenged my husband on him that slew him. Happy had I been, yea too happy! had the ships of Troy never come to this land.” Then she kissed the bed and cried, “Shall I die unavenged? Nevertheless let me die. The man of Troy shall see this fire from the sea whereon he journeys, and carry with him an augury of death.” And when her maidens looked, lo! she had fallen upon the sword, and the blood was upon her hands. And a great cry went up through the palace, exceeding loud and bitter, even as if the enemy had taken Carthage or ancient Tyre, and the fire were mounting over the dwellings of men and of gods. And Anna her sister heard it, and rushing through the midst called her by her name, “O my sister, was
- 60. this thy purpose? Were the pile and the sword and the fire for this? Why wouldst thou not suffer that I should die with thee? For surely, my sister, thou hast slain thyself, and me, and thy people, and thy city. But give me water, ye maidens, that I may wash her wounds, and if there be any breath left in her, we may yet stay it.” Then she climbed on to the pile, and caught her sister in her arms, and sought to staunch the blood with her garments. Three times did Dido strive to raise her eyes; three times did her spirit leave her. Three times she would have raised herself upon her elbow; three times she fell back upon the bed, looking with wandering eyes for the light, and groaning that she yet beheld it. Then Juno, looking down from heaven, saw that her pain was long, and pitied her, and sent down Iris, her messenger, that she might loose the soul that struggled to be free. For, seeing that she died not by nature, nor yet by the hand of man, but before her time and of her own madness, Queen Proserpine had not shred the ringlet from her head which she shreds from them that die. Wherefore Iris, flying down with dewy wings from heaven, with a thousand colors about her from the light of the sun, stood above her head and said, “I will give thee to death, even as I am bidden, and loose thee from thy body.” Then she shred the lock, and Queen Dido gave up the ghost.
- 61. CHAPTER III. From Carthage Æneas journeyed to Sicily, for the wind hindered him from coming to Italy as he would fain have done. And in Sicily he held great games in honor of his father Anchises. And when these were finished he departed to Italy, leaving behind him all that were weak and faint-hearted. The place whereunto he came was nigh unto Cumæ, which was the dwelling-place of the Sibyl. And the men turned the forepart of the ships to the sea, and made them fast with anchors. Then they leapt forth upon the shore, and kindled a fire; and some cut wood in the forest, or fetched water from the stream. But Æneas went up to the great cave of the Sibyl, where, by the inspiration of Apollo, she foretelleth things to come. Now the temple was a marvellous place to look upon. For Dædalus, when he fled from Minos, King of Crete, flying through the air upon wings, came northwards to the land of Cumæ, and tarried there. Also he dedicated his wings in the temple. On the doors thereof was set forth, graven in stone, the death of Androgeos, and the men of Attica choosing by lot seven of their children who should be given as a ransom yearly; and, rising from the sea upon the other side, the land of Crete. Likewise the Labyrinth was there and its winding ways; but Icarus they saw not, for when his father would have wrought the manner of his death in gold his hands failed him: twice he strove and twice they failed. And when Æneas would have looked further, the priestess said, “Linger not with these things, but slay forthwith seven bullocks from the herd, and seven sheep duly chosen out of the flock.” And when they came to the cave—now
- 62. there are a hundred doors, and a voice cometh forth from each—the Sibyl cried, “It is time. Lo! the god, the god!” And even as she spake her look was changed and the color of her face; also her hair was loosened, and her breast panted, and she waxed greater than is the stature of a man. Then she cried, “Delayest thou to pray, Æneas of Troy? delayest thou? for the doors open not but to prayer.” Nor said she more. Then Æneas prayed, saying, “O Phœbus, who didst always pity the sorrows of Troy, and didst guide the arrow of Paris that it slew the great Achilles, I have followed thy bidding, journeying over many lands, and now I lay hold on this shore of Italy, which ever seemed to fly before me. Grant thou that our ill fortune follow us no more. And all ye gods and goddesses who loved not Troy, be merciful to us. And thou, O Prophetess, give, if it may be, such answer as I would hear. So will I and my people honor thee for ever. And write it not, I pray thee, upon leaves, lest the winds carry them away, but speak with thy voice.” And for awhile the prophetess strove against the spirit; but at the last it mastered her, and the doors flew open, and she spake, saying, “The perils of the sea thou hast escaped, but there await thee yet worse perils upon the land. The men of Troy shall come to the kingdom of Lavinium. Fear not for that; yet will they fain not have come. I see battles, and the Tiber foaming with blood, and a new Xanthus and Simoïs, and another Achilles, himself also goddess- born. Juno also shall be ever against thee. And thou shalt be a suppliant to many cities. And the cause of all these woes shall be again a woman. Only yield not thou, but go ever more boldly when occasion shall serve. Little thinkest thou that thy first succor shall be from a city of the Greeks.” And when she had ended these words, Æneas made answer: “O Lady, no toil or peril shall take me unawares; for I have thought over all things in my heart. But one thing I ask of thee. Here is the door of the dwellings of the dead. Fain would I pass thereby, that I may visit my father. I carried him on my shoulders out of the fires of Troy, and with me he endured many things by land and sea, more than befitted his old age. Likewise he bade me ask this boon of thee. Do
- 63. thou therefore pity both father and son, for thou hast the power, if only thou wilt. Did not Orpheus bring back his wife from the dead, having his harp only? Also Pollux goeth many times this same path, redeeming his brother from death. And why should I tell of Theseus and Hercules? And I also am of the lineage of Jupiter.” Then the Sibyl spake, saying, “Son of Anchises, it is easy to go down to hell. The door is open day and night. But to return, and struggle to the upper air, that is the labor. Few only have done it, and these of the lineage of the gods and dear to Jupiter. Yet if thou wilt attempt it, hearken unto me. There lieth hid in the forest a bough of gold which is sacred to the Queen of hell. Nor may any man go on this journey till he have plucked it, for the Queen will have it as a gift for herself. And when the bough is plucked, there ever groweth another; and if it be the pleasure of the gods that thou go, it will yield to thy hand. But know that one of thy companions lieth dead upon the shore. First must thou bury him, and after offer due sacrifice, even black sheep. So shalt thou approach the dwellings of the dead.” Then Æneas departed from the cave, and Achates went with him, and much they wondered who it might be that was dead. And when they came to the shore, lo! Misenus lay there, than whom no man was more skilful to call men to battle with the voice of the trumpet. Hector’s companion he had been in old time, and then followed Æneas. And now, blowing his trumpet on the shore, he had challenged the gods of the sea to compare with him; wherefore a Triton caught him and plunged him into the sea, so that he died. Then did Æneas and his companions prepare for the burial, cutting ilex and oak and mountain-ash from the wood. But when Æneas beheld the forest, how vast it was, he said, “Now may the gods grant that in this great forest the bough of gold discover itself.” And as he spake, lo! two doves flew before his face, and settled on the grass, and he knew them to be the birds of his mother, and cried, saying, “Guide me now to the bough of gold, and thou, my mother, help me as before.” Then the birds flew so that he could still see them with his eyes, and he followed after them. But when they
- 64. came to the mouth of Avernus, they sat both of them on a tree. And lo! the bough of gold glittered among the branches and rustled in the wind. Right gladly did Æneas break it off, and carry it to the dwelling of the Sibyl. In the meantime the men of Troy made a great burial for Misenus on the shore, building a pile of wood, and washing and anointing the body. Also they laid the body on a bier, and on it the garments which he had worn being yet alive. Then others, with faces turned away, held a torch to the wood, whereon also were burned incense and offerings of oil. And when the burning was ended they quenched the ashes with wine. And Corynæus gathered the bones into an urn of bronze, and purified the people, sprinkling them with water with a bough of an olive-tree. Then Æneas made a great mound, and put thereon the trumpet of the man and his bow; and the mountain is called Misenus, after him, to this day. But when the burial was ended he did as the Sibyl had commanded. A great cavern there is, from which cometh so evil a stench that no bird may fly across. There they brought four black oxen, and the priestess poured wine upon their heads and cut hairs from between the horns. And when they had burned these they slew the oxen, holding dishes for the blood. And Æneas offered a black lamb to the Furies and a barren heifer to the Queen of hell, smiting them with his sword. Then they burned the entrails with fire, pouring oil upon them. Then did the ground give a hollow sound beneath them, and the dogs howled, for the goddess was at hand. And the priestess cried, “Go ye who may not take part in this matter. And thou, Æneas, draw thy sword from its sheath and follow. Now hast thou need of all thy strength and courage.” Then she plunged into the cave, and Æneas went with her. So they went together through the land of shadows, like unto men who walk through a wood in a doubtful light, when the moon indeed hath risen, but there are clouds over the sky. And first they came to where, in front of the gates of hell, dwell Sorrow and Remorse, and pale Disease and Fear, and Hunger that tempteth men
- 65. to sin, and Want, and Death, and Toil, and Slumber, that is Death’s kinsman, and deadly War; also they saw the chamber of the Furies, and Discord, whose hair is of snakes that drip with blood. And in this region there is an ancient elm, in the boughs whereof dwell all manner of dreams, and shapes of evil monsters, as many as have been, such as were the Centaurs, half man half horse, and Briareus with the hundred hands, and others also. These Æneas, when he saw them, sought to slay, rushing upon them with the sword, but his guide warned him that they were shadows only. After this they came to the river of hell, whereon plies the Boatman Charon. A long white beard hath he and unkempt; and his eyes are fixed in a fiery stare, and a scarf is knotted upon his shoulder, as is a pilot’s wont. An old man he seemeth to be, but hale and ruddy. Now there was ever rushing to the bank a great crowd, wives and mothers, and valiant men of war, boys, and girls dead before they were given in marriage, and young men laid on the funeral pile before their parents’ eyes. Thick they were as the leaves that fall to the earth at the first frost of autumn, or as the swallows, when they gather themselves together, making ready to fly across the sea to the lands of the sun. And of these Charon would take some into his boat; but others he would forbid, and drive from the shore. This when Æneas saw, he marvelled, and said, “O Lady, what meaneth this concourse at the river? What seek these souls? Why be some driven from the bank and some ferried across?” And the Sibyl made answer: “This river that thou seest is the Styx, by which the gods in heaven swear, and fear to break their oath. Those whom thou seest to be driven from the bank are such as have lacked burial, but those who are ferried across have been buried duly; for none pass this stream till their bodies have been laid in the grave, otherwise they wander for a hundred years, and so at last may cross over.” Much did Æneas pity their ill fortune, and the more when he beheld Orontes and his Lycians, whom the sea had swallowed up alive before his eyes. Here likewise there met him his pilot Palinurus,
- 66. to whom, when he knew him, for indeed he scarce could see him in the darkness, he said, “What god took thee from us and drowned thee in the sea? Surely, in this one matter, Apollo hath deceived me, saying that thou shouldst escape the sea and come to the land of Italy.” Then answered Palinurus, “Not so, great Æneas. For indeed to the land of Italy I came. Three nights the south wind carried me over the sea, and on the fourth day I saw the land of Italy from the top of a wave. And when I swam to the shore, and was now clinging to the rocks, my garments being heavy with water, the savage people came upon me, and took me for a prey, and slew me. And now the winds and waves bear me about as they will. Wherefore I pray thee, by thy father, and Iülus, the hope of thy house, that thou deliver me from these woes. Go, therefore, I beseech thee, to the haven of Velia, and cast earth upon me for burial; or give me now thy hand, and take me with thee across this river.” Then said the priestess, “O Palinurus, what madness is this? Wilt thou without due burial cross the river, and look upon the awful faces of the Furies? Think not that the Fates can be changed by prayers. Yet hear this, and be comforted. They that slew thee, being sore troubled by many plagues, shall make due expiation to thee, and build a tomb, and make offerings thereon year by year; and the place where they slew thee shall be called after thy name.” Then he took comfort and departed. But when they came near to the river, the Boatman beheld them, and cried, “Stay thou, whoever thou art, that comest armed to this river, and tell me what thou seekest. This is the land of Shadows, of Sleep, and of Night. The living may not be ferried in this boat. An evil day it was when I carried Hercules, and Theseus, and Pirithoüs, though they were children of the gods. For Hercules chained the Watch-dog of hell, and dragged him trembling from his master’s seat. And Theseus and his friend sought to carry away the Queen even from the chamber of her husband.”
- 67. Then the Sibyl made answer: “Be not troubled. We come not hither with evil thoughts. Let the Watch-dog of hell make the pale ghosts afraid; let your Queen abide in her husband’s palace; we will not harm them. Æneas of Troy cometh down to hell that he may speak with his father. And if thou takest no account of such piety, yet thou wilt know this token.” And she showed him the bough of gold. And when he saw it he laid aside his anger, rejoicing to behold, now after many years, the marvellous gift. Then he brought near his boat to the bank, and drave out the souls that were therein, and took on board Æneas and the priestess. Much did it groan with the weight, and the water poured apace through the seams thereof. Yet did they come safe across. Then they saw Cerberus, the Watch-dog, in his cave. And to him the Sibyl gave a cake of honey and poppy-seed, causing sleep. And this he swallowed, opening wide his three ravenous mouths, and straightway stretched himself out asleep across the cave. After this they heard a great wailing of infants, even the voices of such as are taken away before they have had lot or part in life. And near to these were such as have died by false accusation; yet lack they not justice, for Minos trieth their cause. And yet beyond, they that, being guiltless, have laid hands upon themselves. Fain would they now endure hardships, being yet alive, but may not, for the river keeps them in with his unlovely stream as in a prison. Not far from these are the Mourning Fields, where dwell the souls of those that have died of love, as Procris, whom Cephalus slew in error, and Laodamia, who died of grief for her husband. And among these was Dido, fresh from the wound wherewith she slew herself. And when Æneas saw her darkly through the shadows, even as one who sees, or thinketh that he sees, the new moon lately risen, he wept, and said, “O Dido, it was truth, then, that they told me, saying that thou hadst slain thyself with the sword. Tell me, Was I the cause of thy death? Loath was I, O Queen—I swear it by all that is most holy in heaven or hell—to leave thy land. But the gods, at
- 68. whose bidding I come hither this day, constrained me; nor did I think that thou wouldst take such sorrow from my departure. But stay; depart not; for never again may I speak to thee but this once only.” So he spake, and would fain have appeased her wrath. But she cast her eyes to the ground, and her heart was hard against him, even as a rock. And she departed into a grove that was hard by, wherein was her first husband, Sichæus, who loved her even as he was loved. After this they came to the land where the heroes dwell. And there they saw Tydeus, who died before Thebes; and Adrastus, and also many men of Troy, as the three sons of Antenor, and Idæus who was the armor-bearer of King Priam, and bare the arms and drave the chariot yet. All these gathered about him, and would fain know wherefore he had come. But when the hosts of Agamemnon saw his shining arms through the darkness, they fled, as in old days they had fled to the ships; and some would have cried aloud, but could not, so thin are the voices of the dead. Among these he saw Deïphobus, son of Priam. Cruelly mangled was he, for his hands had been cut off, and his ears and his nostrils likewise. Scarce did Æneas know him, and he himself in shame would have hidden his wounds; but the son of Anchises spake to him, saying, “Who hath dealt so foully with thee, great Deïphobus? Men told me that on the last night of Troy thou didst fall dead on a heap of Greeks whom thou hadst slain. Wherefore I built thee a tomb by the sea, and thrice called aloud thy name. But thee I found not, that I might lay thee therein.” Then Deïphobus made answer: “Thou hast left nothing undone, but hast paid me all due honor. But my ill fate and the accursed wickedness of the Spartan woman have destroyed me. How we spent that last night in idle rejoicings thou knowest. And she, while the women of Troy danced before the gods, stood holding a torch on the citadel, as though she were their leader, yet in truth she called therewith the Greeks from Tenedos. But I lay overcome with weariness in my chamber. Then did she, a noble wife, forsooth! take
- 69. all the arms out of the house, and my trusty sword also from under my head; and after brought thereunto Menelaüs, so hoping to do away her sin against him; and Ulysses also, always ready with evil counsels. What need of more? May the gods do so and more also to them. But tell me why hast thou come hither?” And it was now past noonday, and the two had spent in talk all the allotted time. Therefore the Sibyl spake: “Night cometh, Æneas, and we waste the day in tears. Lo! here are two roads. This on the right hand leadeth to the palace of Pluto and to the Elysian plains; and that on the left to Tartarus, the abode of the wicked.” And Deïphobus answered: “Be not wroth, great priestess; I depart to my own place. Do thou, my friend, go on and prosper.” But as Æneas looked round he saw a great building, and a three-fold wall about it, and round the wall a river of fire. Great gates there were, and a tower of brass, and the fury Tisiphone sat as warder. Also he heard the sound of those that smote upon an anvil, and the clanking of chains. And he stood, and said, “What mean these things that I see and hear?” Then the Sibyl made answer: “The foot of the righteous may not pass that threshold. But when the Queen of hell gave me this office she herself led me through the place and told me all. There sitteth Rhadamanthus the Cretan, and judgeth the dead. And them that be condemned Tisiphone taketh, and the gate which thou seest openeth to receive them. And within is a great pit, and the depth thereof is as the height of heaven. Herein lie the Titans, the sons of Earth, whom Jupiter smote with the thunder; and herein the sons of Aloeus, who strove to thrust the gods from heaven; and Salmoneus, who would have mocked the thunder of Jupiter, riding in his chariot through the cities of Elis, and shaking a torch, and giving himself out to be a god. But the lightning smote him in his pride. Also I saw Tityos, spread over nine acres of ground, and the vulture feeding on his heart. And over some hangs a great stone ready to fall; and some sit at the banquet, but when they would eat, the Fury at their side forbids, and rises and shakes her torch and thunders in their ears. These are they who while they were yet alive hated their brothers,
- 70. or struck father or mother, or deceived one that trusted to them, or kept their riches for themselves, nor cared for those of their own household (a great multitude are they), or stirred up civil strife. And of these some roll a great stone and cease not, and some are bound to wheels, and some sit forever crying, ‘Learn to do righteousness and to fear the gods.’” And when the priestess had finished these words they hastened on their way. And, after a while, she said, “Lo! here is the palace which the Cyclopés built for Pluto and the Queen of hell. Here must we offer the gift of the bough of gold.” And this being accomplished, they came to the dwellings of the righteous. Here are green spaces, with woods about them; and the light of their heaven is fuller and brighter than that which men behold. Another sun they have and other stars. Some of them contend together in wrestling and running; and some dance in measure, singing the while a pleasant song; and Orpheus, clad in a long robe, makes music, touching his harp, now with his fingers and now with an ivory bow. Here did Æneas marvel to see the mighty men of old, such as were Ilus, and Dardanus, builder of Troy. Their spears stood fixed in the earth, and their horses fed about the plain; for they love spear and chariot and horses, even as they loved them upon earth. And others sat and feasted, sitting on the grass in a sweet-smelling grove of bay, whence flows the river which men upon the earth call the Po. Here were they who had died for their country, and holy priests, and poets who had uttered nothing base, and such as had found out witty inventions, or had done great good to men. All these had snow-white garlands on their heads. Then spake the Sibyl to Musæus, who stood in the midst, surpassing them all in stature: “Tell me, happy souls, where shall we find Anchises.” And Musæus answered, “We have no certain dwelling-place: but climb this hill, and ye can see the whole plain below, and doubtless him whom ye seek.” Then they beheld Anchises where he sat in a green valley, regarding the spirits of those who should be born in after-time of his race. And when he beheld Æneas coming, he stretched out his
- 71. hands and cried, “Comest thou, my son? Hast thou won thy way hither to me? Even so I thought that it would be, and lo! my hope hath not failed me.” And Æneas made answer, “Yea, I have come a long way to see thee, even as thy spirit bade me. And now let me embrace thee with my arms.” But when he would have embraced him it was as if he clasped the air. Then Æneas looked and beheld a river, and a great company of souls thereby, thick as the bees on a calm summer day in a garden of lilies. And when he would know the meaning of the concourse, Anchises said, “These are souls which have yet to live again in a mortal body, and they are constrained to drink of the water of forgetfulness.” And Æneas said, “Nay, my father, can any desire to take again upon them the body of death?” Then Anchises made reply: “Listen, my son, and I will tell thee all. There is one soul in heaven and earth and the stars and the shining orb of the moon and the great sun himself; from which soul also cometh the life of man and of beast, and of the birds of the air, and of the fishes of the sea. And this soul is of a divine nature, but the mortal body maketh it slow and dull. Hence come fear and desire, and grief and joy, so that, being as it were shut in a prison, the spirit beholdeth not any more the light that is without. And when the mortal life is ended, yet are not men quit of all the evils of the body, seeing these must needs be put away in many marvellous ways. For some are hung up to the winds, and with some their wickedness is washed out by water, or burnt out with fire. But a ghostly pain we all endure. Then we that are found worthy are sent unto Elysium and the plains of the blest. And when, after many days, the soul is wholly pure, it is called to the river of forgetfulness, that it may drink thereof, and so return to the world that is above.” Then he led Æneas and the Sibyl to a hill whence they could see the whole company, and regard their faces as they came; and he said, “Come, and I will show thee them that shall come after thee.
- 72. That youth who leans upon a pointless spear is Silvius, thy youngest child, whom Lavinia shall bear to thee in thy old age. He shall reign in Alba, and shall be the father of kings. And many other kings are there who shall build cities great and famous. Lo! there is Romulus, whom Ilia shall bear to Mars. He shall build Rome, whose empire shall reach to the ends of the earth and its glory to the heaven. Seest thou him with the olive crown about his head and the white beard? That is he who shall first give laws to Rome. And next to him is Tullus, the warrior. And there are the Tarquins; and Brutus, who shall set the people free, aye, and shall slay his own sons when they would be false to their country. See also the Decii; and Torquatus, with the cruel axe; and Camillus winning back the standards of Rome. There standeth one who shall subdue Corinth; and there another who shall avenge the blood of Troy upon the race of Achilles. There, too, thou mayest see the Scipios, thunderbolts of war, whom the land of Africa shall fear; and there Regulus, busy in the furrows; and there the Fabii, chiefly him, greatest of the name, who shall save thy country by wise delay. Such, my son, shall be thy children’s children. Others with softer touch shall carve the face of man in marble or mould the bronze; some more skilfully shall plead, or map the skies, or tell the rising of the stars. ’Tis thine, man of Rome, to subdue the world. This is thy work, to set the rule of peace over the vanquished, to spare the humble, and to subdue the proud.” Then he spake again: “Regard him who is the first of all the company of conquerors. He is Marcellus; he shall save the state in the day of trouble, and put to flight Carthaginian and Gaul.” Then said Æneas, for he chanced to see by his side a youth clad in shining armor, and very fair to look upon, but sad, and with downcast eyes, “Tell me, father, who is this? How noble is he! What a company is about him! but there is a shadow of darkness round his head.” And Anchises made answer, “O my son, seek not to know the greatest sorrow that shall befall thy children after thee. This youth
- 73. the Fates shall only show for a brief space to man. Rome would seem too mighty to the gods should he but live! What mourning shall there be for him! What a funeral shalt thou see, O river of Tiber, as thou flowest by the new-made tomb! No youth of the race of Troy shall promise so much as he. Alas! for his righteousness, and truth, and valor unsurpassed! O luckless boy, if thou canst haply break thy evil doom thou shalt be a Marcellus. Give handfuls of lilies. I will scatter the bright flowers and pay the idle honors to my grandson’s shade.” Thus did Anchises show his son things to be, and kindled his soul with desire of glory. Also he showed him what wars he must wage, and how he should endure, or, if it might be, avoid the evils to come. There are two gates of Sleep, of horn the one, by which true dreams go forth; of ivory the other, by which the false. Then did Anchises send forth his son and the Sibyl by the ivory gate. And Æneas returned to the ships, and making sail came to the cape which was afterwards called Caieta.
- 74. CHAPTER IV. While they tarried at Cumæ, Caieta, who was the nurse of Æneas, died and was buried; and they called the cape after her name. And afterwards they set sail, and passed by the island wherein dwelt Circé, who is the daughter of the Sun. Pleasantly doth she sing, sitting at the loom, and burneth torches of sweet-smelling cedar to give her light by night. And round about her dwelling you may hear the growling of lions and wild boars and bears and wolves, which are men whom the goddess with her enchantments hath changed into the shapes of beasts. But Neptune would not that the men of Troy, being fearers of the gods, should suffer such things. Therefore did he send them favorable winds, so that they passed quickly by that land. Now when it was dawn, the wind being now lulled, they came to a great wood upon the shore, and in the midst of the wood the river Tiber, yellow with much abundance of sand, flowing into the sea. And on the shore and in the wood were many birds. Thither the men of Troy brought their ships safe to land. Of this country Latinus was king, who was the son of Faunus, who was the son of Picus, who was the son of Saturn. And King Latinus had not a son, but a daughter only, Lavinia by name, who was now of an age to be married. Many chiefs of Latium, and of all Italy, desired to have her to wife; of whom the first was Turnus, a very comely youth, and of a royal house. Now the Queen, the mother of the virgin, loved him, and would fain have married her daughter to him, but the gods hindered the marriage with ill omens and marvels. In the midst of the palace was a great bay-tree, which
- 75. the King who had builded the house had dedicated to Phœbus. On this there lighted a great swarm of bees, and hung like unto a cluster of grapes from a bough thereof. And the seers, beholding the thing, cried, “There cometh a stranger who shall be husband to Lavinia, and a strange people who shall bear rule in this place.” Also when Lavinia lighted the fire upon the altar, standing by her father, a flame leapt therefrom upon her hair, and burned the ornament that was upon her head and the crown of jewels and gold, and spread with smoke and fire over the whole palace. Whereupon the prophets spake, saying, “The virgin indeed shall be famous and great, but there cometh a dreadful war upon her people.” And King Latinus, fearing what these things might mean, inquired of the oracle of Faunus, his father, which is by the grove of Albunea. Now the custom is that the priest offereth sacrifice in the grove and lieth down to sleep on the skins of the sheep that he hath slain; and it cometh to pass that he seeth visions in the night and heareth the voice of the gods. So King Latinus, being himself a priest, made a great sacrifice, even of a hundred sheep, and lay down to sleep upon the skins thereof. And when he was laid down, straightway there came a voice from the grove, saying, “Seek not, my son, to marry thy daughter to a chief of this land. There shall come a son- in-law from beyond the sea, who shall exalt our name from the one end of heaven to the other.” Nor did the King hide these things, but noised them abroad, and the fame thereof was great in these days when Æneas and his company came to the land of Italy. Now it so chanced that Æneas and Iülus his son, and others of the princes, sat down to eat under a tree; and they had platters of dough whereupon to eat their meat. And when they had ended, and were not satisfied, they ate their platters also, not thinking what they did. Then said Iülus, making sport, “What! do we eat even our tables?” And Æneas was right glad to hear this thing, and embraced the boy, and said, “Now know I that we are come to the land which the gods have promised to me and to my people, that they would give us. For my father, Anchises, spake to me, saying, ‘My son, when thou shalt come to a land that thou knowest not, and hunger shall
- 76. constrain thee to eat thy tables, then know that thou hast found thee a home.’ Now, therefore, seeing that these things have an accomplishment, let us pour out libations to Jupiter, and make our prayers also to my father, Anchises, and make merry. And in the morning we will search out the country, and see who they be that dwell herein.” Then he bound a garland of leaves about his head, and made his prayers to Mother Earth, and to the gods of the land, of whom indeed he knew not who they were, and to Father Jupiter, and to the other gods also. And when he had ended his prayer, Jupiter thundered thrice from the sky. Then was it noised abroad among the men of Troy that now indeed were they come to the land where they should build them a city; and they eat and drank and made merry. The next day those who should search out the country went forth. And when it was told Æneas, saying that this river was the Tiber, and that the people who dwelt in the land were the Latins, valiant men of war, he chose out a hundred men who should go, with crowns of olive upon their heads, to the city of the King, having also gifts in their hands, and should pray that there might be peace between the men of Troy and his people. And the men made haste to depart; and in the meanwhile Æneas marked out for himself a camp, and bade that they should make a rampart and a ditch. Now when they that were sent came nigh to the city, they saw the young men in the plain that was before it, riding upon horses and driving chariots. Others shot with the bow or cast javelins, and some contended in running or boxing. And one rode on horseback and told the king, saying that certain men in strange raiment were come. Then the King commanded that they should be brought into the palace, and sat upon the throne of his fathers, and gave audience to them. Now the palace stood on the hill that was in the midst of the city, where King Picus had builded it, having woods about it very sacred. Here did the kings first receive the sceptre, that they should bear rule over the people. A senate-house also it was, and a
- 77. Welcome to our website – the perfect destination for book lovers and knowledge seekers. We believe that every book holds a new world, offering opportunities for learning, discovery, and personal growth. That’s why we are dedicated to bringing you a diverse collection of books, ranging from classic literature and specialized publications to self-development guides and children's books. More than just a book-buying platform, we strive to be a bridge connecting you with timeless cultural and intellectual values. With an elegant, user-friendly interface and a smart search system, you can quickly find the books that best suit your interests. Additionally, our special promotions and home delivery services help you save time and fully enjoy the joy of reading. Join us on a journey of knowledge exploration, passion nurturing, and personal growth every day! ebookbell.com