Pablo Neira Ayuso wrote:
I'd prefer polling from both sockets instead of using threads, you can access the socket descriptors via nfct_fd() and nfq_fd(). Anyway, the main problem that I see is that you'll have to delay the packet verdict until you receive the conntrack event, otherwise you risk to have a race condition. However, I think that the solution would not be that performant.
Would it be better if I just spawn another thread with a timer which looks at intervals if a connection in my list has to be deleted? This way I would not need conntrack at all and it might be the fastest solution.
Btw. I did a throughput test on the kernelspace module and the userspace daemon without conntrack (so no deletion of connections in my list). I figured out that the kernelspace module had less throughput than my daemon and I didn't had a good explanation for this. Is it possible that my conntrack solution in kernelspace is lowering the performance below the performance in userspace without conntrack?
-- 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
