On Tue, Feb 09, 2016 at 09:23:17AM -0500, Peter Bisroev wrote: > Hi Gilles >
Hi, > <snip> > > > We have faced a similar issue with filters and my thoughts are that we need > > a > > listen on socket of some kind, similar to your listen on local. > > > > This has several benefits over "listen on local", both in ambiguity and it > > new ways the ruleset can match sessions. > > > > If you're interested to work on it, I'd be happy to discuss this with you > > so you can come up with a diff :-) > > I would definitely be interested. Could you elaborate a bit on "listen > on socket" method? > Well your idea for a "listen on local" is very valid and the way to go in my opinion, however the keyword "local" is inappropriate here as we have a very different meaning for it: a message coming from an address that is also the address of a listener. A network connection from 127.0.0.1 or 192.168.1.1 is local on my box, even though it's not coming from the socket. If we introduced a "listen on socket" of some sort, then we could have params applied to the socket + possibly add support for multiple ones, we could also differentiate between local sessions initiated on the machine and local sessions initiated on the network to apply a finer ruleset matching. This would also solve a problem we have with filters where they are applied to network listeners but not to the local socket which requires a specific keyword (ok for now since they are experimental). > Thank you! > --peter > -- Gilles Chehade https://www.poolp.org @poolpOrg
