CS87 Lab 2:

Part1, checkpoint: before 11:59pm, Wednesday Sept. 22 push to git repo and tag with Part1 tag.

Part2: before 11:59pm, Wednesday Sept. 29 push to git repo and tag with Part2 tag.

Learn socket programming by implementing two versions of a TCP socket client-server program.

Implement a specific message protocol, and test correctness by seeing that your client/server can communicate with other group’s server/client.

Gain more practice with pthreads multi-threaded programming and synchronization.

More practice with C programming, C strings in particular.

The Part 1 version: allows for one-at-a-time chat session between a single client on one machine and a single server on another machine. When the current chat session ends, another client can connect to the server end and start a new chat session. The client and server alternate sending messages back and forth (in a question and answer type style).

The Part 2 version: allows for a chat session between multiple clients. In this version the server does not participate in the chat itself, but fosters allowing multiple clients to connect to the chat session. Clients participating in the group chat send their message to the server and the server shares it with all of the other clients participating in the chat session. In this version, clients can "speak" at anytime; there is no specified ordering or taking turns writing messages to the group. Individual clients can also come and go in a chat session.

HELLO: a client introduces itself to the server before talking. The server will tell the client if it can join the chat or not as part of this exchange.

MSG: an endpoint will send a message to another endpoint. A client can send a MSG to a server and a server can send a MSG to the client.

QUIT: a client tells a server it is done and leaving the talk session.

Use the TCP sockets client-server connection protocol. Here is a picture of the TCP client-server connection protocol:

Write your solution in C, using the starting point code.

Use the definitions in cs87_talk.h in your program. For example, use the type tsize_t rather than unsigned char, and use the #defines for message tags:

tsize_t tag;
tag = HELLO_OK;
ret = send(socket, &tag, sizeof(tsize_t), MSG_NOSIGNAL);

For Part 1, the server should never reply HELLO_ERROR (in Part 2 this is a valid option for the server to return).

Make sure to close sockets when done or when an error is detected.

Your solutions should be robust. Check return values from all system calls, and handle appropriately.

Use send and recv functions to send and receive messages on the TCP socket. For recv the flags field should be 0, for send pass MSG_NOSIGNAL to avoid getting sent a SIGPIPE signal when the other end of the connection closes its end of the socket.

You should set the socket options SO_LINGER to off and SO_REUSEADDR on the server’s listen socket (see Tips and Resources).

Any message read in from the user that is longer than BUFMAX should be truncated before being sent (make sure a sender never sends a message greater than or equal to BUFMAX bytes). Similarly for the NAMEMAX limit.

You should define a struct on the server side for keeping track of a client’s information (this will be necessary for Part 2). The struct should minimally hold:

Because you are all implementing the same protocol, your client should be able to connect to another group’s server and have a chat. Your server should be able to accept a connection from another group’s client and have a chat-- all Part1 solutions should be compatable, and all Part2 solutions should be compatable. We will test this out in lab next week, but try it out with other groups in the lab as you work on this too.

Check return values from all system and function calls and handle errors. For system calls (like send, recieve, socket, etc.), you should call perror to print out an error specific message. Here is one example of how I might call perror and exit if a call to setsockopt fails:

int reuse_true = 1;
retval = setsockopt( listenfd, SOL_SOCKET, SO_REUSEADDR, &reuse_true,
                     sizeof(reuse_true) );
if (retval < 0) {
    perror("Setting socket option SO_REUSEADDR failed");
    exit(1);
}

When a new client connects to a group chat session, the server send all other clients a message saying that they have joined (like "Freya has joined the chat").

When a client leaves the group chat session, the server sends all other clients a message saying that the user has left the chat session (like "Freya has left the chat")

When a client sends a chat message to the server, the server sends the message to every other client except for the client whose message it is. For example, if Jo, Flo, and Bo are in a chat and Bo types in a message, the server sends Bo’s message just to Jo and Flo.

Add to the protocol a new message type for a client to ask the server for all the names of people in the chat session. The user on the client side would have to type in a specific string to trigger this protocol (like typing in "goodbye" triggers the QUIT protocol), this would send a specific message tag to the server that would have it send back to the client the names of all other chat members.

Add to the protocol a new message type for a client to ask the server to send it all of the last messages from each chat member. Again, the user on the client side would trigger this by entering some unique string to distinguish this request from a message to share with other clients in the chat session.

If you want to try to implement a solution with nicer looking output, you can try using the ncurses library to split the terminal window and direct stdin to one half and stdout and stderror to the other half (this is not trivial to do). You could also try something easier and print out stdout output in a different color if it is coming from the prompt printing thread vs. from the thread that receives and prints out messages from other clients forwarded from the server. Here is some information about ncurses: Cool C libraries