On 15 December 2015 at 15:36, Alexandr Nedvedicky <[email protected]> wrote: > Hello, > >> > >> > Another possibility would be to require 'once' rules to be 'quick'. >> > This closes the candidacy window and makes its serialisation, to >> > preclude multiple matches, more feasible. >> > >> > Yet another possibility is to drop 'once' rules as too complex to >> > implement for multiprocessor but I have no idea if this is viable. >> > >> >> It is. And I have said that before with an authority of the implementor >> of "once" rules: since we don't have any userland applications that >> would use this yet, we can ditch them for now and possibly devise a >> better approach later. >> >> Don't make your lives harder than they have to be! >> > > I'm just trying out patch improved by Richard. I like his idea to put anchor > rule to garbage collector list. I'd like to give it a try on Solaris. There > might be small changes in details. > > IMO once rules are fine, and offloading hard task to service/garbage collector > thread works just fine. > > regards > sasha
It just occurred to me that another possibility would be a match-only rule that matches one but doesn't involve any purging machinery. Right now we install ftp-proxy rules as having maximum number of states equal to 1, however there's a time window between the moment the state is no longer there, but anchor is not gone yet and it can potentially create more states which is not a problem for an eavesdropper who can sniff the plaintext protocol.
