ECE361 Computer Networks Text Conferencing Lab 2 solution


Original Work


5/5 - (8 votes)

Objective In this lab, you will use UNIX TCP sockets to implement a simple conferencing application. Reference Before starting this assignment, you should read Section 2.4 “The Berkeley API” of your textbook. For further information on network socket programming, you may read Beej’s Guide to Network Programming posted on the course website. Project Description In this assignment, you need to implement a conferencing application. It consists of a server with registered users, and several client nodes which are the end points for a particular conference session. The clients may be located in different networks. TCP will be used to communicate between the clients and the server. Each client has a unique name referred to as the identifier (ID). The ID of a node is unique among participating nodes. The server is assumed to have a list of client IDs that it will accept, and each ID is associated with a password (perhaps through a user registration procedure that took place before the time of this project). A client must first log into the server with its ID and the server’s IP address. Upon logging in by a client, the server will create a binding between the client and itself until the client exits. When a client wishes to communicate with other clients, it must create a conference session on the server. A conference session is simply a list of clients that are sending text messages to one another. Any message sent by a single user is seen by all clients that are participating in the conference session. It is the server’s responsibility to multicast the text data to all participating clients. You will implement both the server and the client processes. Protocol The following protocol is only a suggestion. Feel free to amend, or even use a completely different protocol, but you must implement the basic commands and functionalities specified in the next two sections. You are required to explain your protocol and its implementation in the demo lab session. We use two categories of messages: data and control. Control messages are used for client-server binding, session creation, invitation, termination, etc. Since you are using 2 TCP, you do not need to use acknowledgements for reliability. You only need acknowledgements for success/failure conditions at the server, e.g. whether login is successful. You must use the following structure for data and control messages: struct lab3message { unsigned int type; unsigned int size; unsigned char source[MAX_NAME]; unsigned char data[MAX_DATA]; }; The type field indicates the type of the message, as described in the table below. The size field should be set to the length of the data. The source field contains ID of the client sending the message. The following table shows all control packets that must be implemented: 3 Section 1 Client Program (Client.c): You should implement a client program, called client.c, in C on a UNIX system. Its command line input should be as follows: client Upon execution, the client program will wait for further commands on the command line, and start a receive thread. You should have a strategy to deal with unavailable port numbers. For example, you can use the UNIX netstat command to find out which ports are available on the system. The login process should be clear from the available messages and command parameters. You may assume that the passwords are sent and received in plain text. TCP is a bidirectional protocol, so once a connection has been established between the client and the server, communication may proceed. The client must implement the following commands on the stdin file stream: Here is an example of how clients in a session would work: In this section, a client is only allowed to join one session. If so, the server should check whether a client has been in one session or not. Client 1: 1. Run the program: ./client 2. /login jill eW94dsol 5000 3. /createsession lab_help Client 2: 1. Run the program: ./client 2. /login jack 432wlFd 5000 3. /list /* Returns a list of users and the sessions they joined */ 4. /joinsession lab_help 5. Hi Jill! This is Jack. How are TCP sockets different from UDP sockets? 4 Server Program (server.c): You should implement a server program, named server.c, in C on a UNIX system. Its command input should be as follow: server Upon execution, the server should wait for connections from the clients in the system. The server acts as both a conference session router and a database. For the database part:  The server has access to a client list with passwords (which can be hard coded into your program or kept as a database file).  The server should keep an up-to-date list of all connected clients in the system, as well as their session id, and IP and port addresses. The server should delete a conference session when the last user of the session leaves. The server should acknowledge some client requests (i.e. login and joinsession). You should deal with the possibility of a client attempting to log in with an ID that is already connected. The server implements the conference functionality of the system by forwarding messages intended for a conference session to all the clients registered for that session. This process should be transparent to the receiving clients. Section 2: Project In this section, more possible functionalities are suggested. You could design your own commands and implement them. Suggestion Functionalities: ● One client is able to join multiple conference sessions. ○ Client Program: if so, the client should clearly indicate on the client’s terminal the session ID of every message. ○ Server Program: the up-to-date list should be carefully designed. ● A client is able to invite other clients into a conference session. ○ Client Program: if so, you must provide a protocol for a client to either accept or refuse an invitation. ○ Server Program: the server should be able to forward the invitation and corresponding messages to the specific clients. ● Implement a timer with each client on the server side, to disconnect clients that have been inactive for a long time. Note that you do not need to implement all functionalities. You can either choose one or design your own functionality. You should provide a text file to explain design and implementation for your functionality. 5 Deliverables The following should be submitted and be available for your demo lab session:  The client and server programs. All code must be readable, with meaningful comments. If you use encryption for the passwords, make sure you use simple passwords and make them available separately.  It wouldn’t be a bad idea to have a set of meaningful test cases or scenarios, which will test most of the functionality.  Set of Makefiles and/or UNIX scripts that simplify the compilation.  The text file to explain Section 2. Notes  This lab is long so you should allocate a proper amount of time for finishing it.  For easy inspection, you may want to separate your code into more than two files; however you will neither be punished nor rewarded for this.  For electronic submission, only one person in the group should submit the file. You should create a tar ball (a2.tar.gz) with all the files needed to compile and run your programs. You should also include a Makefile in the tar ball that compiles all of your source code into two executables: one named server and one named client.  The following command can be used to tar your files: tar –czvf a2.tar.gz  Use the following command on the eecg UNIX system to submit your code: submitece361s 2 a2.tar.gz  You can perform the electronic submission any number of times before the actual deadline. A resubmission of a file with the same name simply overwrites the old version. The following command lists the files you have submitted: submitece361s -l 2  You are expected to explain the design choices made in your code to the TAs during your demo lab session. The lab specifications are similar to but different from those in previous years in subtle ways. This will make it easy to spot plagiarized code.