CSE/EE 461: Introduction to Computer-Communication Networks, Autumn 2007
  CSE Home   About Us   Search   Contact Info 
 
Course Home
 Home
Administation
 Overview
 Using course email
 Email archive
 Anonymous feedback
 View feedback
 Homework Turnin
 
Most Everything
 Schedule
 
Information
 UW/ACM Tutorials
   

Homework 1.3: Socket Programming

Out: Wednesday September 26
Due: By class time, Wednesday October 3

Overview / Goal

This should be a refreshingly lightweight programming assignment. It has two main goals:
  • To make sure you have experience writing simple programs using sockets, as this could easily be useful in the future.
  • To make sure we're all able to use the systems (e.g., attu.cs.washington.edu) and languages (e.g., java) needed for the more involved assignments that are to come.

The program you'll write is very similar to the implementation given in Section 1.4.4 of the text, except (a) we're writing in Java, and (b) the functionality is very slightly different. In particular, you'll create a client and a server implementing a simple "request-response" protocol:

  • The server starts, creates a socket (in Java, a ServerSocket), and waits for a client to connect to it.
  • The client starts, creates a socket (in Java, a Socket), and connects to the server.
  • The client sends a one line, text message, and then tries to read a response from the server.
  • If the client sent "Hello", the server responds with "OK". If the client sent anything else, the server responds with "Huh?". In either case, the server closes its side of the connection and goes back to waiting for new client connections.
  • The client prints the response it got from the server and terminates.

If you're like me, programming in Java is mainly an exercise in scouring the API documentation to figure out how Java wants me to say the thing I perfectly well know I want to say. Below are some keywords intended to save you time dealing with this mind numbing activity.

Server Implementation Details

  • Put your code in Server.java.
  • The server creates (or is, if you prefer) a ServerSocket.
  • Reading text is probably most easily done in Java using a BufferedReader.
  • A PrintStream helps with writing text.
  • Whatever you use, the client and server implementations have to be compatible. For example, if you use the two classes above in the server, you'd be wise to use them in the client as well.
  • Don't hard code a server port number (as the book's implementation does). Instead, let the system pick one for you (as part of creating the ServerSocket). Once it's created, print the port number that was chosen - you'll need it to run the client.
  • The server should be invoked, and produce output, like this:
    $ java Server
    57024
    Deviation will certainly cause our scripted test procedures to report that your program failed.
  • Remember the distinction between "==" and ".equals()" when using Strings in Java.
  • The server stops running when it is killed (ctrl-C'ed). If that offends your sensibilities (and it should, at least a bit), implement some message that tells the server to terminate. (For example, if any client sends "Stop" the server terminates.)

Client Implementation Details

  • Put your code in Client.java.
  • The client creates (or is, if you prefer) a Socket.
  • An InetSocketAddress is used to name the destination for the connection. (This corresponds to struct sockaddr_in sin in the book's example client.
  • The client should be invoked like this:
    $ java Client attu2.cs.washington.edu 57034 Hello
    Failure to conform to that syntax will mean failure to pass any automated testing procedure we might use.

System Information

  • Unless you have a good reasons not to, use attu.cs.washington.edu for development and testing. No matter what, test your code there before submitting. Despite being portable, Java programs can fail to port (primarily because different systems might run different releases).
  • attu is actually four machines, attu1.cs through attu4.cs. You should explicitly login to one or two of those machines, so you know what machine your server is running on. (Telling the client to connect to attu.cs will have what seems like random results -- sometimes it will work, sometimes not.)
  • Run your client on one of the attu's, and your server on another.
  • If you lose track of which attu a window is running on,
    $ echo $HOSTNAME
    will tell you.
  • Write the server first. You can then test it using telnet:
    $ telnet attu2.cs.washington.edu 57024
    Hello
    OKConnection closed by foreign host.
    $ telnet attu2.cs.washington.edu 57024
    Hi
    Huh?Connection closed by foreign host.
    (You might not see what you type printed on your screen; don't worry, that's just a telnet detail.)

    Once the server appears to be working, writing/debugging the client will be easier.

Turnin

You'll hand in the two source files, as part of the full turnin for Homework 1. Details to be determined.

Computer Science & Engineering
University of Washington
Box 352350
Seattle, WA  98195-2350
(206) 543-1695 voice, (206) 543-2969 FAX
[comments to zahorjan at cs.washington.edu]