From: Eric Leblond <eric@inl.fr>
To: netfilter@lists.netfilter.org
Subject: Re: about NFQUEUE and nth match
Date: Tue, 02 Aug 2005 14:59:57 +0200 [thread overview]
Message-ID: <1122987597.7160.8.camel@localhost.localdomain> (raw)
In-Reply-To: <WorldClient-F200508020846.AA46420147@tesla.cujae.edu.cu>
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
> >
> >
> >
>
>
>
>
next prev parent reply other threads:[~2005-08-02 12:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-01 20:29 about NFQUEUE and nth match Frank Abel Cancio Bello
2005-08-01 20:42 ` Eric Leblond
[not found] ` <WorldClient-F200508011918.AA18330122@tesla.cujae.edu.cu>
[not found] ` <1122939173.5292.6.camel@localhost.localdomain>
2005-08-02 12:46 ` Frank Abel Cancio Bello
2005-08-02 12:59 ` Eric Leblond [this message]
2005-08-02 13:52 ` Frank Abel Cancio Bello
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1122987597.7160.8.camel@localhost.localdomain \
--to=eric@inl.fr \
--cc=netfilter@lists.netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox