I've seen some discussion around performance on the forums but nothing official. What is the best practice for [handleNewFlow:] , [handleOutboundDataFromFlow:], and [handleInboundDataFromFlow:] callbacks in a content filter? Are all flows funneled through a single serial queue that calls into my subclass? If so this seems like we are back in the days of early OS X with the kernel network funnel serializing all network traffic. Should I offload flow processing onto a concurrent queue and then pause the flow and return from my callback? Or just do all processing in the callbacks?
And once I return an allow/deny verdict for the flow (without asking for more data) do I no longer see that flow's traffic in my content filter? That's what I would expect and it seems to be the case in actual practice too.
For reference I never need to interact with the user. All of the rules are loaded from an EDR platform.
I bring this up because we have users complaining of "stuttering" during Google Meet / Zoom, etc when our extension is active and from our perf metrics time spent in the callbacks are minimal (a few hundred usecs). But if all traffic is serialized through our content filter and the system is very busy I wonder if this could lead to dropped packets.
What if multiple content filters are present? Are they all serialized with each other? Oof.
Does it dispatch requests to each in parallel or does it simply have a for(filter){request} serial loop?
I don’t know, but if you forced me to guess I’d say that the latter is the more likely option.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"