On 9/28/07, Gerrit Renker <[EMAIL PROTECTED]> wrote:
> [DCCP]: Basic data structure for feature negotiation
>
> For implementing an improved DCCP feature negotiation, data structures are
> provided:
> * a container for the various (SP or NN) values,
> * symbolic state names to track feature states,
> * an entry struct which holds all current information together,
> * elementary functions to fill in and process these structures.
>
> Entry structs are arranged as a FIFO for the following reason: RFC 4340
> specifies that
> if multiple options of the same type are present, they are processed in the
> order of
> their appearance in the packet; which means that this order needs to be
> preserved in the
> local data structure (the later insertion code also respects this order).
>
> The struct list_head has been chosen for the following reasons: the most
> frequent operations are
> * add new entry at tail (when receiving Change or setting socket options);
> * delete entry (when Confirm has been received);
> * deep copy of entire list (when cloning from listening socket onto request
> socket).
>
> I am wondering whether struct list_head is `too fat' for a request socket,
> but have kept this
> structure since it lead to simpler code. If structure sizes are an issue, I'd
> be willing to
> convert to singly-linked list later if necessary (but it would need a tail
> pointer).
>
> The NN value has been set to 64 bit, which is a currently sufficient upper
> limit (Sequence Window
> feature has 48 bit).
>
> Signed-off-by: Gerrit Renker <[EMAIL PROTECTED]>
Acked-by: Ian McDonald <[EMAIL PROTECTED]>
--
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
