Re: WCCP v2 implementation thoughts.

Thanks, Henrik.

You're right, a union is probably the better choice. But I still don't
know how to unroll that into a packet in a generic way. I guess with
unions I'll have a generic data structure and a specific routine for
each component and packet type. At least one part will be generic. ;-)

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.

The message header contains a 16 bit length field that includes the
entirety of the packet except the message header itself (which is always
a known size of 64 bits). Each component also has a 16 bit length value
that gives the length of the remainder of a given component, excluding
the type and length. For example, if we have a HERE_I_AM which contains
a security info component, the packet will look like this (minus all of
the other components which are also of variable length and have their
own length values):

struct wccp2_here_i_am {
        struct message_header_t message_header;
        struct security_info_t security_info;
        etc...
};

struct message_header_t {
        uint32_t type; /* This contains the packet type WCCP2_HERE_I_AM */
        uint16_t version; /* Version 0x200 */
        uint16_t length; /* Length of the remainder of the packet, excluding this
header, but including all other components */
};

struct security_info_t {
        uint16_t type; /* WCCP2_SECURITY_INFO (0) */
        uint16_t length; /* Length of the security component excluding the type
and length */
        uint32_t security_option; /* either NO_SECURITY or MD5_SECURITY */

/* if MD5_SECURITY, we have to define the password and checksum in a 16
octet field */
        uint8_t md5_checksum[8];
        char password[8]; /* Should this instead be uint8_t or can we safely
htons a char? */
};

Note that every 'component' of the packet (of which there are about 10)
has a different structure and different size. Most are required to be
present in some form.

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.

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.

Henrik Nordstrom wrote:

> To me it sounds like you may be looking for the C construct "union".
>
> struct wccc_packet {
> [common data]
> enum wccp_type { WCCP_FOO, WCCP_BAR } type;
> union {
> struct wccp_foo foo;
> struct wccp_bar bar;
> } data;
> };
>
> Here "data" is either a wccp_foo or a wccp_bar.
>
> What I don't get is why you have a length parameter in the structs.
>
> --
> Henrik
>
> Joe Cooper wrote:
>
>
>>By this, I mean, I have a struct foo, and a struct bar:
>>
>>struct foo {
>> uint16_t type;
>> uint16_t length;
>>};
>>
>>struct bar{
>> struct foo foostruct;
>> uint32_t length;
>>}
>>
>>Now, is there a way to (safely) unroll the values of either of these
>>structs into a packet buffer using the same function even though their
>>contents are dissimilar? Pointers to documentation would be fine, I'm
>>just not seeing any examples in any of my books.
>>
>>Feel free to ridicule me for going about it all wrong from the get go.
>>(Just offer up tips for the right direction.)
>>
>>Thanks!
>> --
>> Joe Cooper <joe@swelltech.com>
>> Affordable Web Caching Proxy Appliances
>> http://www.swelltech.com
>>
>
>

-- 
                                   --
                      Joe Cooper <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com