1d0cb1040e
Motivation: Previously we would use the combination of DispatchQueue.asyncAfter and a DispatchWorkItem for the connect timeout. If the connection succeeded we would just cancel the DispatchWorkItem. Unfortunately that will still keep everything that's captured in the DispatchWorkItem alive until the deadline has come (because DispatchWorkItem is just a dumb wrapper over a closure). Modifications: use a DispatchSource of type timer source instead. Result: - we won't keep the ELG/EL/Channel/... alive until at least the connect timeout expires. - fixes #28 |
||
|---|---|---|
| .github | ||
| Sources | ||
| Tests/NIOTransportServicesTests | ||
| dev | ||
| scripts | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| Package.swift | ||
| README.md | ||
README.md
NIO Transport Services
Extensions for SwiftNIO to support Apple platforms as first-class citizens.
About NIO Transport Services
NIO Transport Services is an extension to SwiftNIO that provides first-class support for Apple platforms by using Network.framework to provide network connectivity, and Dispatch to provide concurrency. NIOTS provides an alternative EventLoop, EventLoopGroup, and several alternative Channels and Bootstraps.
In addition to providing first-class support for Apple platforms, NIO Transport Services takes advantage of the richer API of Network.framework to provide more insight into the behaviour of the network than is normally available to NIO applications. This includes the ability to wait for connectivity until a network route is available, as well as all of the extra proxy and VPN support that is built directly into Network.framework.
All regular NIO applications should work just fine with NIO Transport Services, simply by changing the event loops and bootstraps in use.
Why Transport Services?
Network.framework is Apple's reference implementation of the proposed post-sockets API that is currently being worked on by the Transport Services Working Group (taps) of the IETF. To indicate the proposed long-term future of interfaces like Network.framework, we decided to call this module NIOTransportServices. Also, NIONetworkFramework didn't appeal to us much as a name.
How to Use?
Today, the easiest way to use SwiftNIO Transport Services in an iOS project is through CocoaPods:
pod 'SwiftNIO'
pod 'SwiftNIOTransportServices'
You can also use the Swift Package Manager:
swift build
and add the project as a sub-project by dragging it into your iOS project and adding the frameworks (such as NIO.framework) in 'Build Phases' -> 'Link Binary Libraries'.
Do note however that Network.framework requires macOS 10.14+, iOS 12+, or tvOS 12+.
Versioning
This repository will remain in development throughout the beta period of macOS Mojave and iOS 12. Once those operating systems have gone GM, we will finalize the API and cut a stable release.
Developing NIO Transport Services
For the most part, NIO Transport Services development is as straightforward as any other SwiftPM project. With that said, we do have a few processes that are worth understanding before you contribute. For details, please see CONTRIBUTING.md in this repository.
Please note that all work on NIO Transport Services is covered by the SwiftNIO Code of Conduct.