dhiren.za.net

Standalone proxy server

Introduction

The standalone proxy server is being designed and built as a precursor to the distributed proxy server. The purpose of building a standalone server first, is to ensure that many of the components that will be needed for the distributed server can be designed, implemented and tested, without the complications that the distributed server will introduce. In this way, the standard protocols can be implemented and verified to be correct, and then imported into the design of the distributed server.

The standalone proxy server is very simple in design, especially since there are established protocols in place. It has a listener socket, which waits for clients to connect to it on a specified port. The server then authenticates the client. If the authentication is successful, the server then waits for the client to send a request to the server to connect to a remote server on its behalf. It also maintains a cache, and stores all cacheable content locally on the proxy server. When a client requests content that is cached, the server will check that the cached copy is still valid, and if it is, it returns the cached content instead of fetching it from the remote server. If the cached content has expired, it is replaced by fresh content from the remote server, and this is then returned to the client.

Thus, the server consists basically of the following components:
Socket library, providing means to accept client connections, and establish connections with remote servers
Authentication library, providing support for the authentication methods required by the SOCKS protocol, as well as possible custom authentication methods
Cache manager, which determines whether content from a remote server is cacheable or not, and maintains the files in the cache.

Socket Library

The socket library need only provide efficient handling of client and server sockets. Because the SOCKS protocol does not specify a requirement for SSL support, it is be assumed that clients will not initiate an SSL connection with the proxy server directly, although it might request the proxy server to negotiate an SSL connection on its behalf. The only client-proxyserver encryption explicitly specified is GSS-API, which is required for complete SOCKS compliance. Since GSS-API is required for authentication as well as data protection, the implementation of GSS-API is probably best not placed within the socket library, but in a separate authentication/encryption library. Since the proxy server will only act as a pass-through for SSL connections, the networking library does not require any SSL capabilities itself.

Basically, the socket library will need to be able to create and maintain a large number of connections to remote servers on clients behalves. Also, it will need to listen for and maintain a large number of connections from clients. Each socket will have a unique socket ID, which other modules can use to read from and write to the socket. Thus, other modules only need to associate a list of socket ID's with each client connection. The socket manager will manage the mapping of socket ID's to actual socket connections, so other modules need only interact with the socket manager, and not with actual socket objects.

Authentication Library

The SOCKS protocol requires that compliant servers must support GSS-API authentication, and should support username/password authentication. The authentication library will provide an extensible framework to allow for any number of other authentication methods to be added to the system to allow for expansion and the addition of proprietary authentication protocols.

The authentication library will handle all aspects of authenticating the client. If authentication requires further messages to be sent between client and server, the authentication module will manage all of them, via the socket manager. Because GSS-API can be used not only as an authentication protocol but also as an encryption protocol, a separate encryption module will be provided, which both the socket library and authentication library can hook into, as it is plausible that other authentication methods might support encrypted data transfer as well.

Cache manager

The cache manager is responsible for all cached content on the proxy server. When a client requests a file from a remote server, the request is passed directly to the cache manager. The cache manager first checks if the file is cacheable or not. Some filetypes can be configured to never be cached. In this case, it requests the file from the remote server and passes it to the client without storing it. If the file is cacheable, it checks if there is a local version in the cache already. If there isn't, the server requests the file from the remote server. If there is a copy already in the cache, it contacts the remote server and asks for the header of the requested file. It compares the header information from the remote server with the header information stored for the cached copy. If the cached copy is still valid, it is send to the client. If it is outdated, the server requests the updated file from the server and replaces the cached copy with it. The cache manager transmits data to the client as soon as it begins receiving it.