TCP/IP is the most heavily used communications protocol for inter-process communication. It is broadly supported by the socket programming paradigm across multiple platforms. In this assignment, you will write a chat program to demonstrate the basics of socket-based TCP/IP communications.

Objectives

• Practice C Programming techniques for socket-level programming as well as multi-threaded solutions
• Practice the integration and use of a 3^rd party library (NCURSES)

Requirements

1. In this assignment you are creating a system called CHAT-SYSTEM. This system is comprised of 2 applications the server (called chat-server) and the client (called chat-client). These names must be used and reflected in your system development structure. (Please refer to the Linux Development Project Code Structure document in the course content)
2. Your solution architecture must be a central server model written in ANSI C.
   • The server must be multi-threaded. A new thread will be created each time a new user joins the conversation. This thread will be responsible for accepting incoming messages from that user and broadcasting them to the other chat users. Call the server chat-server.
   • QUESTION: How will each of the threads learn about all of the other threads and their IP addresses in order to send the message? Think of a data structure that might be used to hold all client information (IP Address, the user name, etc.) within the server and will be visible and shared among all the communication threads.
   • Your client application will be written to make use of the ncurses library in order to facilitate the multiple windows. Call the client program chat-client.
   • I have provided some sample ncurses programs in the ncurses-samples.tar archive
   • You may also want to experiment with threading the client program one thread to handle the outgoing message window and one thread to handle the incoming messages window.
   • The chat functionality must operate across computers that are in the same subnet
3. Your chat solution must be able to support at least 2 users being able to chat with each other.
   • This means that each person can see the messages in the conversation as it goes back and forth

so each users message must be tagged with their name (or userID)

• Your server design must be able to support a maximum of 10 clients.

4. While running the CHAT-SYSTEM the minimum configuration must be:
   • The chat-server application must run on a Linux VM (MACHINE-A)
   • One of the chat-client applications must run on a different Linux VM (MACHINE-B)
   • The second chat-client application can run on the same Linux VM as the server (MACHINE-A)
   • It is recommended that your chat-client application take at least 2 command-line switches as follows:

chat-client user<userID> server<server name>

Please see the section title Finding the Servers Name below for more details and hints

5. The chat solution clients UI only needs to be very basic and simple.
   • You will need to incorporate the use of the ncurses library to do this
   • The minimum UI requirement is show in Figure 1 at the end of the document. The basic UI consists of a prompt area (to allow a user to input a message) as well as a dedicated area on the screen to display the conversation. The message is sent to the recipient when the carriage return is pressed.
   • As you can see by the extra ncurses resource links (at the end of the assignment) you are also able to draw windows on the screen. You could use this concept to soup up your UI (as shown in Figure 2)
6. Your solution must enforce and parcel all messages being input at the 40 character boundary The user should be allowed to enter a message of up to 80 characters. When the user hits the 80 character input boundary the UI should stop accepting characters for input
   • As mentioned, the chat program will parcel up and send the outgoing message into 40 character lengths.
   • So if the user happens to enter a message that is 56 characters in length before pressing ENTER (to send) then one message of length 40 will be sent and another message of length 16 will be sent immediately following it.
   • An example of this kind of message is shown in Figure 2 below
   • As a usability factor it would nice for your chat program to break the message at/near the 40 character boundary based on a space character (i.e. between words)

7. The clients incoming message window of your UI:
   • Should display each of the incoming messages in a specific format. This format is detailed in the Incoming Message Formatting section below and as well is also shown in the sample screenshots.

8. The clients incoming message window should be able to show the history of at most the last 10

lines from the messages sent and received. Please note that a message is allowed to take up 2

lines in the output window (i.e. one line for each of the 40 character messages) this requirement indicates that a maximum of 10 lines of output are present in the message window before being scrolled

9. Your solution should be architected such that messages should be received as soon as they are sent. And as well, if a message is received when the user is typing another message, it must not interrupt the message being currently composed.
10. When the user enters the message >>bye<< their client application will shut down properly.
    • The server can end the thread that is connected to this client and as well clean up any information dealing with the client.
    • When the number of threads reaches zero in the server, it may shutdown properly
11. There should be no debugging messages being printed to the screen in your final client and server programs.
12. Your solution must be programmed to handle any and all errors gracefully.
13. Your solution must be programmed to handle any and all shutdowns gracefully.
14. If there are command line parameters available in either your client or server programs then make sure that a usage message appears if the parameters are incorrect or missing.
15. Include the completed A-04: Test Report in your submission
    • This document does not have to be part of your cleaned, submitted TAR file
16. Make sure to submit your commented, cleaned TAR file to the appropriate drop-box by the due date and time

What About the Message?

You need to think about what needs to be sent in the message and how it will be formatted. When you are using sockets (or any low-level communication mechanism) one of the most exciting things is that you are in control of the messaging protocol! You get to create the format of, program and enforce your own communication scheme. So lets consider what needs to be placed in the actual message what pieces of information need to be sent between the chatting parties?

• The IP address of the incoming message can be gotten through the accept() function call or you could include it in your message
• What about the name (5 characters) of the person sending the message?
• What about the actual message contents? Should it be parceled on the client before the original send? Or on the server before broadcasting?

• Make sure to include where/how the server will gain knowledge of the client IP and clients user name
• Be sure to include documentation on how the server will handle the >>bye<< message and shutdown / clean-up after the client. And as well clean-up after itself (when all clients are gone)
• Also ensure to indicate how your server data structure is managing the list of all clients do this by describing the structure / elements / values being stored for each client

ncurses Resources

Here are a couple of extra resources that you can use to do more in-depth research on the functionality and capabilities of the ncurses library.

• Installing ncurses on Your Own Linux Installation
• Programmers Guide to ncurses
• Another Programmers Guide (of sorts) but with sample programs
• Simple Hello World Tutorial

Incoming Message Formatting

Here is the layout of each of the chat messages being sent from and/or received by your program as well, an explanation of the format follows.

0 1 2 2 6 1 7 5 8 9

XXX.XXX.XXX.XXX_[AAAAA]_>>_aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa_(HH:MM:SS) IP ADDR -USER MESSAGE TIME

• Should display the IP address of the messages source
• in positions 1 through 15 of the output line
• Positions 16, 24, 27 and 68 should be spaces (as highlighted above)
• Should show the name of the person sending the message (max 5 characters) enclosed in square brackets ([ and ])
• in positions 17 through 23 (including the brackets)
• Should show the directionality of the message (i.e. >> for outgoing, << for incoming)
• in positions 25 and 26
• you should see >> on your client if you sent the message
• you should see << on your client if the message came from another client
• Should show the actual message (again max 40 characters)
• in positions 28 to 67
• Should show the a 24-hour clock received timestamp on the message enclosed in round brackets (( and ))
• in positions 69 to 78 (including the brackets)
• this should reflect the time that the client received the message from the server

Finding the Servers Name

As was discussed during the Module on Sockets, the underlying TCP/IP protocol being used in this solution works by knowing the name / identity or address of the computer you are trying to communicate with.

As you learned in OSF computers can be given names (e.g. B03-213) and computers can be networked and be made part of a domain (e.g. conestogac.on.ca). If we were trying to communicate with this computer within the domain then we could open a TCP/IP communication to B03-213.conestogac.on.ca and we would find ourselves talking to that computer!

You also learned in OSF that each computer on a network is assigned an IP address (IPv4 and IPv6). This IP address also serves as the name of the computer when talking across any of the TCP/IP protocols. In Windows, you learned about the ipconfig command which allows you to find the computers IP address. In Linux the comparable command if ifconfig.

It is recommended that when constructing and running the CHAT-SYSTEM you find the servers name by choosing the IPv4 address (referred to as the inet address (not inet6)) of the networking devices shown in the ifconfig command. This command will show you many networking devices the ethernet networking connection device will most likely be called something like eth0.