Re: [Taps] New Transport Networking APIs in iOS 12 beta

[Tommy Pauly <[e-mail]>]

> On Jun 15, 2018, at 1:00 AM, Michael Welzl <[e-mail]> wrote:
> 
> Hi,
> 
> Thanks for sharing this! It’s quite interesting -
> 
> 
>> On Jun 11, 2018, at 6:47 PM, Jonathan Lennox <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> I’ve read over Apple’s new API.  (One note: the URL that Tommy sent a link to doesn’t have the full documentation of the API yet; many of the types and methods still say “No overview available.” If you’re an Apple developer, the header files supplied with the macOS 10.14 and iOS 12 beta SDKs in the Xcode 10 beta contain much fuller versions of the documentation.)
> 
> I agree, things are a bit inconsistent in the online docs for now… e.g. somehow this:
> https://developer.apple.com/documentation/network?language=objc <https://developer.apple.com/documentation/network?language=objc>
> seems to be more complete than
> https://developer.apple.com/documentation/network/nwpath <https://developer.apple.com/documentation/network/nwpath>
> but then there are also differences that are probably not due to the language choice only. Well, it all clearly says “Beta”, so that’s ok, we’ll just have to wait until this documentation is updated.
> 
> 
>> The main difference I’ve found between TAPS and Network.framework is that Network.framework doesn’t have a Preconnection object.  Instead, Connection objects for outgoing connections are directly created from a constructor, and then must have their .start method called before they act.
>> 
>> This part is a relatively minor semantic difference, but more significant is how incoming connections are handled.  In Network.framework, there is a Listener object with a new_connection handler, and this object can produce unlimited numbers of Connections until stopped.  This is unlike TAPS where a Listen action consumes a Preconnection, and to receive multiple connections on the same port, Listen must be called on multiple cloned Preconnections.
> 
> I agree that the first difference is minor (constructor vs. “Preconnection”). I would also say that the latter difference is interesting but not huge… (“under the hood” it’s easy to imagine that these can be two ways to essentially expose the same thing). I’d also agree that the Network.framework method is more convenient though. Tommy - what would you say about moving our API in that direction for Listening?
> 
> 
>> I feel like the Network.framework model is an easier programming model for most use cases, but it has the downside that an API user has no way to pace its handling of incoming connections.
> 
> I haven’t played with the Network.framework myself, but I would guess that, if I want to slow down the rate at which I handle incoming connections, there isn’t really much difference between not calling Listen (current TAPS) vs. ignoring a newly created incoming Connection (Network.framework). Why wouldn’t that work as a way to pace conn. handling?

One first note: a lot of the ‘preconnection’ properties are encapsulated in our NWParameters object. The main difference, conceptually, is that the parameters object is just a container (which may be reused) but doesn’t imply that any work can happen just by creating a parameters object.

Regarding calling listen multiple times vs providing a single completion handler to be called multiple times: I find the Listen model appropriate to have a single completion that gets invoked multiple times because the code in response to a Listen is generally going to be the same—each new connection cannot be assumed to have any relationship or ordering with regards to prior connections, so the logic you need to write to process an inbound connection will be the same. Thus, providing a single completion is cleaner. Contrast this to a Receive completion, in which receiving on a connection is assumed to have order—I may expect to read a “header” message, followed by a “body” message, etc, thus using multiple Receive calls not only provides back pressure, but allows different handling upon completion.

Adding back pressure to inbound connections is something that we do need to add. The approach Michael suggests, of just ignoring an inbound connection until we’re ready to process it, certainly would work. The downside is that this requires the caller of the API to manage their own array of pending inbound connections. One option we’ve considered is allowing the application to specify a “receive connection window size” on a listener, thus defining how many more inbound connections they’re ready to handle at a given time. What do people think about this approach?

Thanks,
Tommy

> 
> Cheers,
> Michael
>