The Architecture Of Traffic Control 3.1

This is a response to a question to a question we recently received.

Your traffic control looks like a very interesting approach, but there are
a couple of questions I have that your online documentation didn't seem to
answer:

1. One problem I have is that I'm using Apple XServes running OSX 10.5,
which has a hard coded limit of 2500 processes per server. I'm running Exim
which launches one process per email delivery. Does Traffic Control do the
same? If not (eg, it might use a thread per incoming mail connection), then
it could be very useful.

The architecture of the latest version of Traffic Control uses several processes. One process for management, one for logging and then several (default of 3) child processes that are single threaded processes. We have found this single threaded architecture is the most efficient way to handle large volumes of connections. Using mulitple child processes allows us to spread the work across several processors or cores and also allows us to continue processing and renewing processes if any problem were to occur. Also, this allows us to use very few persistent connections to your email server.

2. Does traffic control act as a pass-through SMTP proxy, or does it accept
email, then relay it. This makes a big difference to my rejection policy. I
like to reject at SMTP time, instead of accepting then possibly bouncing
email.

We do everything inline. We do recipient validation with your email server, and when we have fully accepted the email and it has passed all our tests it is passed to your email server. We then proxy back the response from the email server to the connecting client. Once again, this is done inline. This is very efficient since the load on the email server is usually vastly reduced due to the number of connections that are removed by our throttling and RBL checks.