In Chapter7, we'll discuss the advantages of breaking complicated applications up into cooperating processes speaking an application-specific command set or protocol with each other. All the good reasons for data file formats to be textual apply to these application-specific protocols as well.

When your application protocol is textual and easily parsed by eyeball, many good things become easier. Transaction dumps become much easier to interpret. Test loads become easier to write.

Server processes are often invoked by harness programs such as inetd(8) in such a way that the server sees commands on standard input and ships responses to standard output. We describe this “CLI server” pattern in more detail in Chapter11.

A CLI server with a command set that is designed for simplicity has the valuable property that a human tester will be able to type commands direct to the server process to probe the software's behavior.

Another issue to bear in mind is the end-to-end design principle. Every protocol designer should read the classic End-to-End Arguments in System Design [Saltzer]. There are often serious questions about which level of the protocol stack should handle features like security and authentication; this paper provides some good conceptual tools for thinking about them. Yet a third issue is designing application protocols for good performance. We'll cover that issue in more detail in Chapter12.

The traditions of Internet application protocol design evolved separately from Unix before 1980.^[54] But since the 1980s these traditions have become thoroughly naturalized into Unix practice.

We'll illustrate the Internet style by looking at three application protocols that are both among the most heavily used, and are widely regarded among Internet hackers as paradigmatic: SMTP, POP3, and IMAP. All three address different aspects of mail transport (one of the net's two most important applications, along with the World Wide Web), but the problems they address (passing messages, setting remote state, indicating error conditions) are generic to non-email application protocols as well and are normally addressed using similar techniques.

C: <client connects to service port 25>


C:
 HELO snark.thyrsus.com               
sending host identifies self


S:
 250 OK Hello snark, glad to meet you  
receiver acknowledges


C:
 MAIL FROM: <esr@thyrsus.com>         
identify sending user


S:
 250 <esr@thyrsus.com>... Sender ok   
receiver acknowledges


C:
 RCPT TO: cor@cpmy.com                
identify target user


S:
 250 root... Recipient ok             
receiver acknowledges


C:
 DATA

S:
 354 Enter mail, end with "." on a line by itself

C:
 Scratch called.  He wants to share

C:
 a room with us at Balticon.

C:
 .                                    
end of multiline send


S:
 250 WAA01865 Message accepted for delivery

C:
 QUIT                                 
sender signs off


S:
 221 cpmy.com closing connection      
receiver disconnects


C: <client hangs up>