NETransparentProxyProvider handleNewFlow vs handleNewUDPFlow

Question

faisalIkwal OP

Created 3w

Replies 3

Boosts 0

Participants 2

NETransparentProxyProvider having these two methods:

override func handleNewFlow(_ flow: NEAppProxyFlow) -> Bool
override func handleNewUDPFlow(
    _ flow: NEAppProxyUDPFlow,
    initialRemoteEndpoint remoteEndpoint: NWEndpoint
) -> Bool

During initial days when NETransparentProxyProvider was introduced, We used handleNewFlow to handle NEAppProxyTCPFlow and handleNewUDPFlow to handle NEAppProxyUDPFlow .

Since handleNewUDPFlow is now deprecated, is it just okay to use handleNewFlow to handle both NEAppProxyTCPFlow & NEAppProxyUDPFlow?

will this works always or there are some scenario where keeping handleNewUDPFlow will be usefull?

Answered by DTS Engineer in 808514022

Since handleNewUDPFlow is now deprecated, is it just okay to use handleNewFlow to handle both NEAppProxyTCPFlow & NEAppProxyUDPFlow?

Yes and no.

It’s always been fine to use just handleNewFlow(…). However, I think you’ve misunderstood the reason behind the deprecation of handleNewUDPFlow(_:initialRemoteEndpoint:). It wasn’t deprecated because it’s no longer necessary. Rather, it was deprecated because it works in terms of legacy types. It’s replacement is handleNewUDPFlow(_:initialRemoteFlowEndpoint:), which works in terms of Network framework’s standard NWEndpoint type.

So:

If you need the initial remote endpoint, implement that new method.
And if you have to support old systems, you’ll need to implement the old method too.
If you don’t need the initial remote endpoint, it’s fine to do everything in handleNewFlow(…).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

2w

Accepted Answer

Recommended

Since handleNewUDPFlow is now deprecated, is it just okay to use handleNewFlow to handle both NEAppProxyTCPFlow & NEAppProxyUDPFlow?

Yes and no.

It’s always been fine to use just handleNewFlow(…). However, I think you’ve misunderstood the reason behind the deprecation of handleNewUDPFlow(_:initialRemoteEndpoint:). It wasn’t deprecated because it’s no longer necessary. Rather, it was deprecated because it works in terms of legacy types. It’s replacement is handleNewUDPFlow(_:initialRemoteFlowEndpoint:), which works in terms of Network framework’s standard NWEndpoint type.

So:

If you need the initial remote endpoint, implement that new method.
And if you have to support old systems, you’ll need to implement the old method too.
If you don’t need the initial remote endpoint, it’s fine to do everything in handleNewFlow(…).

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

faisalIkwal OP

2w

@DTS Engineer Any specific reason why apple has not added remoteEndpoint to NEAppProxyUDPFlow but remoteEndpoint is available for NEAppProxyTCPFlow?

0

Answer 3

DTS Engineer OP

Apple

2w

Because a TCP flow is clearly defined by its local IP / local port / remote IP / remote port tuple. That’s is the very definition of a TCP connection, and thus it can’t change for the life of the NEAppProxyTCPFlow object.

UDP, OTOH, is more flexible. Unless the app specifically restricts the remote endpoint — in BSD Sockets, for example, they do this by calling connect on the UDP socket — then each datagram on the flow can have a different remote endpoint. That’s why the parameter to the new flow method is called initial remote endpoint and why the read method on NEAppProxyUDPFlow returns an array of datagram and endpoint tuples [1].

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] I’m talking about the very latest Swift method, which comes in both async and completion handler flavours. Older methods return parallel arrays of datagrams and endpoints because of their Objective-C heritage.

0