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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.