Functionality

When not using the daemon, does the sniffer queue up all incoming requests and then process them one at a time?

The following QA applies to verion 2 of SNF. Version 3 uses a client-server model, is fully multi-threaded, and each job is handled as a single request - not batched as described below for earlier versions.

The simple answer is yes. A more accurate answer is that the daemon periodically scans the workspace for jobs to do and will run through those jobs (in it's single thread) as fast as they can be scanned.

At the end of that "batch", the daemon _immediately_ makes another scan of the workspace and will process all of the jobs that are ready to process. This will continue as long as the queue does not stall. That is, as long as the daemon always finds at least one message to scan when it finishes it's current batch.

Under those conditions, the only overhead involved is that of creating a job file, locking and unlocking a semaphore file, and renaming the active job file to change it's state. This overhead is generally very thin. It would be thinner, except that file rename operations are not atomic- so the locking is necessary (especially on Winx machines).

If you discount the overhead then you could consider that each message is scanned as quickly as it can be, in turn, by a single thread. From that perspective, the only queue is that which is necessary for synchronizing the producer/consumer relationships between the clients and the server (daemon/persistent instance).

The situation changes as soon as a stall occurs. When the daemon scans the workspace and finds no jobs, it will sleep a short time. During this period, in theory, jobs will be queued for the next batch by the client instances.

When the queue is stalled for multiple cycles, the sleep period for the daemon is increased on each pass according to a natural spiral (Fibonacci sequence). This ensures that the daemon "plays well" with all of the other operations on the system.

Naturally, if either - there is no mail to process, or - the other processes on the system are very busy (perhaps receiving, sending, queuing mail, scanning w/ virus software, etc...) then SNF will patiently wait. When there is work to be done, however, SNF will move as quickly as possible to exhaust this work.

After the queue has been in a stalled state, and new work arrives, the sleep time is reset to zero again. SNF goes back into a real-time mode and in that mode there is no attempt to batch work - except to be as efficient as possible with it's directory scan.

-- to clarify that last bit, the earliest (purest) version of the persistent engine would stop at the first job file it found and would process that scan before looking for another job. This was terribly inefficient since it meant that the directory scan would have to start again from scratch when that job was finished. Almost immediately after that version was put into production, the directory scan operation was made "atomic" from the perspective of the persistent engine -- that is, all available jobs are collected during a single, complete directory scan of the workspace and that list of jobs is processed in sequence without delay.