Table of Contents
| Preface | |
| Acknowledgments | |
| Ch. 1 | Internet Mail | 1 |
| Ch. 2 | Network Protocols | 21 |
| Ch. 3 | Generic Utilities | 35 |
| Ch. 4 | RFC 822 - Internet Text Messages | 53 |
| Ch. 5 | MIME - Multipurpose Internet Mail Extensions | 71 |
| Ch. 6 | SMTP - Simple Mail Transfer Protocol | 107 |
| Ch. 7 | DNS - Domain Name System | 123 |
| Ch. 8 | POP3 - Post Office Protocol | 153 |
| Ch. 9 | IMAP - Interactive Mail Access Protocol | 173 |
| Ch. 10 | ASN.1 - Abstract Syntax Notation One | 201 |
| Ch. 11 | LDAP - Lightweight Directory Access Protocol | 223 |
| Ch. 12 | The Complete Picture | 247 |
| App. A | Library Functions | 259 |
| App. B | Sample Code | 267 |
| Index | 285 |
Read an Excerpt
Chapter 2: Network Protocols
It is possible to write mail-enabled programs and manage E-mail networks with only a limited understanding of networks and their underlying protocols. Nevertheless, the more you know about the building blocks of your system the better you can understand why things work the way the do (or don't). This can only help you to do your job better.
I have tried to isolate some of the components of the Internet networking protocols that I think might be of value. Beyond these, you may wish to consult literature specifically targeted to networks.
Networking protocols address a number of challenges at the same time:
- 1. How do we allow multiple applications to share a link using a single physical medium (wire, air, optical cable, etc)? (Multiplexing)
2. How do applications synchronize operation with their counterparts on the remote machines? (Flow Control)
3. When there are multiple hosts and network lines, how do we deter mine the path for communication to our remote correspondent? (Addressing, Routing)
4. How do we recover from errors in transmission? (Checksums, Retransmission)
Given the complexity of each of these issues, we obviously need to structure our networks to ensure that we are able to satisfactorily address all such needs.
Networks have been historically organized into layers as a way of decomposing and modularizing their functionality. Today the most accepted model for networks is called the OSI model. Virtually all networking architectures describe their components in terms of how they fit this model.
IP Stack
If you look at Figure 2.1 you will see that the Internet protocols do notmatch the model exactly. Most network designers today would acknowledge that the model is top-heavy. In other words, there are too many layers at the top and not enough at the bottom. Consequently, we will find that the protocols we'll be looking at in this book are comparatively simple, yet span several OSI (Open Systems Interconnect) layers. At the same time, the data-link layer (which we can take for granted) has to provide multiple complex functions. I guess we are just lucky!
Internet Protocol
IP (Internet Protocol) is specified in RFC 791 and operates at the network layer. The primary purpose of this layer is to take packages of data and transfer them to their destination. If you look at Figure 2.21 you will notice the highlighted fields indicating the source and destination addresses. The network module of each node looks at the destination address of each packet and then decides where to send the packet next by looking up the shortest path in its routing tables.
Most of the other fields are not of interest to us. IP also does some basic error checking and fragmentation to pass through dissimilar networks, but essentially IP takes no responsibility for delivering its datagrams or for notifying the sender if anything goes wrong. It is fun being an IP module. If you don't like the data you receive you can just ignore it!
The only other field we are interested in is the protocol. Since there are multiple transport-level protocols on most nodes, the receiving IP must know to whom to give each packet when it receives it. In our case, this will usually be TCP (Transmission Control Protocol). The value of the protocol field is 6 if the protocol is TCP, although in the real world you might also encounter a substantial amount of UDP (User Datagram Protocol) (value of 17).
Transmission Control Protocol
Like IP, TCP also offers a few functions that need not overly concern us (Figure 2.3). It ensures that packets are given to the application in the order they were sent, as well as providing for flow control and more complete error-checking. Of interest to us is what RFC 793 calls multiplexing. just as IP was able to transfer incoming packets to various transport layers (TCP or UDP) depending on the protocol number, so TCP also has a number of upper-layer applications to deal with. To accommodate all of them at once, each application must request a port from the TCP module. Any requests coming into the port are held by TCP and can be read by the application. Similarly, any outgoing messages are sent by the application to the port, and TCP takes the responsibility to send them on to the destination application.
In Table 2.1 you can see the ports that we will be dealing with in our testing. Note that there is no technical restriction on which port each protocol can use. However, both client and server must agree on the same port. Since virtually all clients and servers in the industry use these ports, you will want to keep to the standard to interoperate with them.
TCP also defines a socket, which may some times be confused with a port (Table 2.2). It is essentially a specific port on a specific node or the combination of IP address and port number.
Another important term is the connection. A socket can have multiple connections from different nodes or even different ports on the same node. We call the association of two sockets with each other a connection.
Winsock
If you look at Figure 2.4, you will see the data structure you need to give your network interface in order to issue the SMTP command "HELO." Clearly, if you had to fill out these structures each time you wanted to send a command you would not be too pleased. This is the reason for compartmentalizing the network into modules. You can call the TCP module rather than having to replicate its functionality in your code.
Even so, every system and TCP implementation could conceivably have a different interface putting the burden back on you to develop versions of your program that work on every available protocol stack. The 4.2 version of BSD UNIX addressed this issue by defining a common programming interface for networking operations. It was loosely based on the UNIX approach to reading and writing files but addressed the needs of network users.
This API (Application Programming Interface) was called Berkeley Sockets and was eventually ported to many different operating systems. The name originated because its principal data structure was called a socket. Note that this socket is not simply a host-port combination as we discussed earlier. In this context, a socket is one end of a communications link. It holds all the information related to the link (including addresses, queues, and data buffers). Most socket-calls require a socket descriptor, also called a socket. The socket descriptor will be the usual meaning of the word socket in this book.
Early Windows applications did not have a socket library available to them. Each application had to program to the API of the TCP/IP stack of the vendor, much like users of other operating systems before Berkeley Sockets. In 1993, Microsoft and others produced a specification called Winsock, which was closely based on Berkeley Sockets. There are some additional functions (starting with WSA [Windows Socket API]), but the rest closely match the Berkeley specifications, making it easy to write portable code.
In Table 2.3 and Table 2.4 you can see the set of functions defined by Sockets and Winsock respectively. On 32-bit Windows systems (e.g., Windows 95, Windows 98, Windows NT) they are stored in a library called wsock32.dll, usually found in the Windows path....
loading...