Le mardi 02 août 2005 à 08:46 -0400, Frank Abel Cancio Bello a écrit : > Thanks again eric > > Can you send me or point me to some code that you are tested? All the tests have been done on NuFW : http://www.nufw.org The libipq sources are in the src/nufw directory. The daemon in quiet simple : * one thread read message from kernel and send them other network (packetsrv.c) * second thread read decision from network and give it to kernel (authsrv.c) Hope this help, BR, > > Salute > Frank > > > Le lundi 01 août 2005 à 19:18 -0400, Frank Abel Cancio Bello a écrit : > > > > On Mon, 2005-08-01 at 16:29 -0400, Frank Abel Cancio Bello wrote: > > > > > Hi all! > > > > > > > > > > Some time ago I post a mail in this list > > > > > > > > > ("https://lists.netfilter.org/pipermail/netfilter/2005-April/059499.html";) > > > > > asking about how manage packets that was captured with "libipq" and > > > "QUEUE" > > > > > target in different threads or process. > > > > > > > > > > Now with the new "NFQUEUE" target I can have many process reading > > > parckets > > > > > in different queues numbers and using "nth match" to spread > equitably > > > over > > > > > all process the captured packects. > > > > > > > > This look terribly awfull to me ! You better use a single > multithreaded > > > > application. > > > > > > > > > > Due to libipq isn't thread-safe (see one problem in > > > > > > http://www.experts-exchange.com/Programming/Programming_Platforms/Linux_Programmi > > ng/Q_20766491.html) > > > and I'm not a netfilter hacker I send the mail > > > (https://lists.netfilter.org/pipermail/netfilter/2005-April/059499.html) > but > > > anybody reply. > > > The problem is that I need to know if is safe make a multithreaded > > > application with libipq. Now I have the same questions that that some > time > > > ago: > > > > >From my experience, I've tested with two threads. One receiving packets > > the other sending packets back to kernel. It seems to work fine, even > > under heavy load. I've never tried multiple sending and receiving > > threads. > > But you can always have something like that by using messages between > > the threads. > > > > BR, > > -- > > Eric Leblond > > > > > > > > > >
