locked
Filtering conditions - AND, (consecutive) OR and performance RRS feed

  • Question

  • Hi,

     

    I need to implement a simple scenario. I need my callout to be called for all IP addresses (on a given port) except a few ones. However consecutive conditions with the same ID are ORed hence I have a problem.

    My conditions without exceptions are simple:

    [Port==5000] - matches all IPs on 5000

    and when I add an exception IP address:

    [Port==5000 AND IP!=192.168.0.0/24] - matches all IPs on 5000 except for the 192.168.0.* range (OK!)

    but when I add two exceptions (and I need to be able to add as much as I desire):

    [Port==5000 AND (IP!=192.168.0.0/24 OR IP!=10.0.0.0/24)] - matches all IPs on port 5000 :(

     

    What is the 'best practice' solution here? I don't see a way to disable the 'consecutive ORing' feature which would be perfect. Should I add each exception IP as a separate filter? If so, how will that impact performance?

    And since we're talking about conditions - are they somehow 'compiled'? I could just use this but it seem like an ugly hack (haven't tried it):

    Port==5000 AND IP!=anIP AND Port==5000 AND IP!=anotherIP AND...

    How does the BFE handle conditions? Is there some optimisation involved or just a simple loop until false/end?

     

    And since we are talking about filters I have another performance/best practise question. Which is faster:

    1. Simple callout that doesn't check anything (apart from what it requires) AND a bunch of filters/conditions to have it called exactly when needed

    2. A 'clever' callout that checks if it should react based on the data provided by the BFE (metavalues) AND a single, simple filter that (for example) just limits the port/protocol.

    I would assume the first answer is better unless it's notably slower then the second one?

     


    QmQ
    Monday, June 13, 2011 8:41 AM

Answers

  • Best practice would be to use multiple filters.   i.e. F1 = Port 5000 AND Address != 192.268.0.0 /24 F2 = Port 5000 AND Address != 10.0.0.0 /24

    The filter match logic is very optimized.  Filters are not compiled.  BFE maintains hash tables etc.  for the filters

    The general rule is the less work a callout has to do, the better. You could easily implement your solution by having a filter for just port 5000, and first thing in your callout is to return if the addresses aren't what you want.  Provided you optimize your comparison, I doubt you'd see any significant perf hit from this solution.

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, June 29, 2011 7:39 PM
    Moderator

All replies

  • OK, I've found a way around this. I add a filter with the same conditions that the callout filter plus an OR of 'IP equals' to the BFE. This filter has a weight higher than the callout filter hence it's evaluated first. However this filter does not have a provider context associated. For the callout to work I require the provider context so when it gets called without one I permit that traffic.

    What do you think of such a solution?

     


    QmQ
    Wednesday, June 15, 2011 1:12 PM
  • Best practice would be to use multiple filters.   i.e. F1 = Port 5000 AND Address != 192.268.0.0 /24 F2 = Port 5000 AND Address != 10.0.0.0 /24

    The filter match logic is very optimized.  Filters are not compiled.  BFE maintains hash tables etc.  for the filters

    The general rule is the less work a callout has to do, the better. You could easily implement your solution by having a filter for just port 5000, and first thing in your callout is to return if the addresses aren't what you want.  Provided you optimize your comparison, I doubt you'd see any significant perf hit from this solution.

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, June 29, 2011 7:39 PM
    Moderator