> > It would be a great feature if each delay pool have its own maxconn per
ip
> > address parameter solving the accelerators problem and delay pools
> > starvation.

>
> How is the existing maxconn acl insufficient?


Parameter maxconn is matched against all connections from ip irrespective of
delay pool number
used or request not going through delay pool.
I wolud like to limit only downloads on fair share basis by delay pool where
everyone has only 1 connection available or so but I want also that if
someone is downloading he could browse without
delay.
If I limit connections by maxconn it will limit also browsing.
I've expirienced browsing problem when maxconn is too low because browsers
use more connections to speed up browsing.
ie I set sth like this:

acl conlimit maxcon 1
acl downloads urlpath_regex \.zip$ \.mp3$ ......
delay pools 2
delay_class 1 1
delay_class 2 1
delay_access 1 allow downloads conlimit
delay_access 1 deny all
delay_access 2 allow downloads
delay_parameters 1 35000/35000
delay_parameters 2 1000/1000

Delay pool 1 will never be matched because browser open some connections.
All downloads go through pool 2.
Browsing going without any pool.
I choose pool type 1 because I don't want limit user to static limit if
there is ie 35k/s available for downloading(I read some on dynamic delay
pools patches but can't get any).
Without maxconn scenario all downloads going throug pool 1 and there is no
need for pool 2 but
if someone is using download accelerator bandwidth is shared uneqally.
The worst thing is if there is more such users the delay pool is simply
starving and normal user with only one thread can't download anything.
So maxconn parameter per delay pool will solve many problems with fair
sharing and download accelerators if properly configured.

Best regards,
Bar