On Thu, 31 Oct 2002, Henning Brauer wrote:
> On Thu, Oct 31, 2002 at 01:03:23PM +1000, Rukh wrote: > > Actually, there wouldn't be any real performance penalty, because these > > embrionic states are in effect only a tree sorted list of one shot rules. > > oh yes, and the lookup is absolutely for free, sure. of course not > > And if you don't like using embrionic states, then you would have an empty > > embrionic state tree and it would then only require one extra pointer > > comparison (and seeing that it's NULL), before moving on to evaluating the > > rule set. > > yes. extra cost. a little extra cost here, a little extra cost there, > summarized is more than just a little extra cost. > first let me get some stuff clear in my head. an embryo state is required where we have almost all the information required for a state entry as determined by a userland proxy such as ftp-proxy or tircproxy (ftp and irc seem to be the only offenders i can think of). the most common bit of missing information being the remote hosts src port (this info could make code simpler). the fact that pf in its current state doesnt seem to address this problem well has led to this discussion. tne current idea seems to be having an embryo tree (like the state tree but with wildcards for certain fields) in between the state tree and the rule list. henning has correctly stated that this would give a performance hit. rukh has suggested that instead of having an embryo tree in between the states and the rules, you have a rule that lets pf traverse the tree. therefore, users that dont need it dont get affected by it. rather than having an "embryo" flag on a rule tho, id make it its own directive and have it before the normal filter rules, therefore evaluated before the normal rules. state is checked before rules. since embryo states are almost states, it makes sense to me that they get checked before the rules as well. having such a rule (or rules) has several other advantages, you could create several trees, one for each proxy that requires it (include a mechanism for the proxy to talk to its own tree). you could specify which field of the state entry is variable (id still say that remote src port would be th only one, but its nice to be flexible). you could specify tcp flags and state modulation. whatever is needed for connections created by the proxy. im sorry if i havent explained well. fatigue is not a friend when you're trying to be smart. or creative. which is why im going to stop typing now. thanks, David Gwynne.
