Hello,
I am working on network traffic analyser for DLP. The solution is based on NETransparentProxyProvider due to necessity data modifying. To my knowledge, the Transparent Proxy API does not have a concept of an "asynchronous/delayed verdict" for flow authorization. The handleNewFlow(_:) method appears to be invoked sequentially for each new network flow that matches our interception rules.
The challenge we are facing is that a portion of our proxy rules and configurations resides in a LaunchDaemon, which the Network Extension communicates with via XPC. Such separation is required by our cross-platform code base. Thus, we are forced to make a synchronous XPC call within handleNewFlow(_:) and block the thread while waiting for the interception verdict from the daemon. This creates a significant bottleneck when establishing new network flows.
The current implementation works without issues, but we are always looking for ways to improve performance.
Are there any best practices or recommended approaches for parallelizing handleNewFlow(_:)?
Thank you in advance.
the Transparent Proxy API does not have a concept of an "asynchronous/delayed verdict" for flow authorization.
Correct.
This creates a significant bottleneck when establishing new network flows.
Indeed. Something has to give here. You could reasonably file an enhancement request for Apple to support multi-threading in handle-new-flow calls, but it’s hard to imagine that happening in a useful timeframe. The obvious short-term fix — changing your architecture to run these queries in fast, synchronous manner — will likely yield the results you need before any ER could land.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"