B.5.4 Application Linguistics

Most TCP/IP applications use a "dialog" method for communicating between clients and servers. For example, the popular HTTP protocol consists of simple ASCII commands such as "GET" and "POST." The SMTP and POP3 mail protocols also use ASCII commands for all of their functions.

By using ASCII commands, TCP/IP is able to be used across a wide variety of systems. Any system that can generate 7-bit ASCII characters can participate on a TCP/IP network. The fundamental basis of almost all TCP/IP applications lies in the use of these ASCII commands.

Because these applications use character-based commands, you can use a Telnet client to communicate directly with an SMTP or POP3 mail server for example, or an HTTP server, or an FTP server, or almost any other TCP application.

Figure B.9 below shows a Telnet connection to an SMTP server:

Figure B.9 Using Windows 95's Telnet client to interact with an SMTP server.

Once a connection has been established, you can type data directly into the Telnet client, which will pass the commands over the TCP connection to the SMTP server. By passing commands which the SMTP server understands, you will be able to create a mail message, address it to a recipient, or execute any other SMTP commands. For example, Figure B.10 below shows the complete SMTP dialog for creating an e-mail message:

Figure B.10 Using Telnet to manually create an e-mail message over SMTP.

The client sends textual commands such as "mail from:" and "quit" while the server responds with numeric codes that indicate success, failure, or a detailed result, although any textual message may follow the numeric code. For example, the code "250" means "OK", although there are several different text messages following the "250" status message. The text strings following the numeric status codes are simply there for the benefit of any humans who may be watching the transaction.

Specifically, the message dialog is as follows (all using Telnet):

1. Client connects to SMTP server.
   
   
2. Server acknowledges connection with "220" status messages.
   
   
3. Client identifies itself with "helo" command.
   
   
4. Server acknowledges greeting with "250" status message.
   
   
5. Client begins a new mail message with "mail from:" command.
   
   
6. Server acknowledges sender with "250" status message.
   
   
7. Client designates recipient with "rcpt to:" command.
   
   
8. Server acknowledges recipient with "250" status message.
   
   
9. Client designates mail message body to begin with "data" command.
   
   
10. Server acknowledges message body with "354" status message. The "354" provides a more detailed response than the generic "254" response code.
    
    
11. Client designates end-of-body with "." by itself.
    
    
12. Server acknowledges end-of-body with "250" status message.
    
    
13. Client closes the connection with a "quit" command.
    

Because the SMTP application uses raw ASCII characters, any system capable of generating 7-bit ASCII can run them. There are no dependencies on 32-bit tokenized commands, or any other extended characters. This flexibility and portability is one of TCP/IP's most appealing aspects, especially in complex environments.

Once the message has been delivered to the recipient's in-box, the message they see will look something similar to Figure B.11 below:

Figure B.11 What the test message might look like from a Netscape Communicator mail client after being received.

For more information on ports and sockets, refer to section B.5.1 Port Numbers and Sockets. For more information on application servers, refer to section B.5.2 Servers Listen for Connections. For more information on the application clients, refer to section B.5.3 Clients Initiate the Connection. For more information on the SMTP and POP3 mail protocols, refer to Appendix D: SMTP and POP3 Mail.

Copyright © 1997, Unoverica Corporation. All rights reserved. Unauthorized use prohibited.