We start by defining a simple protocol that will allow the client to talk to the server. In network programming, the protocol is the language the client and the server use to communicate over the network. Examples of protocols include SMTP (sending mail), POP3 (fetching mail) and HTTP (the Web protocol). Most of these protocols have a similar format: the client sends single-line text commands indicating what they want, and the server replies with a code indicating error or success, and then maybe additional data. In our proxy protocol, there are only two commands: PROXY and QUIT. PROXY takes one argument, a URL to fetch, and returns the length of the document followed by the full text. A client can ask for as many documents as it wants, and then ends the session by sending the QUIT command. One good way to test a new network server is to telnet to the port on which it is running (here I am telnetting from a Solaris machine, jupiter, to an NT box named venus that is running the proxy server). These text-based, human-readable protocols let you act as if you are the applet client and see what the server does. Here's a sample session with the proxy server:

jupiter:kdowney: telnet venus 4005 Trying 172.16.20.5...
Connected to venus. Escape character is '^]'.

Applet HTTP Proxy Server 1.0, (C) WebConcepts, LLC, 1997
PROXY http://www.webconcepts.com
+OK URL fetched; data to follow
Content-length: 1314

....more follows

QUIT
+OK logging out of proxy server Connection closed by
foreign host. 

The server responds with one of two codes: +OK or +ERR, with the latter indicating a mistake (each is followed by a description of the error or what has been successfully done, such as +OK logging out of proxy server or +ERR unknown directive if you type something other than QUIT or PROXY.

Now that we know what we want our generic server to do, it's just a matter of writing it. The full source for the server is available for download; we'll look at the salient features.