Programming with Sockets

The purpose of this assignment is to acquaint you with using the socket system calls that perform network IPC between two host machines. Since all subsequent assignments will use CORBA, I want you to get a feeling for pros and cons of lower-level network programming vs. higher-level distributed object computing. In addition, this assignment will help determine if you've got the background to take this course.

In this assignment, you will write a simple WWW client, as described below. In brackets are some hints about what kinds of library and system calls you might want to look up to do these (see the UNIX manual pages and course references for additional details).

Please use C++ to write you application, and use OO abstractions whenever possible, but make sure that you access sockets via the C language APIs.


WWW Client

The simple WWW client program should do the following activities:
  1. From the command-line, read (1) the URL from which you can extract the name of the remote WWW server and the file to retrieve and (2) the server port number. Create a socket that is connected to the server machine at the specified port (e.g., HTTP port 80) [getservbyname, gethostbyname, socket, connect].

  2. Send a request to the WWW server using the HTTP protocol format. This will look something like this:
    
    GET /index.html HTTP/1.0\n\n
    
    Note that it's very important to include the two trailing newlines -- they are required by the HTTP protocol.

  3. Read all the data from the HTTP connection and write it to a temporary file created in your WWW cache (e.g., /tmp/yourloginname) on the local host [creat,read/write].

  4. Spawn an external viewer [fork/exec] to display the file. You can determine the type of viewer to spawn in two ways:

    1. Client-side file suffix -- The client can use the file suffix (e.g., *.ps should spawn ghostview, *.gif should spawn xv, an html file should spawn lynx, and a regular text file should spawn /usr/ucb/more, etc.). If the file is compressed (e.g., *.gz, *.Z, or *.zip) then uncompress it before viewing it.

    2. Server-side MIME content type information -- A more robust way to determine what type of the viewer to spawn is to utilize the Content-type: header returned by the server. For instance, the GET /index.html HTTP/1.0\n\n request from the client will return the following header:
      HTTP/1.0 200 Document follows
      Date: Wed, 11 Sep 1996 23:28:40 GMT
      Server: NCSA/1.5.2
      Content-type: text/html
      
      Your client can simply parse this information and use it to determine which viewer to spawn. BTW, this solution is the one used by WWW browsers, such as Netscape or IE.
The client should simply print out the appropriate error message [perror] and exit with a return status of 1 if any of the system calls fail to work properly. If everything works correctly, the program should exit with a return status of 0.


Comments

Although this assignment is fairly easy to describe, there are many subtleties involved in making it work correctly. In particular, you will need to understand many details such as network addressing, remote host identification, signal handling, process creation and termination, etc.


References

W. Richard Stevens, UNIX Network Programming, Prentice Hall, 1990.

W. Richard Stevens, TCP/IP Illustrated, Vol 3. Addison-Wesley, 1995.


Back to Courses home page. Last modified .