James Yonan wrote:
Why don't you use the existing multi_context::vhash hash to keep track of
the server-side MAC table? I know that this hash is usually used to
associate MAC or IP addresses with a given client instance, but it seems
ideally suited for this. Maybe you could add a flag to struct multi_route
to indicate that the MAC is server-side and set multi_route::instance to
NULL.
I considered that, but after trying that for an hour I realized that I
had a hard time getting an accurate overview of the code. For example:
there are 24 function definitions in lists.h, what do they all do and
how do they affect each other?
Two major issues needed to be resolved:
* A FIFO list through all hash elements to easily remove the oldest
element.
* The bucket bases locking can no longer exist if there's a FIFO
structure through all entries (and buckets).
So I had to consider code at many places, including the locking (for
multi threading I assume), which requires a lot of testing to make sure
it all works well.
As I need this functionality quite soon (I expect several hundreds of
MAC entries behind one of the clients, so there should be no MAC quotum
for clients), so I decided to create a prototype based on a separate MAC
table. The coding of the mac_table.[ch] files took me about 2 hours,
including a stand alone program (without OpenVPN) to test it. As the API
is small (5 function prototypes in mac_table.h) it was realy easy to
integrate it into multi.c (another 2 hours, including testing).
Bottomline: I needed a (working) prototype without to much effort, to
see if this solves the problems I'm experiencing.
Though I'm sure it's possible to integrate the mac_table features in
lists.c, It would take me a long time to do so, because lists.c has a
generic structure that is uses in several ways and testing may be hard.
The mac_table.c file is just over 300 lines and has a simple API (5
functions in mac_table.h) which made both debugging and testing easy.
Because MAC tables operate different from route caches you may consider
different implementations, but of course that's up to you.
Also, it would be great if you could #ifdef this code so that we can turn
it on or off.
Sure, I'll do that. I'll do it based on mac_table.[ch], to save time.
OK? If you want we can integrate mac_table functionality into
lists.[ch], but it may require a lot of your help.
James
