re-design struct ccnl_relay_s

[mfrey]

I propose to re-design the struct ccnl_relay_s data structure gradually. The struct is used as a global variable which is passed to functions throughout CCN-lites codebase which already has caused issues within respect to parallel access.

The basic idea is to provide a common API to data structures which allows to interchange the underlying implementation, e.g. one could provide a hash map or linked list for the content store. This would affect the following entries in struct ccnl_relay_s

struct ccnl_relay_s {
    ...
    struct ccnl_face_s *faces;  /**< The existing forwarding faces */
    struct ccnl_forward_s *fib; /**< The Forwarding Information Base (FIB) */

    struct ccnl_interest_s *pit; /**< The Pending Interest Table (PIT) */
    struct ccnl_content_s *contents; /**< contentsend; */
    ...
};

In a first step one would need to define a common API for example for a content store, e.g.

...
/** adds a content store entry */
void add(...);
/** removes a content store entry */
void del(...);
/** searches the content store for an entry and returns its position */
int search(...);
/** retrieves an item of the content store */
struct ccnl_content_s get(...);
...

There would be also need for management functions which would allow to set different implementations (and also set a default implementation by default). The down-side so to speak introduces function pointers and it is also not clear if we can come up with a really generic API for different data structures (e.g. think e.g. for example of additional parameters/functions a data structure needs (this is a solvable problem, but it raises the question if we can have a clean and easy to grasp API)).

Any thoughts? Comments?

[mfrey]

This probably would also ease our efforts to get rid of malloc for IoT devices (by having a component which provides data structures which have been "statically allocated").

[blacksheeep]

I like this idea

[blacksheeep]

Can you explain the point with the management funcitons with more details.
I did not get, why they are related to the content store?

[mfrey]

Can you explain the point with the management funcitons with more details.
I did not get, why they are related to the content store?

Management functions is probably a bit exaggerating. You need functions to set your implementation, e.g. (the header)

/** our generic function to add to the content store */
void add(struct ccnl_prefix_s prefix, uint8_t** data);
/** function to set our function pointer */
void set_add(void (* function_pointer)(struct ccnl_prefix_s, uint8_t**));

and your implementation

/** a "private" function pointer for the add function */
static void (*add_func)(struct ccnl_prefix_s, uint8_t**);

void add(struct ccnl_prefix_s prefix, uint8_t** data) {
       /** check if the pointer is set */
       if (add_func) {
              /** pass the paramaters to our underlying implementation */
              add_func(prefix, data);
       }
}

void set_add(void (* function_pointer)(struct ccnl_prefix_s, uint8_t**)) { 
       if (function_pointer) {
              add_func = function_pointer;       
       }
}

and then somewhere else

void hash_map_add(struct ccnl_prefix_s prefix, uint8_t** data) { ... }

and again somewhere else

void init(...) {
     /** let's use a hash map for our content store */ 
     set_add(&hash_map_add);
}

If you provide a hash_map you would set the hash_map functions to the corresponding implementation. You have one "generic" interface, but can choose which "concrete" implementation of a data structure you will use.