6.894 Lab 2: A TCP Proxy Server

Due date: Thursday Sep. 28 Don't wait until the last minute.

New! Test your tcpproxy before turning it in

Download the tar file of tcpproxy tester here. To compile it, type the following in the untarred directory:

% ./configure
% gmake (on athena, you must use "gmake" to get it working)

To run the program, type:

% ./test-proxy "location of your tcpproxy"

Your program should pass all phases of the tests. We will have a growing list of Q&A regarding the test.

In this lab you'll write a TCP Proxy using the same C++ asynchronous library as in the first lab. You'll learn how to write both client and server code in this lab. (For students who have taken 6.033 lab before, you will be doing the same lab, because now we require you to make use of async library and hence your code should be very different. :-))

A TCP proxy server is a server which acts as an intermediary between a client and another server, called the destination server. Clients establish connections to the TCP proxy server, which then establishes a connection to the destination server. The proxy server sends data received from the client to the destination server and forwards data received from the destination server to the client. Interestingly, the TCP proxy server is actually both a server and a client. It is a server to its client and a client to its destination server.

A TCP proxy server can be useful to get around services which restrict connections based on the network addresses. For example, there are many servers at MIT which will only serve data to addresses within the MIT network. By running a proxy server on the MIT network, clients from outside MIT can use those servers by connecting through the proxy server. The MIT servers will think they are serving data to a machine on the MIT network (namely the proxy server machine) and they'll be right. However, the proxy is forwarding the data out of the MIT subnet, thus subverting the protection mechanism. This is a violation of the rules of use on most of those server, so we do not encourage you to do this.

The proxy server you will build for this lab will be invoked at the command line as follows:

% ./tcpproxy destination-host destination-port listen-port

For example, to redirect all connections to port 3000 on your local machine to the MIT web server, do:

% ./tcpproxy web.mit.edu 80 3000 &

The proxy server will accept connections from multiple clients and forward them using multiple connections to the server. No client or server should be able to hang the proxy server by refusing to read or write data on its connection. For instance, if one client suddenly stops reading from the socket to the proxy, other clients should not notice interruptions of service through the proxy. You will need asynchronous behavior, described in "Using TCP Through Sockets".

Additionally, if the client-side or server-side connection with tcpproxy hangs for more than 10 seconds, the corresponding connection pair must be terminated.

Testing

You should test your proxy to make sure that it continues to forward data even when some connections aren't responding. Here's one test you should be able to pass.

First, run the proxy and point it at amsterdam's HTTP port:

athena% ./tcpproxy amsterdam.lcs.mit.edu 80 1234

Now, in another window, use telnet to fetch /~rtm/BIG through the proxy:

athena% telnet 127.1 1234
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
GET /~rtm/BIG

Watch the data go by for a while, then interrupt the output by typing control-], after which telnet should stop and print telnet>. Now check that the proxy hasn't been hung because telnet isn't reading data; open another window and fetch something else:

athena% telnet 127.1 1234
Trying 127.0.0.1...
Connected to localhost (127.0.0.1).
Escape character is '^]'.
GET /~rtm/ok
You were able to fetch the data.
Connection closed by foreign host.
athena%

If you see "You were able to fetch the data," your program passes the test. Otherwise something is wrong.

How/What to hand in

September 28 - TCP proxy

For this program, you have to install the asynchronous library and have a Makefile for all your programs.

install asynchronous library.
You need to reconfigure your package and install asynchronous library. For example, the following command installs asynchronous library to sub-dir libasync under your home directory ( you may choose to install it in a different directory though, but then you must remember to change the sample Makefile we give you to reflect the change):
```
% ./configure --prefix=$HOME/libasync  
% make install
% cp autoconf.h $HOME/libasync/include/6894-0.1
```
copy the following sample Makefile to your lab2 working directory (it could be anywhere) and rename it as Makefile.

Hand in your lab by creating a tar file with all your source files (and Makefile), uuencoding it, and e-mailing it to 6.894-submit@lcs.mit.edu. For example:

% tar cf lab2.tar tcpproxy.h tcpproxy.C Makefile
% uuencode < lab2.tar lab2.tar | Mail -s '6.894 lab2.tar' 6.894-submit@pdos.lcs.mit.edu

For students working on athena, type the following instead:

% tar cf lab2.tar tcpproxy.h tcpproxy.C Makefile
% uuencode < lab2.tar lab2.tar | mhmail -subject '6.894 lab2.tar' 6.894-submit@pdos.lcs.mit.edu

Please don't send attachments in your email submission. If you cannot submit, email jinyang@lcs.mit.edu for help. :-)

We must be able to compile your software with our standard async library, so don't modify the async library.

The lab is due by the beginning of class on Thursday, September 28th.

If You Are Curious...

Here is a question for you to think about if you are curious:

While the asynchronous library provides callbacks for handling asynchronous network connections, programmers still need to be aware of blocking conditions by checking the return value and error number after each I/O system call. Can you think of an implementation that hides asynchronous I/O from the programmer? What would be an advantage or disadvantage of this new implementation?

References

The following books are useful:

Stevens, W. Richard. Advanced Programming in the UNIX Environment. Addison-Wesley, 1992.
Stevens, W. Richard. Unix Network Programming. Addison-Wesley, 1990.