Re: WCCP v2 implementation thoughts.

From: Joe Cooper <>
Date: Fri, 20 Jul 2001 05:20:06 -0500

Henrik Nordstrom wrote:

> Joe Cooper wrote:
>>I'm including length because length in WCCP packets is /not/ the length
>>of the entire structure (or packet) and is variable dependent on the
>>features in use, and the number of routers and caches. And there is a
>>length field for every component of the packet--not just the packet itself.
> And I am questioning having the length in the structures, as the packet
> length is only valid for the packet format, not the decoded structures.

Ok. Makes sense.

>>struct wccp2_here_i_am {
>> struct message_header_t message_header;
>> struct security_info_t security_info;
>> etc...
> Which cannot be represented by a struct, or even union. The best way to
> represent such a structure in decoded format is a list.


> The packet is a stream of octets. There length is obviously needed to
> keep a good structure of the data format.
> The in-memory structures are another representation of the same data.
> Here length is not that relevant. The data is of known types, having
> their own lengths (which quite likely is not identical to the packet
> format length).
>>Are you suggesting I should leave the length fields out of each of these
>>structures and calculate it at packet construction time? If so, where
>>do I put the incoming packets length information? We need that to
>>figure out where the components are delineated in the packet.
> Yes.
> No. You decode each component separately and make a list of the
> components. The list can either be represented as a linked list, or a
> list of pointers to the supported component types.

Ok. That was what I was after. Will go that way now.

>>I have been in a quandary about how to calculate the length, since a
>>sizeof(structure_name) isn't going to be accurate, and even a header
>>adjusted (sizeof(structure_name) - 4) isn't always going to be correct,
>>because some fields are optional. I'd rather not rely on knowledge of
>>the spec (i.e. adding it up in advance and putting it in defines, which
>>is what the old v1 and v2 code does) since that will make it harder to
>>extend the module later for additional features of WCCP v2.
> You must make struct -> octet stream encoding routines. When this is
> done the length is obvious (the size of the encoded result). Similar to
> the RPC encoding routines.
> Note that all fields need to be encoded in network octet order, not the
> CPU native order.

Does htons and htonl handle order suitably?

Thanks for your detailed reply Henrik. I think I know where to point my
vi now.
                      Joe Cooper <>
                  Affordable Web Caching Proxy Appliances
Received on Fri Jul 20 2001 - 04:12:40 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:07 MST