CS455/555 EE407/507 FA2009 Request for Comments Clarkson University TELEPHONE PROTOCOL---Ver. 1.0 Telephone Protocol is a networked version of the classic game "telephone". A message is generated and "whispered" from one to another and finally arrives back to the first one who has generated it. In the original game of telephone, the message usually arrives back at the originator garbled in a funny way. In this game, however, we are going to try and transfer the message without changing it. This protocol uses TCP as an underlying transport layer. Each "player" will serve as both a client and a server. Client must transfer the message to Server. Once the TCP connection between client and server is established, the client and the server should have a version handshake. After agreement on the protocol version, the client will send the message to the server. The server will examine the checksum of the message and output some summary information of the message it receives. Table of Contents 1 Introduction 2 Terminology 2.1 Message 2.2 Server and Client 2.3 Originator and Intermediate 3 Requirements 4 Specifications 4.1 Forming the Telephone Circle 4.2 Format of Message 4.3 Programming 4.4 Method of Transfer 5 Connection Initiation and Version Handshake 6 Data section 7 Internal Format of the data section 7.1 Hop 7.2 MessageId 7.3 NetworkAddress 7.4 System 7.5 Program 7.6 Author 7.7 SendingTimestamp 7.8 Message Checksum 7.9 Headers Checksum 7.9 Warning 8 Connection Termination and Error Handling 9 Valid Requests and Responses 10 Statistics Display 11 References Appendice A Scenarios Appendice B Checksum Examples 1 Introduction This protocol is a protocol designed for the game "telephone". It is an application-level protocol defining how a Telephone protocol application can communicate to others in order to transfer a message between computers that are set up in a ring type of topology. An original message will be sent from one of these computers and will be passed on through the ring and eventually end its trip by reaching the computer who originated the message. 2 Terminology Some key words in this document are to be interpreted as described below. 2.1 Message The term "message" refers to the plain text data message which the first computer originates and the others in the ring pass on. 2.2 Server and Client The Server/Client architecture is used in the protocol application. As specified in the requirements, the server is to receive the message from another machine in the ring and the client is to send the message to the other computer in the ring. It is intended that each application implementing the protocol participate as both a server and a client in the transfer of a message. The originator of the message begins as a client and then becomes a server waiting for the message to complete its trip around the circle of participants. All intermediate machines are first a server (waiting for the message to be sent to them) and then a client (passing the message on to the next machine in the circle). 2.3 Originator and Intermediate The machine who first handles a new message and sends it out is called the Originator while the rest of the computers in the ring who pass the message on to another and finally return it to the originator machine are called Intermediate machines. Each machine that transmits a message will add certain information about themselves including the author of the program, the language in which the program was written, the platform on which the program is running, the IP address and port number of the machine itself, the IP address and port number of the machine to which they are sending the data and checksum information to all the machines to detect data corruption in transit. Each machine that touches the message is responsible for determining if the message has been altered. The originator machine is responsible for displaying statistical information about the path of the message (number of machines it passed through, languages used, platforms used, time spent at each hop, etc.) 3 Requirements The protocol requirements, as specified in the assignment, are as follows: 1) Have a handshaking phase to allow client and server to agree on the version of the protocol use. 2) Transfer the original message exactly as given 3) Each computer should add its machine information in the message 4 Specifications Originator When a machine originates a message, it evokes its client to send the original message out. The machine becomes the originator. After the originator adds the required header information to the message and sends it out, the originator's server will keep listening until the message returns. From the message the originator server receives, the originator should display the statistics of the message on the screen. Intermediate For an intermediate machine, after its server receives the message from another client, the intermediate's information is added into the message and the intermediate client sends the message to another intermediate server or returns it to the originator. After the message is successfully sent out, the intermediate displays the statistics of the message and the machine from whom it receives the message. 4.1 Forming the Telephone Circle This protocol contains no support for forming the circle of machines nor for electing a originator. We intend that this either be done manually by those running the programs and then the necessary information passed to the program on a command line or set through a GUI interface. For example, we propose the following parameters to any telephone application: % telephone isOriginator(0/1) portToListenOn -IpaddressToSendTo portToSendTo It would also be possible for this information to be determined automatically through another protocol. For example, the Originator machine could allow intermediate to connect with their information and then it could determine an order for the ring and inform all intermediate machines. This is beyond the scope of this RFC. 4.2 Format of Message We restrict the contents of the message to contain only 7-bit ASCII characters. We will interpret all data sent as plain text. 4.3 Programming A Telephone Protocol application should be implemented as a single program that can serve both as a client and a server for this protocol as well as a parser of the metadata returned. There are no requirements on the language, operating system and other specifics of the program as long as the implementation follows the specifications outlined in this RFC. 4.4 Transfer Protocol The telephone protocol should use TCP as the transfer protocol. 5 Connection Initiation and Version Handshake As discussed above, TCP will be used to set up a connection between the client and the server. The client will be the first to open a connection to a listening server. Once the connection is established, the server should have a handshake with the client. The server should first send HELLO to the client after connection is established, and the client checks the version and responds HELLO to the server if the version is acceptable. If the server sends an unsupported version or the server says anything else, the client will respond QUIT. For example: S: HELLO 1.0 C: HELLO 1.0 OR S: HELLO C: QUIT OR S: C: QUIT 6 Data section After the client has a successful version handshake with the server, it will begin to send the message to it. It sends the request DATA, followed by the Header blocks, followed by one blank line and then the actual message to the server in the next step. The data block ends with a period on a line by itself. After the server has received the message, it responds SUCCESS. For example: C: DATA C: S: SUCCESS We package the message in the formation of metadata, and the protocol application should contain a message parser capable of analyzing the data. The data section is strictly specified in this format: ... . After the last Message Header Block, there is one blank line followed by the . records the information of each machine the message has passed through, and Message Header Blocks are in decreasing order. The last machine to send the message adds its information first and the first machine, the originator's information is at the bottom, and then a blank line precedes the actual message. Message header blocks must always come in this exact order. Further details on the contents and format of each will be mentioned in the next section. The data section is terminated by a line containing only a period, that is the character sequence . is the end of data indication. ::= ::= the carriage return character (ASCII code 13) ::= the line feed character (ASCII code 10) In order to handle data containing the same sequence, the following procedures are used: 1. Before sending a line of data the client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line. 2. When a line of data is received by server, it checks the line. If the line is composed of a single period it is the end of mail. If the first character is a period and there are other characters on the line, the first character is deleted. SMTP follows the same procedure. Refer to RFC 2821 for details. 7 Internal Format of the data section Each message header block contains the information of a machine that has touched the message. Hence, the message header blocks record the trip of the message. Headers must be in a particular order both from one machine and in decreasing order by hops. The message header block follows the format below, must always come in this exact order within a : Hop: MessageId: FromNetworkAddress: ToNetworkAddress: System: ///... Program: / Author: //... SendingTimestamp: :: MessageChecksum: HeadersChecksum: Warning: each line in message header ends with a . Each message header line has a similar format