Viktor Dukhovni:
> On Mon, May 13, 2013 at 05:18:05PM -0400, Wietse Venema wrote:
>
> > The qmgr(8) concurrency scheduler limits the concurrency per nexthop.
> > That does not change when prescreen is inserted between qmgr(8) and
> > smtp(8) processes.
> >
> > For each nexthop:
> >
> > number of qmgr-prescreen connections + number of qmgr-smtp connections
> > <= concurrency limit
>
> Patrick does raise a valid new concern about the prescreen design.
Yes, I had some time to ponder over this in during the night.
Parallelization is easy enough for DNS which does not expire
immediately, but the number of TCP connections in progress must be
proportional to (but not necessarily equal to) the number of idle
delivery agents.
Suppose that we set aside a pool of 10 of the 100 delivery agents.
Then prescreen can safely have 10 connection requests in progress
(connection request here = DNS lookup, TCP handshake and receiving
the initial server response).
It can be a little smarter than that. It can group SMTP/TCP connection
requests by nexthop, effectively creating a connection request queue.
If a nexthop is quick, then its connection requests clear the
connection request queue quickly, so this queue could be given
favorable scheduling preference. If a nexthop is slow, then this
really wants a back-channel to the queue manager to provide selective
scheduler or queue-reader feedback of some kind.
This is a rough design.
Wietse
