~ubuntu-branches/ubuntu/maverick/postfix/maverick-security

algorithm are a) the option of less-than-1 positive feedback per delivery to

avoid overwhelming servers, b) the option of less-than-1 negative feedback per

delivery to avoid giving up too fast, c) feedback hysteresis to avoid rapid

it can correct for overload quickly.

 

SSuummmmaarryy ooff tthhee PPoossttffiixx 22..55 ""ddeeaadd ddeessttiinnaattiioonn"" ddeetteeccttiioonn aallggoorriitthhmm

            if (concurrency < 1)

                concurrency = 1

 

 

Discussions about the concurrency scheduler redesign started early 2004, when

the primary goal was to find alternatives that did not exhibit exponential

 

IImmppaacctt ooff aaccttiivvee sseerrvveerr ccoonnccuurrrreennccyy lliimmiitteerr

 

don't time out, but are rejected immediately with the Postfix server's

smtpd_client_connection_count_limit feature (the server replies with a 421

status and disconnects immediately). Similar results can be expected with

    variants, the defer rate decreases with increasing concurrency. See text

    for a discussion of results.

 

 

All results in the previous sections are based on the first delivery runs only;

they do not include any second etc. delivery attempts. It's also worth noting

  * The structures used by nqmgr

  * What happens when nqmgr picks up the message - how it is assigned to

    transports, jobs, peers, entries

  * How destination concurrency limits affect the scheduling algorithm

  * Dealing with memory resource limits

 

couple of messages was picked up, what is the relation between all those job,

peer, queue and entry structures.]

 

 

Having prepared all those above mentioned structures, the task of the nqmgr's

scheduler is to choose the recipient entries one at a time and pass them to the

except for the preemption, under ideal conditions - that is, no recipient

resource limits and no destination concurrency problems.]

 

 

As you might perhaps expect by now, the transport's job list does not remain

sorted by the job's message enqueue time all the time. The most cool thing

default_delivery_slot_cost parameter which is set to 5 by default. This is the

k from the paragraph above. Each time k entries of the job are selected for

delivery, this counter is incremented by one. Once there are some slots

delivered can preempt this job.

 

[Well, the truth is, the counter is incremented every time an entry is selected

already used some when it was preempted before (remember a job can be preempted

several times). In either case, we know how many are accumulated and how many

are left to deliver, so we know how many it may yet accumulate at maximum.

valid candidate for preemption. How do we choose among them?

 

The answer is - the one with maximum enqueue_time/recipient_entry_count. That

 

Now let's recap the previous two paragraphs. Isn't it too complicated? Why

don't the candidates come only among the jobs which can be delivered within the

how much it has yet to accumulate? If you found out the answer, congratulate

yourself. If we did it this simple way, we would always choose the candidate

with least recipient entries. If there were enough single recipient mails

and transport_delivery_slot_loan come from (they default to

default_delivery_slot_discount and default_delivery_slot_loan, whose values are

by default 50 and 3, respectively). The discount (resp. loan) specifies how

slots the current slot had accumulated so far.

 

And it pretty much concludes this chapter.