Re: WCCP v2 implementation thoughts.

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 <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com
Received on Fri Jul 20 2001 - 04:12:40 MDT