Programming Lab 2 CPS 196 Systems and Networks home calendar topics labs resources Program 2 - Java Networking Due: April 26 This assignment is broken up into a number of smaller pieces. You will only receive one grade for the entire lab, the smaller pieces and shorter deadlines are only to help you pace your work out. Assignment Goals To understand some of the fundamentals behind programming on network - sockets and the client-server model. To learn to design and implement a very simple networking program using the Java networking API. To understand some of the harder problems in distributed systems and the need for synchronization Background RFC 1925 - The 12 Fundamental Truths of Networking. Pay special attention to truth #5. In most cases, you will find all you need from the Java documentation. Check the resources page of the course web site, or the Java documentation on the web. You can also find many java tutorials and example programs on the web. You are free to use these resources as long as you understand what is happening. Further parts of this lab will require you to build on code you are writing now. Every client/server program is built in the same way. Some commonly asked questions are answered below. The server must already be running when the client wants to connect. The server "listens" on a particular port. This port must be known in advance to the client. In general, a single server program can serve multiple clients connecting to the same port. You will not need to do this for the first part of this lab, but you will in subsequent parts. Plan for it. You will need to write small test programs in order to give input to/get output from your program. I recommend also taking a look at telnet (man telnet). Part 1: Build a Trivial Networking Program You will be writing a "Channel Server" program in java. The channel server is similar to an echo server, but with one twist: you will be writing data to a different connection than the one you used to read from. Specifically, your program: Connects to a given IP address and port specified on the command line. Reads as much as it can from that connection. Waits for something to connect to it on port 4242 Writes everything it just read to the new connection and terminates the connection. Goes back to step one. Example usage:
$ channelserver 10.17.18.23 2442
Connected to 10.17.18.23 on port 2442
READ: The best diplomat that I know is a fully-loaded phaser bank.
Connection received on port 4242.
Written: The best diplomat that I know is a fully-loaded phaser bank.
Connection Closed
READ: Live long and prosper
Connection received on port 4242.
Written: Live long and prosper
Connection Closed
.
.
.
Notes You must read as much as you can from the IP address and port specified. You are free to define "as much as you can" any way you see fit. However, be prepared to defend your choice. Expect that a different client will connect to you every time. Be prepared to handle this case. You will need to write a testing helper program to feed data to your own program. Think about modifying your channel server to do this - it will save you a lot of effort. Use telnet to connect to your server and receive the data. Remember fundamental truth #1: It has to work! Further parts of the lab will be put up shortly. You can do this lab in either Java or C++. If you want to use another language, please clear it with Dr. Chase first. If you do choose to use Java, you will find it installed at /usr/research/pkg/j2sdk1.4/ To use this version, you must set your PATH and JAVA_HOME variables correctly. If you are using the default tcsh shell, add these lines to the end of your .cshrc file. If it doesn't exist, create it
set JAVA_HOME=/usr/research/pkg/j2sdk1.4/
set PATH=${PATH}:${JAVA_HOME}bin
The procedure if you're using Bash is similar, put these lines at the end of your .bashrc file
export JAVA_HOME=/usr/research/pkg/j2sdk1.4/
export PATH=$PATH:$JAVA_HOME/bin
Part 2: Threads and Bounded Buffers In this part, you will add a buffer to your channel server to avoid having to block on reads or writes. The motivation is as follows: If you wrote a simple single-threaded program in Part I, it probably looked like this: Open a socket and read in x bytes from a source Wait for someone to connect to you Send them the entire x bytes Repeat As you can see, this is not the most efficient way to handle network traffic. For instance, if a very slow reader connects to you, you will need to block while sending them the entire contents of the buffer. The basic problem is that it does not allow you to overlap steps 1 and 3, which are (generally) the most time-consuming parts of a network program. In this part of the lab, you will put the sending and receiving parts in different threads, so that one does not have to wait for the other. You might not see the advantage to doing so in such a small program, but think about a busy webserver. Serving client requests serially is a terrible waste of bandwidth. Your new program should satisfy the following requirements: One thread fills up a buffer if it is not already full by reading from a socket (This would be the same as step 1 in my hypothetical old program above) This thread MUST NOT wait if the buffer is not full Another thread that waits for a connection, then feeds it the contents of the buffer This thread MUST NOT wait if the buffer is not empty Notes Since you now have two independent threads accessing the same data structure (the buffer), you should think about synchronization. Java has plenty of easy ways to get synchronization working. Having a thread "wait" for a certain number of seconds (using sleep(), for example) is NOT an acceptable synchronization method. For the purposes of this lab, you are not required to accept multiple concurrent connections. However, the next part of the lab will require you to do so, along with a number of other changes. Try to plan for that. You are still required to be able to support different clients connecting to you every iteration, though. You may open and close connections as you see fit. Just make sure your test program can handle this. However, this is generally considered a bad idea. Try to minimize the number of unnecessary socket opens. You can find many good resources on multi-threaded network programs on the web.
