Hi, Thanks for sharing this! It’s quite interesting -
> On Jun 11, 2018, at 6:47 PM, Jonathan Lennox <jonat...@vidyo.com> 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? Cheers, Michael
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
