CSC209 Assignment A4: Network Programming - Friends Server
Assignment A4: Network Programming
Introduction
In this assignment, you will implement a network version of the friends program that we wrote for assignment 2. You will write a server to which clients can connect and issue friends commands. You will not write a client. We recommend that before you start this assignment, you complete the week 10 lab. You will probably also find the week 11 lab material helpful and may want to complete it early. (The material required for the week 11 lab was included in the week 10 PCRS prep.)
Your Ports
To avoid port conflicts, please use the same port numbers as you use for the week 10 lab. You should also make sure to add the following lines to your server code so that the port will be released as soon as your server process terminates. int on = 1; int status = setsockopt([sock_fd], SOL_SOCKET, SO_REUSEADDR, (const char *) &on, sizeof(on)); if (status == -1) { perror("setsockopt -- REUSEADDR"); }
Playing Around
Before detailing your tasks, let's explore the friends server to get an idea of how it works. On wolf.teach.cs.toronto.edu port 8888, we have a friends server running. To connect to it, first ssh into teach.cs, and then type the following at the shell: netcat -C wolf.teach.cs.toronto.edu 8888. (Only the teach.cs machines are allowed to connect to this server.) This runs a program called netcat to connect to the demo server. Once you've connected, you'll be asked for your user name. Type a name (that does not contain a space) and press Enter. User names may not contain whitespace characters.
Now the server is ready to accept friends commands. These are similar commands as those from A2, but they are not identical. There is no longer an update_pic, a delete_user or an add_user. If you provide a new user name (never before seen by the server) at the time you connect, the server will create a new user, but if a user by this name already exists in the friends data structure, it will assume that you are this user. No users are ever deleted from the data structure. Some of the remaining commands have also changed to require one fewer parameter since one of the users involved in the command is assumed to be you.
list_users Displays the usernames of all users in the data structure. These users are not necessarily connected at this time. make_friends username Makes a friendship between the current client and username. Friendship is symmetrical. post target msgpiece [msgpiece ...] Posts this message to user target from the current client. profile username Displays the profile of this user. quit Disconnects from the friendme server.
Try running some of the commands see the behaviour of the server. After you have run a few commands, open up another terminal and connect to the friends server from there too. Choose a different client name and then make friends with the user you created earlier and make a post from each of the users to the other. Notice that when a post is made, friends server notifies the client that has the same name as the target of the post and adds the post to the profile.
Open yet another terminal window and connect. This time give a name that is longer than 32 characters.
Notice that the server truncates the name to 31 characters and then goes ahead and uses that truncated name (to either create a new user or to connect to a user with the truncated name). Assuming you still have two or three clients connected, mess around with friends commands, understanding that the actions of one client are seen when others list users for example.
While you still have at least two clients connected, start typing a command in client 1, then switch to client 2 and type a command: you'll notice that the server responds to client 2; it uses select to avoid waiting for any particular client, and uses separate buffers for each client so that client text is maintained independently.
When you're finished, use ctrl+c to kill your netcat process(es). The quit command will tell the server to disconnect the client, but it won't close your netcat process.
The server keeps all of its data about clients and friends in memory (rather than writing information out to files.) This means that once the server is killed, all friends and user information is gone. We will restart the sample server on teach.cs periodically to keep the size of the data structure reasonable so you may find that a user name you used previously is no longer recognized by the server.
Your Tasks
You are required to implement a server that works like the sample server. You might like to work from your own A2 solution but we have also provided starter code for friends.h, friends.c and friendme.c that has a modified solution to A2. Some friends commands from A2 are not required here and we have removed the functionality from the starter code.
When you have questions about the behaviour required by your server, test the situation on the sample server. You do not need to worry about matching the output exactly (with respect to whitespace or numbers of dashes), but you must implement the same behaviour and the same messages. You may assume the following:
Users do not enter a user name that is an empty string or a user name that contains whitespace Users do not enter a single line (including the user name) that is longer than should define in your code
BUFFER_SIZE
which you
Other than these two, you should probably not be making assumptions. In particular, you can not assume a maximum number of possible users. You also must not assume that a user will run the quit command before they exit their client program or that a user will not stop to get a coffee in the middle of typing in their name. If there are other assumptions that you feel are necessary for your program to work properly, ask on Piazza or come to office hours and check with us.
Step 0: Makefile
The starter code we've provided only contains sample code implementing some of the functionality from assignment 2. You should begin this assignment by creating two new files: a friend_server.c file (with a stubbed main function) and a Makefile that compiles a program called friend_server. It must use the gcc flags -g , -std=gnu99 , -Wall , and -Werror . In addition to building your code, your Makefile must permit choosing a port at compile-time. To do this, first add a #define to your program to define the port number on which the server will expect connections (this is the port based on your student number):
ifndef PORT
define PORT
endif
Then, in your Makefile, include the following code, where y should be set to your student number port
plus 1:
PORT=
Now, if you type just use the program will be compiled with PORT defined as 53456. If you type , PORT will be set to y as defined in the Makefile. Finally, if you use gcc directly and do not to supply a port number, it will still have the x value from your source code file. This method of
make -D make PORT=53456
setting a port value will make it possible for us to test your code by compiling with our desired port number. (It's also useful for you to know how to use -D to define macros at command line.)
Step 1: Updating the friends.c code
Modify the list_users and print_user functions to return dynamically allocated strings in all cases. This means changing the signatures of these functions and changing their code. If you are using the starter code, you will also need to modify print_post in the same way. Some of these commands require a string to be created based on the nodes in a linked list. However, prior to looping through the list, you don't know how much memory to allocate for the string that you will build. If you are concatenating strings together, then one approach is to loop through the list twice: once to add up all of the string lengths, and again to copy those strings into a buffer of sufficient size. You may find snprintf and/or asprintf helpful. Read the man pages to see what header files and #define constants (e.g. _GNU_SOURCE ) you need to include to use these functions.
When the user types a command in the client, it will be sent to the server. The server will call the appropriate function, and will send a message back to the client to be printed to the user. All messages sent to the client need to end with the network newline ( \r\n ). The functions in friends.c should never print anything to standard out/error, except when calling perror
Because you are writing a server that can be accessed by malicious users across the internet, it is a requirement of the assignment that your code never overwrite the end of a character array. This means that when you use malloc to allocate memory for strings you guarantee to allocate enough memory to hold the strings to be stored. Since the user will be typing arbitrarily-sized user names, friends names and comments, you will often have to check the size of the input before allocating memory. Allocate only the memory that you need.
Although you do not need to submit it for marking, it is a wise idea to check your changes to friends.c by modifying the friendme.c starter code to so that it works again after you have made the required changes to your functions. For example, instead of
if (strcmp(cmd_argv[0], "list_friends") == 0 && cmd_argc == 1) {
print_friends(friends_list);
}
you might have something like
if (strcmp(cmd_argv[0], "list_friends") == 0 && cmd_argc == 1) {
buf = print_friends(friends_list);
printf("%s",buf);
free(buf);
}Be sure that your changes to friends.c work properly before you move on to the next step!
Step 2: Build the server so that it works with one client
Write the friend_server.c code so that you can have one client writing friends commands to the server. When you run the executable it should not take any command-line arguments. You will want some pieces from friendme.c (either your own solution or the new one we have provided), but you should remove sections of code that are no longer needed. Take advantage of example socket code that you have been given (including source code from the PCRS videos, lectures, and labs.) When your client connects to the server, ask for and store their name. Then allow them to enter commands. Of course the commands aren't very interesting at this point without a second user for them to befriend or message. But before adding a second user, you should sort out how to handle partial reads.
Calling read on a socket is not guaranteed to return a full line typed in by the client, so you will need to keep track of how much is read each time and check to see if you have received a network newline which indicates the end of a command. (Section 61.1 in the Kerrisk textbook describes this in detail.) The lab from week 10 (https://q.utoronto.ca/courses/300838/assignments/985036) should also be helpful here.
Step 3: Support multiple clients using select
Change your server to be able to handle multiple clients. Design your own client struct to store the information that you need for each client - including a buffer to hold the partial reads. Since there is no upper limit to the number of clients, use a linked list data structure to store the client records. The server must never block waiting for input from a particular client or the listening socket. After all, it can't know whether an existing client will talk next or whether a new client will connect. And, in the former case, it can't know which client will talk next. This means that you must use select rather than blocking on one file descriptor. There will be a significant deduction if your code could block on a read or accept call.
Testing Since you are not writing a client program, the netcat tool mentioned above can be used to connect clients to your server. Your server is required to work in noncanonical mode (stty -icanon); we will test in this mode. For completeness, you might also wish to test in canonical mode (stty icanon). We won't explicitly be testing in this mode, but problems here might indicate unfounded assumptions in your server.
To use netcat, type netcat -C hostname yyyyy , where hostname is the full name of the teach.cs machine on which your server is running, and yyyyy is the port on which your server is listening. If you aren't sure which machine your server is running on you can run hostname -f to find out. If you are sure that the server and client are both on the same server, you can use localhost in place of the fully specified host name.
To test if your partial reads work correctly, you can set the terminal to send each character to the socket as soon as you type it, by running stty -icanon. When you want to go back to the normal line-buffered mode, type stty icanon at the shell to return the terminal back to canonical mode. If you don't do this, programs will work in unexpected ways. (For example, do a stty -icanon to get to noncanonical mode, then type cat. You'll notice that instead of waiting for full lines, each character is echoed by cat as soon as you type it.) When you are using non-canonical mode, characters get sent immediately to the server, so it is more apparent that the server is waiting to see a newline character before it processes the input.
What to submit
Commit all the files required to build your executable. That includes .h files, .c files, and your Makefile. Make sure your code compiles on teach.cs with the required flags using your Makefile with no target specified and produces an executable called friend_server .
Coding style and comments are just as important in CSC209 as they were in previous courses. Use good variable names, appropriate functions, descriptive comments, and blank lines. Remember that someone needs to read your code. You may write extra helper functions. You must perform errorchecking for all system calls (and functions which use system calls). We recommend defining a set of helper functions to wrap these calls to reduce duplication. Be sure to free all dynamically-allocated memory that is no longer in use. You do not need to write a signal handler to free memory still in use within your data-structure of clients at the point when your server is killed.
