Assignment 3: Message Exchange

You are going to develop a showcase application (that is, not a production system) to demonstrate a more modern equivalent to the torn-tape message switching or relay system. Imagine a room filled with primitive printer/keyboard devices, each with a paper-tape reader and writer. Message switching is accomplished by sending a message from a source location (maybe a business) to be punched as holes in paper tape at such a relay centre. An operator (an actual real human being) would tear off the paper tape section, identify the destination (a customer, perhaps, or a supplier), and hand-carry the tape to another crude telex (teleprinter exchange) machine and send it on to its destination (or forward to another message switching centre):

"Linked teletypewriters in corporate networks with administrative message switching provided the first crude electronic mail service. Paper tapes were used to store and forward messages on switched systems: these networks were known as torn tape systems. Beginning in the 1930s, the Telex and TWX (teletypewriter exchange) services made two-way point to point teletypewriter service available to individual businesses (table <AJF.A.3>)." - Field, Alexander J., Communications. HISTORICAL STATISTICS OF THE UNITED STATES: MILLENNIUM EDITION, Vol. 4, pp. 977-998, Cambridge University Press, 2006. Available at SSRN: http://ssrn.com/abstract=1105636

Use your knowledge of sockets and message queues to write a torn-tape message exchange (MX) server application, as well as an accompanying client program, that can perform several operations on the messages:

The client can send a message to the MX (Message Exchange) server to be held until requested, request messages from the MX for display on stdout, and delete a message (requires user confirmation). It must first identify itself to the MX server (login) and end each session with a closing message (logoff). The MX server can handle at least 5 simultaneous clients from a pool of 100 clients, identified by the numbers 1 to 100. The client stations do not require a password.

The client reads a command from stdin, performs the required action or actions by communicating with the MX server (this is running on your VMware virtual network), prompting for new commands until the command to terminate the client is given (you may use any SFW command name you wish, as defined in your user documentation):

Command	Client/Server Action
login	Send the client id to MX and receive confirmation
logoff	Send a request to end this client session
send	Send message text for a client destination
receive	Request all messages queued for this client, if any
delete	Order the MX server to remove a message

Your first task should be to define a protocol, both the sequence of messages and responses and the struct definitions to be used for each message type (it's possible to have only one message type or to use several, one for each purpose).

The MX server will record each client id on login and remove it at logoff; add messages to the queue by the target client id (mtype might be good); respond to receive requests with a) a count of messages on the queue for this target client, and b) each message in turn. Message deletion occurs only on client request (that is, reading a message does not automatically remove it), and can only be done to messages for that client. Perhaps you will combine that with the message receipt process, keeping some and deleting others. Hint: have the server assign a unique message id for each client's messages.

You may optionally also support Client Zero (with an id of 0; basically a root user) who can perform any action as if it were that actual client, including an extra command to terminate the server and all current client sessions. Well done and complete Client Zero implementations will receive a bonus of 10% of the mark otherwise earned.

Your programs, complete with PDL, Data Dictionary, Test Plan, and so on (all the standard submission requirements) must have a well-defined protocol, at least two include files, and a working makefile. You may not use the atoi()/atol(), system(), popen()/pclose(), scanf()/fscanf(), or strtok() functions.

Part A is due first, and consists of all your Analysis and Design documents (keep a copy to work from, as this will be returned with the marked part B). Part A must include a detailed description of your communication protocol and its message blocks (application-level packets or structures only). Part B is due one week later, and will include your complete source code, makefile, and the results from executing your Test Plan from part A. Be sure to demonstrate clearly that your programs work correctly by including script(1) output that is complete (but brief - no book is needed) and explicit, for at least two simultaneous clients running on your virtual network.

Submissions must be cleanly printed on standard letter paper, complete with a title page, and placed in my drop box by 12:00 noon on Friday:

Part A: 13 November 2009

Part B: 20 November 2009 (also the date of the second midterm)

It is strongly recommended that you work in pairs, ensuring that both partners actively participate in all aspects of the planning, design, programming, and testing.