Re: WCCP v2 implementation thoughts.

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.

> 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.

/* List approach */

struct wccp_packet {
    wccp_type type:
    wccp_version version;
    wccp_packet_component *components;
}

struct wccp_packet_component {
    wccp_packet_component_type type;
    union {
        wccp_security_info security;
        wccp_foo foo;
        wccp_bar bar:
    } data;
};

/* Pointer approach */

struct wccp_packet {
    wccp_type type;
    wccp_version version;
    wccp_security_info *security_info;
    wccp_foo *foo;
    wccp_bar *bar;
};

The pointer approach is most likely easiest to work with.

> 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.

--
Henrik