CS87 Lab 2: Client/Server Chat Programs

cs87talk.[c,h]: definitions used by both the client and server, and common functions used by both the client and server side should go here. For example, both the client and the server send and receive messages on sockets. I recommend adding some generic message sending and receiving functions here, functions that will be used by both your client and server code.

server.c: the server side should be implemented here (there is a lot of starting point code for you in here)

client.c: the client side should be implemented here (there is a lot of starting point code for you in here)

Makefile: builds client and server executables (cs87_client, cs87_server).

README.adoc: some notes to you about code.

Up to NAMEMAX bytes (chars) can be sent in the data part of a HELLO_MSG message, and up to MSGMAX bytes can be sent in a MSG_DATA message. You can use these constant definitions to allocate message buffers to handle any size message one time in your program vs. on mallocing and freeing buffer space on every message send/received. (NOTE: your message buffer may be larger than these sizes in capacity…​read on).

The bytes sent in the data part of MSG_DATA and HELLO_MSG should not include the final null terminating character (\0) of a string. However, the null terminating character needs to added before printing out the message as a string.

You can use the same char buffer to receive the message and to construct its resulting string. For example, in the server you can do this by receiving the MSG_DATA data bytes starting after the "name : " prefix at the start of the buffer--the message buffer can be larger than MSGMAX chars, and then adding the null terminating charater to string-ify the result. It is okay to use one buffer for receiving the message bytes and another to construct the string to print, but using just a single buffer for both is more efficient. In either case, you should not malloc and free message buffer and the resulting message string space on every message send and receive.

The server may need to truncate a message it receives when it produces the resulting string to print out (Part 1), or to send to other clients (Part2) in order to ensure that the message’s total length is at most MSGMAX bytes. For example, if the client sends the server a message of len MSGMAX, the server should receive all MSGMAX bytes of the message, but the server will then have to truncate off the last "name: " characters of the message in the resulting string that is printed out (Part 1) or sent to other clients (Part 2); it is important that the server (and client) can receive a full MSGMAX sized message, but the server may need to truncate off some characters at the end when creating the resulting string from the message bytes it receives.

The server allows multiple clients to be connected at once.

The server is no longer a participant in the chat: it just facilitates some number of clients to have a group chat: the server doesn’t read in input from a user, nor does it echo any of the messages it receives from clients. Its only output should be a printing a message when a new client enters the chat and printing a message when a client leaves (or a connection ends).

The server must be multi-threaded: on each client connection (accept), the sever should create a new thread dedicated to that connection; when the client quits, the thread should clean-up any server state associated with its client, and then this server thread should exit.

The main server thread, after an accept and creating a worker thread dedicated to the new connection, should go back to the main accept loop, ready to accept a connection from another client.

The server should accept no more than 5 simultaneous client connections. If there are 5 clients connected and a new one tries to connect, the server thread should reply HELLO_ERROR to this client and terminate the connection with this client. When a connected client leaves, then the next connect request should succeed. #define some constant for this max size (5), and use it in your code.

When a server thread receives a message from one of its clients, it will send the message to all other clients.

The client should be multi-threaded with 2 threads:

Clients can connect and disconnect at any point

Clients can send messages whenever they read in a line entered by the user: there is no message ordering among the clients.

I have some Socket Programming Links.

The Steven’s Unix Network Programming (2nd Edition Vol. 1). Chapters 3 and 4 are very helpful. We have a couple copies of this in one or more CS Lab spaces. Please don’t remove these from the CS labs.

You should use send and recv to send and receive messages on sockets.

ret = recv(sock, &(buf[i]), amt_left, 0);

set sockopts on the listen socket: SO_REUSEADDR and SO_LINGER. If you set the sockoption SO_LINGER to off, then the socket will close immediately upon a process exit (This is done for you already in the starting point code, just understand what it is doing and don’t remove it):

  struct linger linger_val;

  linger_val.l_onoff = 0;
  linger_val.l_linger = 0;

  setsockopt(sock_fd, SOL_SOCKET, SO_LINGER, (void *)(&linger_val),
            (socklen_t) (sizeof(struct linger));

Read the man pages for system calls like socket, connect, accept, listen, send, recv, etc.

man 2 socket

use perror to print out error messages from failed system calls:

int *sock_fd;

sock_fd = socket(AF_INET, SOCK_STREAM, 0);
if(sock_fd == -1) {
  perror("socket create failed. Exiting\n");
  exit(1);
}

run /sbin/ifquery eth0 to get your own IP address.

$ /sbin/ifquery eth0  # look at the address entry for the IP address

nslookup or dig to get another machines IP address

$ nslookup lime
 Address: 130.58.68.165

$ dig +short lime.cs.swarthmore.edu
 130.58.68.165

Chapter 2 of Dive into Systems covers C programming, structs, arrays and strings, pointers, pass-by-pointer parameters, switch statment, dynamic memory allocation, and more. And here are some other C programming references.

readline library. You can use readline to read in messages entered by the user in the client. It is possible that the user types in a message that is too long to send in a MSG message. In this case, truncate the entered message to the max size that will fit.

fflush: to force printf to output printf output is buffered and may not show up to the terminal until the program has executed many instructions past the printf stmt. To force printf output to stdout, you can call fflush:

printf("hello there");
fflush(stdout);    // force all buffered printf output to stdout

valgrind and gdb guides. Also see Chapter 3 of Dive into Systems on debugging C programs.

Chapter 14 of Dive into Systems covers pthread programming.

Links to other pthreads documentations and tutorials off my help pages.

Some tips for debugging pthread programs, or debugging pthread programs from Dive into Systems chapter 3, and more details here: guide for using gdb to debug pthread programs.

my help pages includes other links to Unix, C, pthreads, networking resources

Dive into systems(C programming, and Appendix 2 on Using Unix)

CS department help pages

man pages for C library, pthreads library, and TCP/IP socket functions.

Tools for examining system and runtime state top and htop to see what is executing on client and server side

make and writing Makefiles

some useful tools vim, ssh, scp, tmux, finding idle machines, latex, git, …​

git help page