Pablo Neira Ayuso wrote:
Pablo Neira Ayuso wrote:
Patrick McHardy wrote:
I see. That kind of makes sense, but if you're running a
synchronization daemon anyways, you might as well renumber
all nodes so you still have proper balancing, right?
Hm, I was not replying to your question ;). Right, the renumbering also
requires getting the states back to the original node. We can use the
same hashing approach in userspace to know which states belong to
original node that has come back to life when it requests a
resynchronization.
Indeed, the daemon may also add a new rule for the node that has gone
down but that results in another extra hash operation to mark it or
not (one extra hash per rule) :(.
This is not true. We may have something like this (assuming two nodes):
To whom are you replying now? :)
if no mark set and hash % 2 == 0, accept
if no mark set and hash % 2 == 1, accept
if no mark set, drop
So we can still do this adding rules with the iptables interface. But
still having the /proc looks like a simple interface for this.
I'm sure someone would argue that changing TCP port numbers of
the tcp match through proc would be a nice and simple interface.
The fact though is that we have an interface for handing a
configuration to the kernel and this is clearly a configuration
parameter. We're missing a proper way to use it in userspace
from within programs (well, hopefully not for long anymore),
but that needs to be fixed in userspace.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
