Re: WCCPv2 support

Hi,

I think I understand...and this version now properly handles redirect assignments. I'm excited for people to test this because it doesn't seem to crash anything, well then there's the router that seems to have some wccp bug in it, but I can't figure that out.

It still doesn't handle the standard wccp (standard service0) which puzzles me--the router says service mismatch and doesn't provide more useful information. It knows it is 0:0 but something about my definition it doesn't like, very odd.

To test this you'll need to mod the cf.data.pre bits a little to include Config.Wccp2.router_id (yeah I know bad bad bad) we're really not a router id and so perhaps we should be a cache_id

and you'll want to make Config.Wccp2.routers (note the s) be a wordlist.

This doesn't do multicast yet, but I want to get unicast working first, then I'll think about multicast.

It doesn't check to make sure everybody is seeing him, this not really a problem in unicast mode but multicast mode will definitely cause problems no question about that.

For now it only handles one cache. As I finally understand the hash bits a little, there are some comments about how one might decide to roll across caches--me not being a squid developer really I don't have much thought on how one might accomplish round-robining but maybe somebody could take some of the same ideas and put them into the code.

It does not understand "alternate assignment"

and looks like the wccp module for hte kernel might need to be modified--it assumes standard/0 for service only (I think, if I understand the code)

well hopefully somebody can at least get it to compile. It does seem to work in a multirouter setup though.

sorry about top-posting the mail software sucks :(

_J

>>> Henrik Nordstrom <henrik@henriknordstrom.net> 03/13/06 5:41 AM >>>
sön 2006-03-12 klockan 23:04 -0500 skrev Jeremy Hall:

> I'm not sure whether it is a good idea to wait until routers are
> included (until we're 2waying with them, somebody understanding te
> protocol better than I would have great comments I'm sure)

There is multiple negotiations going on.

a) router<->cache negotiation. This is the "HERE_I_AM -> I_SEE_YOU"
handshake. It is completed by the cache getting included the list of
cache servers in I_SEE_YOU messages from the router, which requires a
"HERE_I_AM -> I_SEE_YOU -> HERE_I_AM -> I_SEE_YOU" sequence (first three
to verify connectivity, the last to inform the designated cache you are
available..)

b) Election of the designated cache. Ther is an election algorithm
(outside the protocol) defining which cache is the designated cache. The
recommended algorithm is that the cache with the lowest IP gets elected.
The list of potential designated cache servers is found in the I_SEE_YOU
packets. If you are not there, or not the lowest IP there then you are
not the designated cache..

c) designated cache -> router assignment using REDIRECT_ASSIGNMENT
messages, based on the information it received in the I_SEE_YOU packet
from the router.

In service groups the designated cache election gets a little messy as
each router maintains it's own WCCP state and things can get out of sync
if not all equipment is configured proper or some device is restarted.
Consider for example a potential designated cache only announcing itself
to a subset of the routers in the service group.. but these fine details
can be left to deal with later.. The 1.5 HERE_I_AM_T delay helps a lot
in reducing this.

Regards
Henrik