1. The program is ready to serve the requests immediately after it
has got started. The check of storages integrity during the
program's startup or reconfiguration procedure
made in the background and does not detain processing of the
customers' requests.
2. The elementary file system is chosen as a model for storing the objects cashed. I.e. the objects
are not stored in separate files, but in one or several big files (storages), representing the file
system within the file. Apart from the increase of access speed to the objects in such storage in
comparison with the storage of "one object - one file" type, it allows to create storages on block
devices. Unfortunately, it results in limitations on 32-bit systems, where the file size (to be more
exact: offset in a file) is limited approximately to 2GB. It does not mean the impossibility to use
storages with their capacity more than 2GB, just a necessity for use of several files will be faced
in such systems. This problem will be fixed soon.
3. Objects in the storage are indexed. Index is b-tree database, which allows finding the objects
with minimum time losses.
4. All operations on supporting storages (cleaning, expire), requiring blocking of access, are made
in the background with less priority. If there is a request, the blocking is removed as fast as
possible (the time of maximum delay can be configured and makes 1 second by default).
5. The program is written with the help of multithread technology. It certainly has both its
advantages and disadvantages.
The advantages are obvious: more simple program development, absence of the unforeseen
blocking, capability to use several processors on multiprocessors machines with appropriate
productivity increase.
Disadvantages: the platforms having pthread's are just supported; some difficulties with
debugging.
It is necessary to take into account that threads become more and more popular paradigm of
programming, so, I hope the disadvantages will absolutely disappear soon.
6. All the necessary operations are carried out within one program, no external demons (ftpget,
dnsservers, unlinkd).
- Stability of work is gained by means of thorough testing and debugging.
To find out the bugs of programming and memory leaks such means are used as "purify" and internal
checker of debugger dbx.
- Supported protocols: http, ftp, ssl-tunneling, icp v2.
- Configuration opportunities: several types of acl (unfortunately,
such abundance of acl observed in squid I haven't produced yet). For eg.:
group localusers {
networks 192.168/16 127/8;
badports [0:79],110,138,139,513,[6000:6010];
bandwidth 8k;
icp {
allow dstdomain * ;
}
http {
allow dstdomain * ;
}
}
group otherworld {
networks 0/0;
icp {
deny dstdomain * ;
}
http {
deny dstdomain * ;
}
}
Basically, all is obvious enough. These types of acl are enough for me; the necessary types can be
accumulated if required (on idea - by modules). Actually in latest versions Oops have large part of Squid
ACL's. Oops re-reads configuration files on a HUP signal. Meanwhile the current customer and server
sessions do not break. The new parameters concern only newly formed connections.