- Shopping Bag ( 0 items )
From the Publisher. . .is ideal for anyone new to computer network development and administration.
Programmer's Guide to Internet Mail will help you create and manage network applications using powerful Internet mail, directory, and domain name protocols and standards. It succinctly explains from a programmer's perspective not simply the primary Internet mail protocols but also how to use other important network protocols such as LDAP and DNS vital to the creation of message-enabled applications. Readers will learn how these protocols and standards facilitate message submission, delivery and retrieval, support...
Programmer's Guide to Internet Mail will help you create and manage network applications using powerful Internet mail, directory, and domain name protocols and standards. It succinctly explains from a programmer's perspective not simply the primary Internet mail protocols but also how to use other important network protocols such as LDAP and DNS vital to the creation of message-enabled applications. Readers will learn how these protocols and standards facilitate message submission, delivery and retrieval, support directory lookup, how they interoperate, and how they together create a framework for sophisticated networked applications.
Programmer's Guide to Internet Mail will help you select the right protocol, or combination of protocols, for a specific programming function. Written by an expert e-mail and messaging consultant from Compaq, this insightful book is loaded with sample code you can use to begin and accelerate application development.
Master the primary Internet mail and directory protocols
Understand the interaction between Internet messaging clients and servers
Troubleshoot e-mail network problems
Audience: Application developers of mail and mail-enabled software, administrators, and those considering mail-enabling their programs.
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:
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)
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.
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).
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.
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....
Internet Mail; Network Protocols; Generic Utilities; RFC822: Internet Text Messages; MIME: Multipurpose Internet Mail Extensions; SMTP: Simple Mail Transfer Protocol; DNS; POP3: Post Office Protocol; IMAP: Interactive Mail Access Protocol; ASN.1: Abstract Syntax Notation One; LDAP: Lightweight Directory Access Protocol; The Complete Picture; Appendix A: Library Functions; Appendix B: Sample Code