Matus UHLAR - fantomas:
> >Rodrigo Severo - F?brica:
> >> I think that this info - the delay between deliveries is per
> >> connection and not per, or only, per domain - should be stated
> >> clearly in the documentation.
>
> On 26.08.18 11:08, Wietse Venema wrote:
> >Absolutely not. I promise that each delivery to that destination
> >(recipient or domain) will be followed by the per-destination
> >transport_destination_rate_delay.
>
> so, does transport_destination_concurrency_limit not apply when
> transport_destination_rate_delay is >0 ?
There can be no concurrency.
With rate delay, there is an N second delay between the completion
of delivery 1 to the destination, and the start of delivery 2 to
that same destination.
>From this it follows that delivery 2 does not start before the rate
delay expires, that delivery 2 does not start before delivery 1 has
completed, and that there is no overlap in time between delivery
1, 2, 3, 4, 5, 6, 7, 8, and so on, to that same destination.
You can replace 'email' with 'car', and 'destinion' with 'bridge'.
Imagine counting cars that pass over a bridge. Imagine that car 1
starts crossing the bridge, and that some time later it arrives at
the other side. Then there is an N second delay before car 2 starts
crossing that same bridge.
>From this it follows that car 2 does not start crossing the bridge
before the delay has expired, that car 2 does not start crossing
the bridge before car 1 has arrived at the other side, and that
there is no overlap in time that cars 1, 2, 3, 4, 5, 6, 7, 8, and
so on, are crossing that same bridge.
Wietse
