Network Protocols

Network Protocols
The OSI layers define a model of protocol layers, their purpose, and how they work together. Let us compare the OSI layers with a concrete implementation: that of the TCP/IP protocol stack. The TCP/IP protocol stack is a simple form of the OSI model, which can be viewed by 4 layers as opposed to 7. The IP protocol corresponds to OSI layer 3; TCP and UDP are OSI layer 4 protocols. HTTP, FTP, and SMTP don't fit one layer of the OSI model, and the tasks they accomplish encompass the session, presentation, and application layers:

In the next section, we shall look into the functionality and purpose of the protocols of the TCP/IP suite in the following order:
Basic Protocols
Internet Protocols
E-mail Protocols
Other Protocols
Basic Protocols
As we can see, the TCP/IP protocol suite has a much simpler layered structure than the seven layers of the OSI model. The Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) protocols are transport protocols corresponding to OSI layer 4. Both protocols make use of the Internet Protocol (IP), an OSI layer 3 protocol (the network layer). As well as these three protocols, there are two more basic protocols in the TCP/IP suite that extend the IP protocol: ICMP and IGMP. The functionality of these protocols must be implemented in the layer housing the IP protocol, hence they are shown in that layer in the preceding figure.
IP-Internet Protocol
The Internet Protocol connects two nodes. Each node is identified by a 32-bit address, called its IP address. When sending a message, the IP protocol receives the message from upper level protocols such as TCP or UDP and adds the IP header which contains information about the destination host.
The best way to understand the IP protocol is by examining this IP header in detail. The information it contains is listed in the following table:
Field
Length
Description
IP Version
4 bits
The IP version that created the header. The current IP protocol version is 4.
IP Header Length
4 bits
The length of the header. The minimum value is 5, in units of 32 bits-4 bytes-so the minimum length is 20 bytes.
Type of Service
1 byte
The service type allows a message to be set as normal or high throughput, normal or high delay, and normal or high reliability. This is useful for datagram packets sent to the network. Several kinds of network use this information to prioritize certain traffic.
Also, Network Control messages have a higher precedence and reliability than normal messages.
Total Length
2 bytes
These two bytes specify the total length of the message- header and data-in octets. The maximum size of an IP packet is 65,535 bytes, but that is impractical for most networks. The largest size that must be accepted by all hosts is 576 bytes. Large messages can be split into fragments-a process called fragmentation.
Identification
2 bytes
If the message is fragmented, the identification field helps to assemble the fragments of a message. If a message is split into multiple fragments, all fragments of a message have the same identification number.
Flags
3 bits
These flags indicate if the message is fragmented or not, and if the current packet is the last fragment of a message.
Fragment Offset
13 bits
These 13 bits specify the offset of a fragmented message. Fragments may arrive in a different order than when sent, so the offset is necessary to rebuild the original data. The first fragment of a message has an offset of 0, and other fragments give the offset where the fragment should be appended. The offset unit is 8 bytes, so a fragment offset value of 64 means that the second fragment should be appended after 512 bytes of the first packet.
Time to Live
1 byte
The time to live (TTL) value specifies the number of seconds a message can live before it is discarded. This value doesn't necessarily specify the number of seconds, as every router that the message crosses must decrement the TTL value by 1 no matter if the handling of the message took less than 1 second. So in practice, this value gives the number of hops to live.
Protocol
1 byte
This byte indicates the protocol used at the next level in the protocol stack for this message. The protocol numbers are defined in an online database at the Internet Assigned Number Authority (IANA):
http://www.iana.org/assignments/protocol-numbers.
Some examples: ICMP has the value 1, IGMP 2, TCP 6, UDP 17.
Header Checksum
2 bytes
This is a checksum of the header only. Because the header changes with every message that is forwarded, the checksum changes also.
Source Address
4 bytes
This field gives the 32 bit IP address of the sender.
Destination Address
4 bytes
This is the 32-bit IP address where the message is to be sent.
Options
variable
Optional fields can appear here. We can specify that a message is confidential or top secret, and there is also room for future extensions.
Padding
variable
This field contains a variable number of zeros such that the header ends on a 32-bit boundary.
The Internet Protocol (IP) is defined with RFC 791. The RFC (Request for Comments) documents contain technical information about many important Internet technologies. RFCs can be found at http://www.ietf.org/rfc.html.
IP Addresses
Every node on a TCP/IP network can be identified by a 32-bit IP address. Usually the IP address is represented in a quad-notation with four decimal values, such as 192.168.0.1. Each of these numbers represents one byte of the IP address, meaning that each falls in the range 0 to 255.
An IP address consists of two parts: the network part and the host part. Depending on the network class, the network part consists of the first one, two, or three bytes:
Class
Byte 1
Byte 2
Byte 3
Byte 4
A
Network (1-126)
Host (0-255)
Host (0-255)
Host (0-255)
B
Network (128-191)
Network (0-255)
Host (0-255)
Host (0-255)
C
Network (192-223)
Network (0-255)
Network (0-255)
Host (0-255)
The first bit of a Class A network address must be 0, so the first byte of a Class A network is in the binary range 00000001 (1) to 01111110 (126). The remaining three bytes serve to identify nodes on the network, allowing us to connect more than 16 million devices on a Class A network.
Note that the networks in the above table make no mention of addresses with 127 as the first byte-this is a reserved address range. The address 127.0.0.1 is always the address of the local host, and 127.0.0.0 is a local loopback. Loopbacks are used to test the network protocol stack on a machine without going through the network interface card.
Class B networks always have the first two bits of the IP address set to 10, giving a range of 10000000 (128) to 10111111 (191). The second byte further identifies the network with a value of 0 to 255, leaving the remaining two bytes to identify nodes on the network; a total of 65,534 devices.
Class C networks are denoted by an IP address where the first three bits are set to 110, allowing a range of the first byte from 11000000 (192) to 11011111 (223). With this network type, only one byte is set aside for node identification, so only 254 devices can be connected.
The number of devices that can be connected to each of these different network classes with a distinct IP address is inversely proportional to the number of networks of that type available. For instance, a Class A network, allowing 16 million hosts, only leaves part of the first byte for identifying the network. The result is that there are only 126 Class A networks available worldwide. Only big companies such as AT&T, IBM, Xerox, and HP have such a network address. When a company requests an IP network from a network authority, it will usually only be allocated a class C network. Should the company desire more hosts to be directly connected to the Internet, an additional Class C network can be sought. Another option applies if each network host doesn ‘t need direct Internet access, when a private IP address can be used. We discuss private IP addresses in the next section.
Class A, B, and C network addresses leave addresses that have a first byte of 224 to 255. Class D networks (224-239) are used for multicasting, as we will see in Chapter 7, and Class E (240-255) is reserved for testing purposes.
The IANA (Internet Assigned Numbers Authority) assigns network numbers, and lists them at http://www.iana.org/assignments/ipv4-address-space. Nearly every country has a regional registration authority to give network numbers to requestors. The regional authority receives a network range from IANA.
Private IP Addresses
To avoid exhausting IP addresses, hosts that are not directly connected to the Internet can use an address in the private address ranges. Private addresses are not globally unique, and are just unique locally within the network. All network classes reserve certain ranges for use as private addresses for hosts that do not require direct two-way access to the Internet. Such hosts may well access the Internet through a gateway that doesn't forward private IP addresses.
Class
Private Address Range (Network Part of IP address)
A
10
B
172.16-172.31
C
192.168.0-192.168.255
Address allocation for private addresses is described with RFC 1918.
Subnets
Connecting two nodes of different networks requires a router. The host number is defined by 24 bits of a Class A IP address; while with a Class C network, just 8 bits are available. A router splits the host number into a subnet number and host number. Adding additional routers will reduce broadcasts in the network, which can reduce network load. The main reason for adding routers is to improve connectivity between sites in different buildings, cities, and so on.
Let's look at a subnetting example of a Class C network with an address 194.180.44. Such a network may have a subnet mask of 255.255.255.224 to filter addresses. The first three bytes (which consist of all ones) are the mask for the class C network. The last byte, 224, is the decimal value for the binary representation 11100000, so that 3 bits of the host number indicate the subnet, and the remaining 5 bits represent the host number on a particular subnet. These 3 subnet bits represent 128, 64, and 32, and thus support the subnet addresses shown below:

So the subnet 194.180.44.64 will contain hosts with addresses from 194.180.44.65 to 194.180.44.94, and the subnet 194.180.44.160 contains hosts from 194.180.44.161 to 194.180.44.190.
IPv6
The predecessor of the Internet Protocol was developed by the US Defense Department's Advanced Research Project Agency (DARPA) in the 1960s, and the TCP/IP protocol suite was not established until 1980. Because IP was based on the existing DARPA network protocols, it became version 4, now known as IPv4. At that time, when most people's idea of a mobile phone was one that could be taken off the wall and used on the couch, the number of hosts supported by IP seemed more than adequate. Now, however, everyone wants to connect their refrigerator and lawnmower to the Internet. To answer this demand, a new IP version has been under development by the IETF: IPv6. The most important change over IPv4 is the use of 128 bits to address nodes rather than 32 bits-which will allow every Tablet PC, Pocket PC, mobile phone, TV, car, lawnmower, coffee machine, and dustbin to become a fully-fledged Internet host.
As well as being able to allocate an address to just about every atom in the solar system, there are one or two other useful changes with IPv6:
Extended Addressing Capabilities
Multicast routing information can be added to IPv6 addresses to define the scope of a multicast address. Also there's now an anycast address to send a message to any host or group of hosts.
Header Format Simplification
Some of the header fields of IPv4 have been removed, and others are now optional. However, the complete header length of IPv6 is longer than IPv4 because of the 128-bit addresses for source and destination.
Improved Extensibility Support
It should be easier to add extensions to the IPv6 protocol in the future. The length restriction for options has been removed.
Flow Labeling
A new capability is added for particular traffic flows. A flow is a sequence of packets traveling from a source to a destination. With the new protocol, applications can offer both audio and video real-time capabilities over different flows. Each flow can request a real-time or specific quality-handling from routers that it travels through.
Authentication and Privacy
IPv6 extensions to support authentication, privacy, and confidentially of data sent are added.
Transport Layer-Port Numbers
The IP protocol uses IP addresses to identify nodes on the network, while the transport layer (layer 4) uses endpoints to identify applications. TCP and UDP protocols use a port number together with an IP address to specify an application endpoint.
The server must supply a known endpoint for a client to connect to, although the port number can be created dynamically for the client.
TCP and UDP port numbers are 16 bits, and can be divided into three categories:
System (Well-Known) Port Numbers
User (Registered) Port Numbers
Dynamic or Private Ports
The system port numbers are in the range 0 to 1023. System port numbers should only be used by system privileged processes. Well-known protocols have default port numbers in this range.
User port numbers fall in the range 1024 to 49151. Your server applications usually will take one of these ports, and you can also register the port number with the Internet Assigned Numbers Authority (IANA) if you wish to make it known to the Internet community.
Dynamic ports are in the range 49152 to 65535. When it is not necessary to know the port number before starting an application, a port in this range would be suitable. Client applications connecting to servers might use such a port.
If we run the netstat utility with the -a option, we'll see a list of all ports currently in use, and also an indication of the state of the connection-if it's in listening state, or if a connection has been already established:

The file services in the directory \system32\drivers\etc lists many predefined user and system port numbers. If a port is listed in this file, the netstat utility will display the name of the protocol instead of the port number.
IANA assigns system and user port numbers. You can find a list of defined port numbers at http://www.iana.org/assignments/port-numbers.
TCP-Transmission Control Protocol
Connection-oriented communication can use reliable communication where the layer 4 protocol sends acknowledgements of data receipts, and requests retransmission if data is not received or is corrupted. The TCP protocol uses such reliable communication.
Some of the application protocols that use TCP are HTTP, FTP, SMTP, and Telnet.
TCP requires that a connection must be opened before data can be sent. The server application must perform a so-called passive open to create a connection with a known port number, where rather than making a call to the network, the server listens and waits for incoming requests. The client application must perform an active open by sending a synchronize sequence number (SYN) to the server application to identify the connection. The client application can use a dynamic port number as a local port. The server must send an acknowledgement (ACK) to the client together with the sequence number (SYN) of the server. The client in turn answers with an ACK, and the connection is established.
Now sending and receiving can start. After receiving a message, an ACK messages is always returned. If the sender times out before receiving an ACK, the message is placed in the retransmit queue for sending again.
The TCP header fields are listed in the table below:
Field
Length
Description
Source port
2 bytes
Port number of the source.
Destination port
2 bytes
Port number of the destination.
Sequence number
4 bytes
The sequence number is generated by the source and is used by the destination to reorder packets to create the original message, and to send an acknowledgement to the source.
Acknowledgement number
4 bytes
If the ACK bit of the Control field is set, this field contains the next sequence number that can be expected.
Data offset
4 bits
Details where the packet data begins.
Reserved
6 bits
Reserved for future use.
Control
6 bits
The control bits contain flags that denote if the acknowledgement (ACK) or urgent pointer (URG) fields are valid, if the connection should be reset (RST), if a synchronize sequence number is sent (SYN), and so on.
Window Size
2 bytes
This field indicates the size of the receive buffer. The receiver can inform the sender of the maximum data size that can be sent using acknowledgement messages.
Checksum
2 bytes
A checksum for the header and data to determine if the packet has become corrupted.
Urgent Pointer
2 bytes
This field informs the target device of urgent data.
Options
variable
Again option values will only be specified when relevant.
Padding
variable
The padding field adds zeros so that the header ends on a 32-bit boundary.
The TCP protocol is complex and time consuming because of the handshaking mechanism, but this protocol takes care of guaranteeing delivery of packets, obviating the need to include that functionality in the application protocol.
Important
The TCP protocol has a reliable delivery built-in. If a message isn't sent correctly, we will be informed by an error message.
The TCP protocol is defined with RFC 793. Programming with the TCP protocol is covered in .
UDP-User Datagram Protocol
Contrary to TCP, UDP is a very fast protocol as it specifies just the minimum mechanism required for data transfer. Of course this has some disadvantages. Messages can be received in any order, and a message that was sent first could be received last. The delivery of UDP messages is not guaranteed at all, and messages can be lost, or even two copies of the same message might be received. This latter scenario can happen when two different routes are used to send the message to the same destination.
UDP does not require a connection to be opened, and data can be sent as soon as it is ready. UDP doesn't send acknowledgement messages, so the data can be received, or it can be lost. If reliable data transfer is needed over UDP, it must be implemented in a higher-level protocol.
So what are the advantages of UDP, why would we want to use an unreliable protocol such as this? To understand the most important reason for using UDP, we have to differentiate between unicast, broadcast, and multicast communications.
A unicast message is sent from one node to just one other. This is also called point-to-point communication. The TCP protocol only supports unicast communication. If a server wants to communicate with multiple clients using TCP, each client must make a connection, as messages can only be sent to single nodes. A broadcast means that a message is sent to all nodes in a network. Multicast is something in-between: messages are sent to selected groups of nodes.
UDP can be used with unicast communications if fast transfer is required, such as for multimedia delivery, but the major advantages of UDP apply to broadcasts and multicasts. Usually we don't want an acknowledgement from every node when sending a multicast or broadcast, as the server would be deluged, and the network load would be too great. An example of such a broadcast is the time service. A time server broadcasts a message containing the current time, and any host that wishes may synchronize the time with that in the broadcasted message.
The UDP header is a lot shorter and simpler than the TCP header:
Length
Field
Description
2 bytes
Source port
Specifying the source port is optional with UDP. If this field is used, the receiver of the message can send a reply to this port.
2 bytes
Destination port
Port number of the destination.
2 bytes
Length
The length of the message including header and data.
2 bytes
Checksum
A checksum for the header and data for verification.
Important
UDP is a fast protocol, but delivery is not guaranteed. If message ordering and delivery is required, TCP should be used. UDP is primarily a protocol for broadcasts and multicasts.
UDP is defined with RFC 786. You can read information on how to program applications using UDP in .
ICMP-Internet Control Message Protocol
ICMP is a control protocol used by IP devices to inform other IP devices of activity and errors in the network. Without TCP, IP is not a reliable protocol, and there are no acknowledgements, no error control for data (only a header checksum), and no retransmissions.
Errors detected may be reported with ICMP messages. The ICMP messages are used to send feedback about the status of the network. For example, a router sends an ICMP 'destination unreachable' message if a suitable entry for a network cannot be found in a routing table. A router can also send an ICMP 'redirect' message if a better path was found.
ICMP doesn't sit on top of the IP protocol as it may appear, rather ICMP messages are sent within the IP header. Hence, the ICMP protocol must be implemented by the IP module of the network stack. These ICMP message fields are prefixed to the IP header:
Length
Field
Description
1 byte
Type
This field specifies the ICMP message type. For example, a type value of 3 means that the destination is unreachable, 11 specifies that the time was exceeded, and 12 that incorrect header parameters were found.
1 byte
Code
The code provides more information about the message type. If the type is destination unreachable, the code specifies whether the network (0), host (1), protocol (2), or the port (3) is unreachable.
2 bytes
Checksum
A checksum of the ICMP message.
4 bytes
Depending on the type
The last 4 bytes of the ICMP header can supply additional information depending on the message type.
...
Regular IP Header

Some of the types that can be sent using ICMP messages are:
Echo, Echo reply
This ping command sends an ICMP Echo command to the destination device, and if all goes well an Echo reply is sent back.
Destination unreachable, Redirect
A router returns the ICMP destination unreachable message if a target cannot be reached, or a redirect if a better path is found to a target.
Time exceeded
The time to live (TTL) value was exceeded.
Ping Command
The Windows command line ping utility sends an ICMP Echo message to the target device specified by hostname or IP address in the ping command. If the device can be reached, an ICMP Echo Reply is sent back.
This command is very useful to check if a device can be reached, if there are intermediate problems (PING -t continues sending ping messages until it is stopped), and how long it takes to send a message to the device.
If you can't reach a host using the ping command it is not necessarily the case that the host cannot be reached by using other protocols. The ICMP echo messages may be blocked by routers or firewalls.
The picture below shows the output produced by ping for the host with IP address 212.183.100.193. By default, ping sends four ICMP messages to the target, and waits for the echo messages. The screenshot shows that 32 bytes of data were sent, and the time until the reply was received was less than 10 milliseconds. A summary appears after the four ICMP results, where we can see that 0% of the packets were lost. Intermediate failures would usually lose a certain percentage of the packets.

ICMP is defined with RFC 792.
IGMP-Internet Group Management Protocol
Similarly to ICMP, IGMP is an extension to the IP protocol and must be implemented by the IP module. IGMP is used by multicasting applications. When sending a broadcast message to a complete LAN, every node in the LAN analyzes the message up to the transport layer to verify if some application wants to receive messages from the port of the broadcast. If no application is listening, the message is destroyed and does not progress beyond the transport layer. This does mean that some CPU cycles are needed by every host no matter if the broadcast message is of interest or not.
Multicasts address this concern, by only sending messages to a group of nodes rather than every node in the LAN. The network interface card can detect if the system is interested in a particular message by analyzing the broadcast MAC address without needing the assistance of the CPU.
Registering interest in a multicast message is done by sending a group membership request for a multicast address with an IGMP message. Similarly, IGMP can be used to drop a membership.
You can read more about the use of IGMP in , where we create .NET multicasting applications. IGMP is defined by RFC 2236.
Internet Protocols
After discussing base protocols, we can now step up to a higher level. The HTTP and FTP protocols cover layers 5-7 of the OSI model.
FTP-File Transfer Protocol
FTP is used to copy files from and to a server, and to list files and directories on a server. It is an application level protocol based on TCP, where FTP commands are encapsulated within the TCP data block of a TCP message.
An application model with an FTP server and client is illustrated in the picture below. The client application presents a user interface and creates an FTP request according to the user's request and the FTP specification. The FTP command is sent to the server application over TCP/IP, and the FTP interpreter on the server interprets the FTP command accordingly. Depending on the FTP command, a list of files or a file from the server's file system is returned to the client in an FTP reply.

The FTP protocol has these characteristics:
Reliable data transfer through TCP
Anonymous access or user authentication with user name and password
Files are sent as ASCII in a form supported by the target platform, or as unchanged binary data.
FTP commands can be grouped into these categories:
Access Control Commands
FTP access control commands specify the user name (USER) and password (PASS), the settings can be reset (REIN), and the connection can be ended (QUIT).
Transfer Parameter Commands
FTP transfer can be configured with transfer parameter commands. Changing the transfer from ASCII to binary, data compression, changing of ports to send data is supported by these commands.
FTP Service Commands
Copying files from the server (RETR), copying files to the server (STOR), deleting files (DELE), renaming files (RNTO), creating directories (MKD), and asking for a list of files (LIST) are some of the FTP service commands.
FTP is defined by RFC 959.
FTP Clients
The best way to get to grips with the FTP protocol is by using the ftp command-line utility as shown below. The ftp program operates through the ftp> command prompt allowing us to enter commands. These commands are different from the commands of the FTP protocol-you can see them all by entering ?. Below, I enter the command open ftp.microsoft.com to create a connection to the host ftp.microsoft.com. Setting the username to anonymous indicates a guest user. The response 230 from the server indicates that a connection has been established, and we can list the files on the server using the dir command. On receiving the dir command, the ftp program sends an FTP LIST command to the server, cd can be used to change directories on the server, and the get command copies a file to the client by sending a RETR command. The ftp utility uses the bye command to close the connection:

Another FTP client is Microsoft Internet Explorer. Instead of using a URL such as http://hostname, we start the FTP client with ftp:// as a schema identifier. This tool allows files to be copied with drag and drop:

HTTP-Hypertext Transfer Protocol
HTTP is the main protocol used by web applications. Similar to the FTP protocol, HTTP is a reliable protocol that is achieved by using TCP. Like FTP, HTTP is also used to transfer files across the network. Unlike FTP, it has features such as caching, identification of the client application, support for different attachments with a MIME format, and so on. These features are enabled within the HTTP header.
To demonstrate what an Internet browser is doing when it requests files from a web server, we can use the telnet application to simulate a browser. Start the telnet application by entering telnet in the Run dialog of the Start menu, and we see the Microsoft Telnet> prompt. Enter set local_echo (set localecho with Windows XP) to display the entered commands locally for demonstration purposes. If we don't set this option, commands we send to the server would not be displayed by the telnet application. Now we can connect to the web server with the open command. The command open msdn.microsoft.com 80 creates a TCP connection to port 80 of the server at msdn.microsoft.com. The telnet application uses port 23 by default, hence we have to specify a port for the HTTP request. The default port of a web server offering HTTP services is port 80.

As soon as the connection is initiated we can send an HTTP request to the web server. A simple request consists of a request line followed by two returns (two CR-LF sequences). Such a request line can look like one we are using in the picture below: GET /default.asp HTTP/1.0. The server returns anHTTP response that consists of the status information (in this case 200 OK) followed by the HTML content:

As we have seen, a basic HTTP request has only a single request line. A full HTTP request however will comprise a request line with additional headers and data.
HTTP commands such as GET, HEAD, and POST can be specified in the request line. Both GET and POST request data from the server. The GET command includes request parameters in the URL, while the POST request specifies that parameters follow in the data block. The HEAD command means that we just want to know when the requested file was changed so we can verify if the newest version is already in the cache.
General headers, request headers, and an entity header can follow the request line. This header information allows the client to tell the server about the browser in use, any preferred languages, to send a cookie, or to request files only if they have been changed. In the telnet example, we have already seen some header information returned by the server: the date, server version, content-length, content-type, and cache-control.
More information about the HTTP protocol and programming with the HTTP protocol can be found in . HTTP is defined by RFC 1945.
HTTPS-HTTP over SSL (Secure Socket Layer)
If there is a requirement to exchange confidential data with a web server, HTTPS can be used. HTTPS is an extension to the HTTP protocol, and the principles discussed in the last section still apply. However, the underlying mechanism is different, as HTTPS uses SSL (Secure Socket Layer), originally developed by Netscape. SSL sits on top of TCP and secures network communication using a public/private key principle to exchange secret symmetric keys, and a symmetric key to encrypt the messages.
To support HTTPS, the web server must install a certificate so that it can be identified. The default port for HTTPS requests is 443.
For more information on SSL, go to the following page on the Netscape web site: http://wp.netscape.com/eng/ssl3/ssl-toc.html.
E-Mail Protocols
There are quite a few protocols for use with e-mail. In this section, I'll try to provide an overview of the most important mail-related protocols. In Chapter 9, we will look into these more, and see how to create applications that use them.
SMTP-Simple Mail Transfer Protocol
SMTP is a protocol for sending and receiving e-mail messages. It can be used to send e-mail between a client and server that both use the same transport protocol, or to send e-mail between servers that use different transport protocols. SMTP has the capability to relay messages across transport service environments. SMTP does not allow us to read messages from a mail server, however, and for this activity POP3 or IMAP protocols should be used.
An SMTP service forms part of the Internet Information Server installation of Windows 2000 and XP.
The SMTP standard is defined with RFC 821; the SMTP message format is defined with RFC 822.
POP3-Post Office Protocol
The Post Office Protocol was designed for disconnected environments. In small environments it is not practical to maintain a persistent connection with the mail server, for instance, in environments where the connection time must be paid. With POP3 the client can access the server and retrieve the messages that the server is holding for it. When messages are retrieved from the client, they are typically deleted on the server, although this is not necessarily the case.
Windows .NET Server includes a POP3 server.
POP 3 is defined by RFC 1081.
IMAP-Internet Message Access Protocol
Like POP3, IMAP is designed to access mails on a mail server. Similar to POP3 clients, an IMAP client can have an offline mode where mails can be manipulated on the local machine. Unlike POP3 clients, IMAP clients have greater capabilities when in online mode, such as retrieving just the headers or bodies of specified mails, searching for particular messages on the server, and setting flags such as a replied flag. Essentially, IMAP allows the client to manipulate a remote mailbox as if it was local.
IMAP is defined with RFC 1730.
NNTP-Network News Transfer Protocol
Network News Transfer Protocol is an application layer protocol for submitting, relaying, and retrieving messages that form part of newsgroup discussions. This protocol provides client applications with access to a news server to retrieve selected messages, and also supports server to server transfer of messages.
NNTP is defined by the RFCs 850, 977, and 1036.
Other Application Protocols
There are two other interesting application protocols: SNMP and Telnet.
Simple Network Management Protocol (SNMP) aims to permit management of devices on the network. There is no lack of information such as performance counts from devices; instead there is too much information to manage it effectively. SNMP aims to manage devices effectively using alarms triggered by performance problems and faults, and allows devices to be configured.
An SNMP agent associated with a particular network device will have an MIB (Management Information Base) database that contains all manageable information for that device in an object-oriented manner (that is, consisting of objects, attributes, and instances). An SNMP client accesses the information in this database by sending SNMP GET requests. Conversely, SNMP SET requests are used to configure the MIB database.
In case of faults or performance problems, the SNMP agent sends trap messages to the SNMP client.

SNMP is defined with RFC 1157. The MIB database is defined with RFC 1155 and RFC 1156.
Earlier, we used the telnet application to simulate a browser as it carries out an HTTP request. However, the telnet application is primarily intended for connecting to a telnet server using the Telnet protocol. This protocol lets us connect to a remote system using user authentication, and to then invoke commands remotely from a console