The c-icap project

Technical Information and Status

c-icap has been implemented as a multiprocessing/multithreaded server. In the future, both a classic fork-by-request UNIX server and a simple multithreaded server will be included in c-icap, and the user will be free to decide which better satisfies his or her needs.

The multiprocessing/multithreaded server works as follows. Initially, it starts a number of server processes (using fork) and uses a single process for monitoring. Each server process includes a fixed number of threads which perform the main operation.

A server process receives and serves requests as long as it has available threads. After the number of available threads is eliminated, another process starts serving requests. If the number of the available server threads decreases under a threshold value, the monitor process creates a new server process. On the other hand, if the number of the available server threads exceeds a threshold value, then the monitor process kills an idle server process. The monitor process continuously checks for available servers at short periods of time. This model ensures that there are always available servers while inactive resources are eventually released.

In UNIX, c-icap has been implemented by using POSIX threads, an IPC shared memory, and an IPC locking mechanism. However, there exists a less tested implementation, which uses POSIX semaphores and a file-locking mechanism for cross-locking between child processes and POSIX memory-mapped files for shared memory.

The server operates well, but there still exist some open issues: (1) a better signal management is needed, (2) child processes should be modified to release all reserved resources on exit, and (3) the communication between child processes should be improved.

The Antivirus ClamAV service

This service is under development. You should not consider installing it in a production environment. Currently there are the following options for clamav service:

• c-icap can configured to wait for all the data of the downloaded object received, then c-icap scan it and if a virus found then a page which informs the user returned. Otherwise the dowloaded object sent as is to the user's web browser. You can define the maximum size of downloaded objects.
• c-icap can configured to sends only a small percentage of the incoming data (e.g. 1% of the incoming data) that it receives, to user's client. When all the data has been received, they are scanned for viruses. If a virus found, no more data are sent to the user's web browser (but attention! maybe the virus contained in the data which c-icap allready sent to the user!). Otherwise the rest data send to the client.
  
• c-icap can configured to use a "viralator like" mode (look here for real viralator). In this mode the c-icap send's to the user's web client messages about the progress of download. After the download completed it sends a message with the web location where the downloaded file stored.

Win32 implementation

TODO

The current implementation lacks numerous features that need to be added. Some directions of future work are the following:

• Bugs correction and support of additional features of the ICAP protocol
• Implementation of a supper-module that combines functionality of multiple modules by user demand.
• Support of per-user configuration.
• Support of "configuration modules", which can read configuration parameters from sources different than flat configuration files.
• Support for statistics, and programming interface for statistics for use from services.
• Implementation of Perl and Java service handlers so that services can be written in Perl and Java.
• Creation of additional modules, mainly full antivirus and black sites list modules.
• SNMP support.
• SSL support.
• Full porting to Win32 using a native windows interface.