On Wed, 15 May 2002, Henrik Nordström wrote:
> You completely lost the ACL part here, didn't you (#if 0 segment)? The ACL 
> part is quite important to many people...
Yeah, thats where it gains most of its *hack* status, i think i totally 
butchered it ;) If you have a look this is what i was thinking of 
attempting...
addr = aclMapAddr(Config.accessList.outgoing_address, &ch);
if (addr.s_addr == INADDR_ANY)
        return adaptiveLoadBalance(Config.accessList.outgoing_address);
But we will match on the last tcp_outgoing_address x.x.x.x, so that won't 
work.
> What would be great is if this could be done using an generic ACL mechanism 
> to select 1 of N in a group of things.. This way the same mechanism could 
> apply to
> 
>   tcp_outgoing_address
>   tcp_outgoing_tos
>   cache_peer_access
> 
> and any other ACL driven selection mechanims.
> 
> This would put the implementaion mainly in acl.c..
I'll have to dig deeper into that..
> And then we have the question on persistence.. Most people would really like 
> each user to stick to one of the IP's to work around stupid websites using 
> source IP in authentication/session management..
That would be fixed if i can get the ACL checking re-incorporated.
> And then there is the question on supporting secondary alternatives when the 
> first fails.. which makes me thing that perhaps this should be done in a two 
> stage process
> a) Collect possible the alternatives by ACL driven processing
> b) Load distribution, by "Select 1 of N", or by "Reorder alternatives 
> according to load".
I'm going to rethink the whole thing and try and undo my breakage first 
then graft in the feature afterwards.
> Obviously some brain work needed here to find the correct approach.
Unfortunately for me a resource in short supply ;)
Regards,
        Zwane Mwaikambo
-- http://function.linuxpower.caReceived on Wed May 15 2002 - 22:16:37 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:27 MST