Development of the Armenian Regional
Academical Cache Service

Arthur Petrosyan (arthur@sci.am)
 Institute for Informatics and Automation Problems of the
National Academy of Sciences of the Republic of Armenia

Outline:

Introduction
Independent Armenia obtained new opportunities for the development of sciences. But hard economic situation, blockade and energetic crisis did not allow scientific organisations to use the full opportunities of having international contacts and to participate in international projects. Only connection to the Internet stimulated the activity of scientists in Armenia. There were also difficulties with creating and supporting a reliable connection. Local telephone lines, that are the only prevailing connection means, were (and still are) in a pity state.

In 1994 the group of specialists in the Institute for Informatics and Automation Problems (IPIA) of the National Academy of Sciences of the Republic of Armenia (NAS RA) attempted to create a communication between some Scientific and Research Institutions of NAS RA. The Institutions were located in Yerevan (capital of Armenia) and in other cities of Armenia. After several tests wireless connection methods were selected as the main communication means for both inter-city connections as well as for connections within the Yerevan city. Next step was organising connection with other main scientific and educational centers such as Yerevan State University (YSU), State Engineering University of Armenia (SEUA), etc. Created Armenian Academical Scientific and Research Network now connects, more that 30 scientific and educational organisations. In addition to radio-links we use also cable and dial-up telephone connections. At present our network is used by hundreds of users and includes many servers and workstations. Together with the creation of our scientific academical network some commercial and governmental organisations also worked on the creation of their own networks and as a result several independent regional networks are existing in Armenia. This created problems of communicating from one such network to another, because each may have its own Internet connection and no inter-connection with other regional networks. Thus the route from one to another regional network in Armenia may lead through the whole Internet. An important step we achieved in our network was the inter-connection with all other regional networks in Armenia that solved most such problems. In addition we now use 2 different Internet connection channels (i.e. 2 totally different access points to the Internet).

Caching in the our regional network
As our network was enlarging, the usage of the Internet grew and we started to think how to minimize the cost of Internet traffic, because international connection to the Internet is still a very expensive resource. Caching seemed to be a good idea and we started experiments with caching in 1997.
Up to now we have 3 Cache servers already installed and operating. And 3 others are being prepared (see Fig.1). All Cache servers are based on SQUID Internet Object Cache (Squid 1.1.*) software. The hardware used for each cache server is: Pentium 166Mhz, 32RAM, 1Gb disk space for cache. For our network this is currently more than enough.


Figure 1

Development of the Armenian Regional Academical Cache Service (DARACS). |large image|

Any machine connected to our regional Armenian Academical Scientific and Research Network is free to use all internal resources of our network, but only few hosts have a direct access to the Internet. These are primarily various servers (Mail, WWW, DNS, FTP, etc.). In this situation of limited access to Internet the use of proxy servers, which will simultaneously do the caching was very beneficial.

Local developments
Specific local needs led to the development of user access tools for Cache Proxy servers. It was necessary to control the Internet traffic on per-user basis, rather than on per-host basis.
We made it possible by organizing a so-called proxyuser concept. A person to whom Internet access is to be granted gets its own username and password. For such proxyuser we define a list of hosts from which he is allowed to work with Cache server (so called "allowed hosts"). Before using a Cache server a person runs a Web browser from one of his "allowed hosts" and goes to a special Registration Web page (see Fig.2) where he completes the registration form by entering his Proxy Username and Password (see Fig.3). After authentication checks that host is allowed to use Cache server (i.e. Cache server starts accepting the requests from that IP-address). When a person has finished browsing Internet he is obliged to close the access to Internet from that host by doing the same procedure (going to the Registration Web page and completing another form that denies the use of Cache server from that host).
In addition the proxyuser can use the special form at the same Registration Web page to change his password and also can see his personal traffic.


Figure 2


Figure 3

How all this works
As it is known, access control mechanism (ACL) in Squid configuration (squid.conf) defines a list of hosts who can access that Cache server. Once you have included a host in an ACL list you need also to give it a permission to use your cache (adding a http/icp/miss_access entry for that host). There is also a possibility to use redirector program for rewriting requested URLs. Configured to work with redirector Squid passes every incoming URL, before processing it, through that external redirector program. We are using 'Redirector' package written by Iain Lea (iain@sbs.de) that allows additional special configuration file (acl-client.conf) where you can specify hosts for Intranet (restricted) or Internet (full) access with ability to deny or redirect some URLs.
Using all this we are listing in squid.conf the range of host from which we want to accept Web-browser's requests at all (we do this by adding ACL and http_access TAGs in squid.conf). Generally this would result in accepting requests from any of that hosts anytime. But because our Cache server is configured to user 'redirector', there is also one step to pass - redirector's permission. This way if the host listed in squid.conf is not listed in additional acl-client.conf file it will not be able to use Cache server.
The registration process described above is accomplished by CGI-script that check proxyuser's permissions and if everything is ok adds the IP-address of the host from which Web browser runs to acl-client.conf file. This opens the access to Cache server from that host, we just need to causes the Squid to re-read acl-client.conf file (by sending 'HUP' signal). The reverse procedure of closing the access to Internet from that host does the similar CGI-script.
All registration/removal operations are logged. This way it is possible to have a period of time when a specific proxyuser worked from some host. This allows counting traffic on per-user basis even if one proxyuser worked from different hosts.
The appropriate CGI-script counts the traffic in the following way: for each host from which the given proxyuser worked we count only the traffic, which was downloaded from that host during the period when it was used by that proxyuser. Then we have to sum all this up and the result will be the total personal traffic of a given proxyuser.

Plans for the future
Our future plans are: