Unix Systems Programming: Lab 8 - Unix Sockets

Purpose and Rationale

The purpose of this lab is to allow students to become comfortable with Socket programming.

Resources

If you are not in our course email list, please subscribe to the cspp51081 email list here:
        http://mailman.cs.uchicago.edu/mailman/listinfo/cspp51081
You will also find the course FAQ containing useful information for this assignment.

Lecture 8 is the primary source for information on programming Sockets. You can find additional information in the manpages, online, as well as the following sources:

• Kerrisk,  The Linux Programming Interface, Chapters 56-61
  
• Molay, Understanding Unix/Linux Programming
  • Section 11.5 is an introduction to setting up a socket connection, from the server and client side.
  • Chaper 12 provides a thorough example of using a socket in making a webserver.
  • Chapter 13 gives an example of setting-up a socket using a datagram socket (UDP protocol). The earlier references set-up a stream socket (TCP protocol.)
• Several helpful online resources were provided in the lecture. These can be found at FAQ

Marks Distribution

Sockets Programming

Background

Sockets enable processes connected over networks to communicate with one another. The socket interface allows for a standard set of function calls that hide some of the details of the underlying networking details from the programmer. We probably use sockets every day, you've used one to look at this web page (http connections are typically made as a socket connection to port 80 on a server). They are used for simple tasks such as public chat rooms and for complex tasks such as massively parallel super computer intercommunications. Here is a nice socket tutorial with code examples.

Project

One common use of sockets is to facilitate a distributed workload system such that a slow client machine can make a computationally intensive request of a faster server machine via the network and sockets (in fact, this forms the basis of RPC concepts). The goal of this project is to write both a client and a server that together create such a system. The program flow could resemble the following:

1. The client will request the input of a word from the user via stdin.
2. This word will be transferred to the server over a raw socket connection.
3. The server will check the word for proper spelling and return a response that the word was spelled correctly, or a response that the word was spelled incorrectly.
4. The client will then display a formatted result of the server's response to the user. For example, a message stating, "The word --- is spelled correctly." or "The word --- is spelled correctly."

The server must take the port number that it will be listening to as a command line argument. The client must take the name of the server machine and the port number to connect to as two command line arguments. On the server side, you may use the file /usr/share/dict/words on CS machines to look up the correct spelling of user input. This means that a word not found on the list will be considered to be incorrectly spelled.

Additionally, your server will send a short list (no more than ten, but possibly none) of alternative spellings, if the word provided by the client does not appear in the list of words you searched. The new protocol will be

1. The client will request the input of a word from the user via stdin.
2. This word will be transferred to the server over a raw socket connection.
3. The server will check the word for proper spelling and return a response that the word was spelled correctly, or a response that the word was spelled incorrectly. If the word was not spelled correctly, the server will search for alternative possible spellings. These alternatives will be passed to the client.
4. The client will then display a formatted result of the server's response to the user. For example, a message stating, "The word --- is spelled correctly." or "The word --- is spelled correctly." In this latter case, the client will display a short list (no more than ten) of alternative spellings provided by the server.

One heuristic for choosing alternative spellings (suggested in class), is to look for all words contain exactly the same consonants, in the same order, but considers vowel alternatives. A simple way to do this is to form a regular expression from a word, replacing each vowel with '[aeiou]?'. You may consider more elaborate alternatives. It is possible that there are no alternative spellings found. This should not happen too often though. Your heuristic should be able to provide the correct spelling for words like "booot" and "recieve".

Deliverables

Carefully follow the 5 steps below.

1. Create a directory:
         lab8
2. You will have one directory to store your assignment:
• ex:    If you are submitting the exercise
  
3. This directory will contain:
   • All C files needed to build your client and server.
   • A file named Makefile, which will build both your client and server, when make is entered on the command line. In addition, your make file must contain a target clean which will remove all executables created by make when make clean is entered on the command line.
   • A README text file which explains what your server does for a client. You must also include an explanation of what heuristic you used to provide alternative spellings.
   • There should be no object files or executable files in your submission. Please make sure that all back-up files generated by emacs (*~) are removed.
4. When you are finished with your directory you will create a compressed archive file using tar (this utility stores your directory as a single file, then compresses its size.)
          tar -czvf   username.lab8.tgz   username.lab8
   


5. You will email your file to our TA as an attachment. He will send an acknowledgement that your assignment has been received.

To	Nicholas Flees (nickflees@uchicago.edu)
Attachment	username.lab8.tgz
Subject	CSPP51081-lab8