apple / swift-nio-transport-services

Extensions for SwiftNIO to support Apple platforms as first-class citizens.

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?

NIO Transport Services primarily uses SwiftPM as its build tool, so we recommend using that as well. If you want to depend on NIO Transport Services in your own project, it's as simple as adding a dependencies clause to your Package.swift:

dependencies: [
    .package(url: "https://github.com/apple/swift-nio-transport-services.git", from: "1.13.0")
]

and then adding the NIOTransportServices module to your target dependencies.

If your project is set up as an Xcode project and you're using Xcode 11+, you can add NIO Transport Services as a dependency to your Xcode project by clicking File -> Swift Packages -> Add Package Dependency. In the upcoming dialog, please enter https://github.com/apple/swift-nio-transport-services.git and click Next twice. Finally, make sure NIOTransportServices is selected and click finish. Now will be able to import NIOTransportServices in your project.

Supported Platforms

NIOTransportServices is supported where Network.framework is supported: macOS 10.14+, iOS 12+, tvOS 12+, and watchOS 6+.

In order to allow dependencies to use NIOTransportServices when it's available and fallback to NIO when it isn't, all code is behind import guards checking the availability of Network.framework. As such NIOTransportServices may be built on platforms where Network.framework is not available. NIOTransportServices can be built on macOS 10.12+, iOS 10+, tvOS 10+, watchOS 6+ and Linux but is only functionally useful on macOS 10.14+, iOS 12+, tvOS 12+ and watchOS 6+.

Versioning

Just like the rest of the SwiftNIO family, swift-nio-transport-services follows SemVer 2.0.0 with a separate document declaring SwiftNIO's Public API.

swift-nio-transport-services 1.x

swift-nio-transport-services versions 1.x is part of the SwiftNIO 2 family of repositories and does not have any dependencies besides swift-nio, Swift 5.7, and an Apple OS supporting Network.framework. As the latest version, it lives on the main branch.

To depend on swift-nio-transport-services , put the following in the dependencies of your Package.swift:

.package(url: "https://github.com/apple/swift-nio-transport-services.git", from: "1.0.0"),

The most recent versions of SwiftNIO Transport Services support Swift 5.7 and newer. The minimum Swift version supported by SwiftNIO Transport Services releases are detailed below:

SwiftNIO Extras	Minimum Swift Version
1.0.0 ..< 1.11.0	5.0
1.11.0 ..< 1.12.0	5.2
1.12.0 ..< 1.15.0	5.4
1.15.0 ..< 1.17.0	5.5.2
1.17.0 ..< 1.19.0	5.6
1.19.0 ..< 1.21.0	5.7
1.21.0 ...	5.8

swift-nio-transport-services 0.x

The legacy swift-nio-transport-services 0.x is part of the SwiftNIO 1 family of repositories and works with Swift 4.1 and newer. The source code can be found on the swift-nio-transport-services-swift-4-maintenance branch.

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.

swift-nio-transport-services's Issues

Add Async Await support to NIOTSListenerBootstrap childChannelInitializer

Expected behavior

When using NIOTSListenerBootstrap I would expect to be able to provide an async block since the common methods one would call within this have await-able versions. eg channel.pipeline.addHandler.

SwiftNIO version/commit hash

swift-nio==2.33.0
swift-swift-nio-transport-services==1.11.3

Swift & OS version (output of swift --version && uname -a)

swift-driver version: 1.26.9 Apple Swift version 5.5.1 (swiftlang-1300.0.31.4 clang-1300.0.29.6)
Target: x86_64-apple-macosx12.0
Darwin Matthauss-MacBook-Pro-2.local 21.2.0 Darwin Kernel Version 21.2.0: Wed Oct 20 00:23:27 PDT 2021; root:xnu-8019.60.40.0.1~26/RELEASE_X86_64 x86_64

P.S maybe there is an easy way to create an async task connected to the event loop that returns a EventLoopFuture<Void> but I cant find such a method on the channel.eventloop (more of an issue for SwiftNIO repo through)

Could not connect TCP Sever at simulator

Expected behavior

Connect to TCP server at simulator with TCP Client successful

Actual behavior

Failed to connect TCP server at simulator with TCP Client.

The error message show as "2020-08-22 05:55:15.948928+0700 iDine[8523:266860] XPC connection interrupted
2020-08-22 05:57:04.736866+0700 iDine[8523:266862] [ServicesDaemonManager] interruptionHandler is called. -[FontServicesDaemonManager connection]_block_invoke"

Client code

                Button(action: {
                    let client = TCPClient(host: "localhost", port: 9090)
                    do {
                        try client.start()
                    } catch let error {
                        print("Error: \(error.localizedDescription)")
                        client.stop()
                    }
                }) {
                    HStack {
                
                        Text("Login")
                            .font(.title)
                    }
                    .padding()
                    .foregroundColor(.white)
                    .background(Color(red: 0/255, green: 89/255, blue: 121/255))
                    .cornerRadius(20)
                }.padding(.top, 20)

Race condition when closing connection

Background

I have a client-server setup between a macOS app and an iPhone app. The two apps communicate over http and I use swift-nio for much of the implementation. I use swift-nio-transport-services on both sides which enables peer-to-peer connections without much extra work.

I've read a reasonable amount of the example code in the swift-nio repo for figuring out how to put this all together, so I was fairly sure my handler implementations were sound, but I was running into some weird issues (more on that shortly). Digging into this more, I think I've narrowed it down to a difference in how swift-nio-transport-services handles closed connections.

I've put together a repo with two tests, one using transport-services and the other without. The plain nio test passes, whereas transport-services fails.

Expected behavior

• Client issues request to server
• Server reads request, and writes back a fixed, large* response and immediately closes**
• Client reads entire response before closing the connection

^* the large response guarantees that the data is broken up over several read/writes, additionally the client has autoRead = false, and delays the read() call to make the test failure more repeatable.

^** this mirrors the example code here which closes the connection immediately after the final write. this behaves as expected when transport-services is not used.

Actual behavior

• Client issues request to server
• Server reads request, and writes back a fixed, large* response and immediately closes**
• Client begins reading response, then NWConnection switches to an failure state when the connection is closed
• transport-services immediately issues a close() before reading the rest of the response, which breaks reading the full http response and producing an unexpected EOF error to downstream channel handlers

Steps to reproduce

1. Check out https://github.com/brushedtype/nio-test
2. Run the tests and note that the PlainTestClient succeeds, while NIOTSTestClient fails with no differences beyond the bootstrap process and eventloop.

If possible, minimal yet complete reproducer code (or URL to code)

https://github.com/brushedtype/nio-test

SwiftNIO version/commit hash

{
  "object": {
    "pins": [
      {
        "package": "swift-nio",
        "repositoryURL": "[email protected]:apple/swift-nio.git",
        "state": {
          "branch": null,
          "revision": "6aa9347d9bc5bbfe6a84983aec955c17ffea96ef",
          "version": "2.33.0"
        }
      },
      {
        "package": "swift-nio-transport-services",
        "repositoryURL": "[email protected]:apple/swift-nio-transport-services.git",
        "state": {
          "branch": null,
          "revision": "e7f5278a26442dc46783ba7e063643d524e414a0",
          "version": "1.11.3"
        }
      }
    ]
  },
  "version": 1
}

Swift & OS version (output of swift --version && uname -a)

swift-driver version: 1.26.9 Apple Swift version 5.5 (swiftlang-1300.0.31.1 clang-1300.0.29.1)
Target: x86_64-apple-macosx11.0
Darwin Edwards-MBP 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

Adopt new Channel-focused APIs from NIO

There are a few new APIs that we can adopt from NIO

• New synchronous operations for firing events into a pipeline (apple/swift-nio#1908)
• New APIs for detecting whether we're shutting down an event loop that we're actually on (apple/swift-nio#1904)
• New APIs for detecting whether it's safe to wait on a future (apple/swift-nio#1900)
• New APIs for tracking promise creation in debug mode (apple/swift-nio#1899)

We can and should take advantage of all of them.

Make `NIOTSNetworkEvents` initialisers public

Type in the NIOTSNetworkEvents namespace are all public, but users can’t construct them as the initialisers aren’t public. That’s an unnecessary limitation, and it blocks certain kinds of unit testing. We should therefore add public inits to all types in the NIOTSNetworkEvents namespace.

Blocks swift-server/async-http-client#589

Can't build for release on iOS 15

Expected behavior

Should be able to build release build for iOS 15

Actual behavior

Xcode has a build error

Looks like the system Network lib is missing an @available(macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *) in the Network framework however im not sure. Looking at the exposed swift interface this extension should be wrapped in the @ available but maybe a change tho NIOTS would also solve this? Or maybe this is just a compiler bug, normally an extortion that only contains methods with @available does not need its own @available.

extension Network.NWConnection {
  @available(macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *)
  convenience public init?(message: Network.NWConnectionGroup.Message)
  @available(macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0, *)
  convenience public init?(from: Network.NWConnectionGroup, to: Network.NWEndpoint? = nil, using: Network.NWProtocolOptions? = nil)
}

Steps to reproduce

Add a a swift package to an Xcode project import/use it. And build a release build for iOS 15.

SwiftNIO version/commit hash

Swift & OS version (output of swift --version && uname -a)

swift-driver version: 1.26.7 Apple Swift version 5.5 (swiftlang-1300.0.27.6 clang-1300.0.27.2)
Target: x86_64-apple-macosx12.0
Darwin Matthauss-MacBook-Pro-2.local 21.0.0 Darwin Kernel Version 21.0.0: Mon Aug  2 00:18:11 PDT 2021; root:xnu-8019.30.9~9/RELEASE_X86_64 x86_64

Flaky test -[NIOTransportServicesTests.NIOTSChannelOptionsTests testDataTransferReport]

Found via our internal tools:

Test Suite 'Selected tests' started at 2022-05-13 14:38:03.406Test Suite 'swift-nio-transport-servicesPackageTests.xctest' started at 2022-05-13 14:38:03.408Test Suite 'NIOTSChannelOptionsTests' started at 2022-05-13 14:38:03.409Test Case '-[NIOTransportServicesTests.NIOTSChannelOptionsTests testDataTransferReport]' started./private/tmp/nio-release-validator/40A781E9-4756-44F3-A726-64FC412A6572/repos/swift-nio-transport-services/Tests/NIOTransportServicesTests/NIOTSChannelOptionsTests.swift:113: error: -[NIOTransportServicesTests.NIOTSChannelOptionsTests testDataTransferReport] : XCTAssertEqual failed: ("0") is not equal to ("1")Test Case '-[NIOTransportServicesTests.NIOTSChannelOptionsTests testDataTransferReport]' failed (0.293 seconds).Test Suite 'NIOTSChannelOptionsTests' failed at 2022-05-13 14:38:03.702.
	 Executed 1 test, with 1 failure (0 unexpected) in 0.293 (0.294) secondsTest Suite 'swift-nio-transport-servicesPackageTests.xctest' failed at 2022-05-13 14:38:03.702.
	 Executed 1 test, with 1 failure (0 unexpected) in 0.293 (0.294) secondsTest Suite 'Selected tests' failed at 2022-05-13 14:38:03.702.
	 Executed 1 test, with 1 failure (0 unexpected) in 0.293 (0.297) seconds
Command failed reason=exit, status=1

Seems to be happening fairly commonly on macOS only.

Linux CI

We need Linux CI here, sounds silly but #77 and #78 :'(. Just a Swift 5.0 build will do.

Unable to make pre-shared key based wifi socket connection to server on iOS 13 Beta 7

Expected behavior

The handshake should happen on iOS 13

Actual behavior

Handshake is not happening and it failing due to the Error:
PSK_IDENTITY NOT FOUND

Note

Working fine on iOS 12 but it broke on iOS 13

Through OPEN SSL

Even I have tried with [email protected] and it works. and it says CONNECTED.
/usr/local/Cellar/[email protected]/1.1.1c/bin/openssl s_client -connect XXXXX:XXXX -psk 054dd7317f689a3425d5aadfd53771af7987be96 -psk_identity 1002535472 -no_tls1_3 -cipher PSK-AES256-CBC-SHA

Steps to reproduce

1. Simply connect the server with PSK and PSK identity. NIO will throw Timeout Error and in debug console getting Error from the iOS side: PSK IDENTITY NOT FOUND

If possible, minimal yet complete reproducer code (or URL to code)

 do {
            let tlsOptions = NWProtocolTLS.Options()
            
            let storePinHashData = Data(fromHexEncodedString: authProcessInfo.preSharedKeyAsEncodedString)!
            let requestIdData = Data("\(authProcessInfo.pairingRequestId!)".utf8)
                                    
            let psk = DispatchData(data: storePinHashData as Data)
            let pskIdentity = DispatchData(data: requestIdData as Data)

            sec_protocol_options_add_pre_shared_key(tlsOptions.securityProtocolOptions, psk as __DispatchData, pskIdentity as __DispatchData)
             sec_protocol_options_add_tls_ciphersuite(tlsOptions.securityProtocolOptions, TLS_PSK_WITH_AES_256_CBC_SHA)
            
            do {
                try NIOTSConnectionBootstrap(group: self.group)
                    .channelOption(ChannelOptions.socket(SocketOptionLevel(SOL_SOCKET), SO_REUSEADDR), value: 1)
                    .channelOption(ChannelOptions.socket(IPPROTO_TCP, TCP_NODELAY), value: 1)
                    .tlsOptions(tlsOptions)
                    .channelInitializer { channel in
                        channel.pipeline.addHandler(self.handler!)
                }.connect(host: host, port: port).whenFailure({ (error) in
                    print("Error:\(error)")
                })
            }catch(let e) {
                debugPrint("Error:\(e)")
            }
        }catch(let e) {
            debugPrint("Error:\(e)")
        }
    }

Extension Dispatch Data

extension DispatchData {
    public init(data source: Data) {
        self = source.withUnsafeBytes { ptr in
            DispatchData(bytes: ptr)
        }
    }
}

Swift & OS version (output of swift --version && uname -a)

Swift 5.0
iOS 13 Beta 7
Tried both Simulator as well as Device
Swift NIO 2.7.0

Example for Bounjour service announcement would be useful

I've got a swift-nio app working, and I wanted to add mDNS-based service discovery. Basically, advertise my service on the port I already have things listening on (or advertise it on a random port, doesn't really matter). I had hoped it would be just a matter of switching to NIOTSEventLoop, NIOTSListenerBootstrap etc., and then setting up a bootstrap.bind(endpoint: .service(...)), but that doesn't seem sufficient (I don't see the service getting advertised).

It would be really handy to have an example for this use case, since it's probably fairly common.

Support Explicit Congestion Notifications

Expected behavior

ECN data to flow through AddressedEnvelope as it does for regular NIO - see apple/swift-nio#1472

Actual behavior

Code does not exist.

Connecting to a server with a self-signed certificate

Hi,
first up: is this the right place for questions?

I am maintaining the Swift driver for the Neo4j database, and have a SwiftNIO 1 implementation of that with all tests green. Yay. :-) Now I'm in the progress of moving that to SwiftNIO 2.

With SwiftNIO 1 I had set up my channel like this - and that worked very well with self-signing.

I tried using the same pattern with SwiftNIO2:

return channel.pipeline.addHandlers([self.sslHandler], position: .first).flatMap({ () -> EventLoopFuture<Void> in
  return channel.pipeline.addHandlers([dataHandler], position: .last)
})

Here, sslHandler is was set up like with SwiftNIO1:

let configuration = TLSConfiguration.forClient(certificateVerification: .none) // allow self signed
let sslContext = try NIOSSLContext(configuration: configuration)
let sslHandler = try NIOSSLClientHandler(context: sslContext, serverHostname: self.hostname)

But I must have misunderstood something, as I didn't get that to connect at all. My next approach was following the SMTP example:

return NIOTSConnectionBootstrap(group: overrideGroup).channelInitializer { channel in
  return channel.pipeline.addHandlers([dataHandler], position: .last)
 }.tlsConfig()

extension NIOTSConnectionBootstrap {
    func tlsConfig() -> NIOTSConnectionBootstrap {
        return self.tlsOptions(.init())
    }
}

and that connects, but quickly ends: "Alert level: fatal, description: certificate unknown"

Is there a way for me to supply the option that I want a self-signed certificate to be ok? (I assume this was the reason for the error)

To give a bit more context: I'm trying to set up the project so that it will compile both for Ubuntu, macOS, iOS and tvOS. Have I understood it correctly that I'll need to write slightly different implementations using NIOSSL instead of NIOTransportServices for Ubuntu vs the other platforms? Or is there a recommended path for using the same dependency (with both SwiftPM and CocoaPods) that will use the Network framework on macOS/iOS/tvOS and OpenSSL on Linux?

SwiftNIO version/commit hash

At the time of writing I was using commit #687e79828a40978292a89eb0d1caec28571d8ca2 as the latest

Application Crash when attempting to connect to `Ports > UInt16.max`

Expected behaviour

Throw NIOTSErrors.InvalidPort when a port is provided that is larger than UInt16.max

While having a port number larger than UInt16 should not happen. Given the publicly exposed api accepts Int and there is a NIOTSErrors.InvalidPort error exception users using Hypermedia style apis do find themselves at risk of a third party providing a (malformed) URL that crashes the application.

Actual behaviour

Application crash. The Publicly exposed api expects.

Steps to reproduce

1. Attempt to connect to a port number > 65535

If possible, minimal yet complete reproducer code (or URL to code)

Modify https://github.com/apple/swift-nio-transport-services/blob/main/Sources/NIOTSHTTPClient/main.swift#L70 replacing port value with 65536

SwiftNIO version/commit hash

2.25.1

Swift & OS version (output of swift --version && uname -a)

Apple Swift version 5.3.2 (swiftlang-1200.0.45 clang-1200.0.32.28)
Target: x86_64-apple-darwin20.3.0
Darwin Matthauss-MacBook-Pro-2.local 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64

flaky test NIOTransportServicesTests.NIOTSConnectionChannelTests testZeroLengthWritesHaveSatisfiedPromises

Expected behavior

test passes

Actual behavior

test did not pass once :)

Steps to reproduce

1. swift test -Xswiftc -target -Xswiftc x86_64-apple-macosx10.14

SwiftNIO version/commit hash

• swift-nio: 8d7d4cb9ca1c5e4b444f2895254a55b91e85540a
• swift-nio-transport-services: e14a834

Swift & OS version (output of swift --version && uname -a)

$ swift -version
Apple Swift version 4.2 (swiftlang-1000.0.36 clang-1000.10.44)
Target: x86_64-apple-darwin18.0.0
$ sw_vers 
ProductName:	Mac OS X
ProductVersion:	10.14
BuildVersion:	18A377a

Output

Compile CNIOSHA1 c_nio_sha1.c
Compile CNIOAtomics src/c-atomics.c
Compile CNIOLinux shim.c
Compile CNIODarwin shim.c
Compile CNIOLinux ifaddrs-android.c
Compile CNIOHTTPParser c_nio_http_parser.c
Compile CNIOZlib empty.c
Compile Swift Module 'NIOPriorityQueue' (2 sources)
Compile Swift Module 'NIOConcurrencyHelpers' (2 sources)
Compile Swift Module 'NIO' (55 sources)
Compile Swift Module 'NIOFoundationCompat' (1 sources)
Compile Swift Module 'NIOHTTP1' (9 sources)
Compile Swift Module 'NIOTLS' (3 sources)
Compile Swift Module 'NIOTransportServices' (11 sources)
/private/tmp/.nio-release-tools_wcDcXq/swift-nio-transport-services/Sources/NIOTransportServices/NIOTSListenerChannel.swift:386:9: warning: default will never be executed
        default:
        ^
/private/tmp/.nio-release-tools_wcDcXq/swift-nio-transport-services/Sources/NIOTransportServices/NIOTSConnectionChannel.swift:633:9: warning: default will never be executed
        default:
        ^
Compile Swift Module 'NIOTSHTTPServer' (1 sources)
Compile Swift Module 'NIOTSHTTPClient' (1 sources)
Compile Swift Module 'NIOTransportServicesTests' (6 sources)
Linking ./.build/x86_64-apple-macosx10.10/debug/NIOTSHTTPServer
Linking ./.build/x86_64-apple-macosx10.10/debug/NIOTSHTTPClient
Linking ./.build/x86_64-apple-macosx10.10/debug/swift-nio-transport-servicesPackageTests.xctest/Contents/MacOS/swift-nio-transport-servicesPackageTests
Test Suite 'All tests' started at 2018-10-08 6:12:31.603 pm
Test Suite 'swift-nio-transport-servicesPackageTests.xctest' started at 2018-10-08 6:12:31.603 pm
Test Suite 'NIOTSConnectionChannelTests' started at 2018-10-08 6:12:31.603 pm
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testConnectingToEndpointSkipsPipeline]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testConnectingToEndpointSkipsPipeline]' passed (0.090 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testConnectingToHostPortSkipsPipeline]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testConnectingToHostPortSkipsPipeline]' passed (0.003 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testConnectingToSocketAddressTraversesPipeline]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testConnectingToSocketAddressTraversesPipeline]' passed (0.002 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testErrorsInChannelSetupAreFine]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testErrorsInChannelSetupAreFine]' passed (0.001 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testSettingGettingReuseaddr]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testSettingGettingReuseaddr]' passed (0.002 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testSettingGettingReuseport]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testSettingGettingReuseport]' passed (0.002 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testSettingTCPOptionsWholesale]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testSettingTCPOptionsWholesale]' passed (0.003 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testWatermarkSettingGetting]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testWatermarkSettingGetting]' passed (0.002 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testWritabilityChangesAfterChangingWatermarks]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testWritabilityChangesAfterChangingWatermarks]' passed (0.002 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testWritabilityChangesAfterExceedingWatermarks]' started.
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testWritabilityChangesAfterExceedingWatermarks]' passed (0.003 seconds).
Test Case '-[NIOTransportServicesTests.NIOTSConnectionChannelTests testZeroLengthWritesHaveSatisfiedPromises]' started.
Assertion failed: : file /private/tmp/.nio-release-tools_wcDcXq/swift-nio-transport-services/Sources/NIOTransportServices/NIOTSConnectionChannel.swift, line 653
Exited with signal code 4

flaky test `NIOTSChannelOptionsTests.testDataTransferReport`

Tests stop after starting NIOTSChannelOptionsTests.testDataTransferReport:

Test Case '-[NIOTransportServicesTests.NIOTSChannelOptionsTests testDataTransferReport]' started.
Exited with signal code 11
Command failed reason=exit, status=1

normal_debug.log
normal_release.log
It almost always crashes on my system and only sometimes passes.

SwiftNIO version/commit hash

SwiftNIO 2.35.0/37e7a33de45bac894c0b08b56a2f755ebe4884e6

Swift & OS version (output of swift --version && uname -a)

swift-driver version: 1.26.16 Apple Swift version 5.5 (swiftlang-1300.0.38 clang-1300.0.29.20)
Target: x86_64-apple-macosx12.0
Darwin Kernel Version 21.1.0
root:xnu-8019.40.67.171.4~1/DEVELOPMENT_X86_64 x86_64

NIOTSListener.bindPromise is disappearing

Looking at:

swift-nio-transport-services/Sources/NIOTransportServices/NIOTSListenerChannel.swift

Line 282 in fb47fc1

self.close0(error: error, mode: .all, promise: nil)

.

If we fail to create the NWListener, we call self.close0() with the error. Inside close0 we immediately see that self.nwListener is nil, and exit doing nothing else. In this situation, self.bindPromise, aka the promise parameter to beginActivating0() is just left dangling.

I would guess that the catch block should look like this:

self.close0(error: error, mode: .all, promise: nil)
self.bindPromise?.fail(error: error)
self.bindPromise = nil
return

However, I'm not certain that's necessarily the right way to go about it. Any comments? I'm happy to submit the fix if my supposition above is actually correct.

flaky test: testKEEPCNT

Test Case '-[NIOTransportServicesTests.NIOTSSocketOptionsOnChannelTests testKEEPCNT]' started.
/tmp/.nio-release-tools_DGgPWc/swift-nio/Sources/NIO/EventLoopFuture.swift:929: error: -[NIOTransportServicesTests.NIOTSSocketOptionsOnChannelTests testKEEPCNT] : failed: caught error: "connectTimeout(NIO.TimeAmount(nanoseconds: 10000000000))"
Test Case '-[NIOTransportServicesTests.NIOTSSocketOptionsOnChannelTests testKEEPCNT]' failed (10.790 seconds).

on macOS

URGENT : NIOTransportServices / NIOTSConnectionBootstrap is only available in macOS 10.14 or newer

Hi. I have pulled updated my SPM in the past 30min and am getting this error which means I cannot build my entire project

#if swift(>=5.6)
@available(*, unavailable)
extension NIOTSConnectionBootstrap: Sendable {}
#endif

in NIOTSConnectionBootstrap.swift

These is my current Package. I am set to .v12 but it is possible that one of the packages is not. If you can please fix this issue. Thanks.

/////

import PackageDescription

let package = Package(
name: "DM123",
platforms: [
.macOS(.v12)
],
dependencies: [
// 💧 A server-side Swift web framework.
.package(url: "https://github.com/vapor/vapor.git", from: "4.0.0"),
.package(url: "https://github.com/vapor/fluent.git", from: "4.0.0"),
.package(url: "https://github.com/vapor/fluent-mysql-driver.git", from: "4.0.0"),
.package(url:"https://github.com/vapor/queues.git",from: "1.3.2"),
.package(name: "QueuesFluentDriver", url: "https://github.com/m-barthelemy/vapor-queues-fluent-driver.git", from: "2.0.0"),

Expected behavior

[what you expected to happen]

Actual behavior

[what actually happened]

Steps to reproduce

1. ...
2. ...

If possible, minimal yet complete reproducer code (or URL to code)

[anything to help us reproducing the issue]

SwiftNIO version/commit hash

[the SwiftNIO tag/commit hash]

Swift & OS version (output of swift --version && uname -a)

NIOTSChannelOptions doesn't exist

Expected behavior

The documentation references NIOTSChannelOptions to access TPC or TLS configuration

Actual behavior

The above class does not exist

Steps to reproduce

• https://github.com/apple/swift-nio-transport-services/blob/master/Sources/NIOTransportServices/NIOTSConnectionBootstrap.swift#L81
• https://github.com/apple/swift-nio-transport-services/blob/master/Sources/NIOTransportServices/NIOTSConnectionBootstrap.swift#L91
• https://github.com/apple/swift-nio-transport-services/blob/master/Sources/NIOTransportServices/NIOTSListenerBootstrap.swift#L124
• https://github.com/apple/swift-nio-transport-services/blob/master/Sources/NIOTransportServices/NIOTSListenerBootstrap.swift#L134

If possible, minimal yet complete reproducer code (or URL to code)

n/a

SwiftNIO version/commit hash

897eb36 (release 0.2.0)

Swift & OS version (output of swift --version && uname -a)

n/a

ScheduledTask should clear callbacks on cancel (for leak management)

Expected behavior

After a successful connect(), the EventLoopGroup reference shouldn't be held by a task.

Actual behavior

In today's NIO, connect() will end up leaking the entire EventLoopGroup at least until it fires, because on connection completion, the callback (which has a reference to the group) will still stick around.

Steps to reproduce

1. Run a successful connect.
2. Tear down everything.
3. Run leaks (on macOS) on the process. Expect to see no group. See a group.

EventLoop.next() could eventually crash?

In NIOTSEventLoopGroup.swift,

public func next() -> EventLoop {
    return self.eventLoops[abs(index.add(1) % self.eventLoops.count)]
}

I know it's highly unlikely, but wouldn't index eventually overflow and throws a fatal error? Also, why do we need the abs()?

testBasicUnixSockets doesn't delete its UNIX Domain Socket used for tests.

swift-nio-transport-services/Tests/NIOTransportServicesTests/NIOTSEndToEndTests.swift

Line 428 in 6cba688

func testBasicUnixSockets() throws {

Failed to build module 'Network'; this SDK is not supported by the compiler

Expected behavior

I am trying to build for release

Actual behavior

[what actually happened]

Steps to reproduce

1. ...
2. ...

If possible, minimal yet complete reproducer code (or URL to code)

[anything to help us reproducing the issue]

SwiftNIO version/commit hash

2.32.2
[the SwiftNIO tag/commit hash]

Swift & OS version (output of swift --version && uname -a)

swift-driver version: 1.26.5 Apple Swift version 5.5 (swiftlang-1300.0.24.13 clang-1300.0.25.10)
Target: x86_64-apple-macosx11.0
Darwin Saroars-MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64

Xcode 13 beta 5

watchOS build failure

I'm new to swift and iOS development, but from what I've read swift-nio transport services support watchOS since 1.1.0? I'm having trouble building a library that references grpc-swift, and ultimately transport services, with the below build error.

A clone of the repo and attempt to build on Apple Watch Series 5 yields the same result. Just wondering if anyone can shed some light on if this might be an issue or if I have something setup wrong?

Expected behavior

Build success for Apple Watch Series 5 device

Actual behavior

Steps to reproduce

1. Build the package for Apple Watch Series 5

SwiftNIO version/commit hash

2.18.0

Swift & OS version (output of swift --version && uname -a)

Apple Swift version 5.2.4 (swiftlang-1103.0.32.9 clang-1103.0.32.53)
Target: x86_64-apple-darwin19.5.0
Darwin PA90C02Z50WYLVDTC02Z50WYLVDT 19.5.0 Darwin Kernel Version 19.5.0: Tue May 26 20:41:44 PDT 2020; root:xnu-6153.121.2~2/RELEASE_X86_64 x86_64

Cannot get NIO transport services to resolve - still not working :-(

I have the following fragment in my package file:

    dependencies: [
        .package(url: "https://github.com/apple/swift-nio-transport-services.git", from: "1.1.1")
    ],
    targets: [
        .target(
            name: "Simulcra",
            dependencies: ["swift-nio-transport-services"],
        ),

But it won't resolve, telling me "product 'swift-nio-transport-services' required by package 'simulcra' target 'Simulcra' not found."

How do I get this to work?

Edgar

NWConnection and its NWParameters should be exposed for a channel

Expected behavior

This part in the Swift NIO Transport Services README made me assume that I could access the NWConnection and NWParameters of the established channel for a NIOTSListenerBootstrap or a NIOTSConnectionBootstrap.

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.

Basically, I'm looking to get statistics of a connection after its completion, things like NWParameters, NWProtocolMetadata, EstablishmentReports, DataTransferReports etc.

Actual behavior

I cannot find any way to get to these connection details. The class NIOTSConnectionChannel seems to be internal, which prevents me from casting from Channel to that. Basically, all I'm left with is the same amount of connection info I had without NIO TS.

If possible, minimal yet complete reproducer code (or URL to code)

let clientBootStrap = NIOTSConnectionBootstrap(group: context.eventLoop)
      .channelInitializer { channel in
            // no access to NIOTSConnectionChannel here...
      }

SwiftNIO version/commit hash

swift-nio-transport-services version 1.5.1

Swift & OS version (output of swift --version && uname -a)

Apple Swift version 5.2.2 (swiftlang-1103.0.32.6 clang-1103.0.32.51)

NIOFilterEmptyWritesHandler isn't guarded by `if #canImport(Network)`

All of the code in NIOTS should be guarded by if #canImport(Network). However NIOFilterEmptyWritesHandler isn't. Since its intended use is to work around a bug in Network framework, it's only helpful when Network framework is available anyway.

We can't add the check now as it would break API, but we should consider adding the missing compilation check for the next major version of NIOTS.

iPhone

IPv6 variants of our translated socket options aren’t supported

Right now we translate socket options to Network.framework stuff. However, we missed some stuff in IPv6 that should be addressed there.

NIOTS doesn't let you control the equivalent of `maxMessagesPerRead` and `recvAllocator`

swift-nio-transport-services/Sources/NIOTransportServices/NIOTSConnectionChannel.swift

Lines 583 to 585 in 2ac8fde

	// TODO: Can we do something sensible with these numbers?
	self.outstandingRead = true
	conn.receive(minimumIncompleteLength: 1, maximumLength: 8192, completion: self.dataReceivedHandler(content:context:isComplete:error:))

NIOTS always does one underlying receive per read and always up to 8192.

So that kinda corresponds to:

• maxMessagesPerRead = 1
• recvAllocator = AdaptiveRecvAllocator(minimum: 1, maximum: 8192, initial: ???)

We should make those values configurable.

NIOTSEventLoops don't participate in MTEventLoopGroup.currentEventLoop

There are two problems with EventLoopGroup as currently concretely implemented:

1. MultiThreadedEventLoopGroup.threadSpecificEventLoop is a ThreadSpecificVariable, which has unpredictable behavior when used with dispatch queues (which have their own mechanism for the purpose).
2. There is no way for the generic EventLoopGroup protocol to provide an API for expressing a currentEventLoop concept without making that API public.

This has some unfortunate results when any alternate EventLoopGroup - most especially NIOTSEventLoopGroup is in use:

• Invoking EventLoopGroup.syncShutdownGracefully() while still on an event loop will fail to diagnose the problem via precondition as it normally would.
• Misuse of EventLoopFuture.wait() while executing on any event loop will incorrectly report the "current" event loop as nil. In addition, the misuse will only be correctly detected when it takes on the future's own event loop, and even then will suffer even further from NIOTSEventLoop.inEventLoop's "false negative" problem.
• NIOPipeBootstrap.withPipes() similarly fails to diagnose an attempt to bootstrap while on an event loop.

To make matters even more confusing, it's not clear that NIOTSEventLoop could provide a satisfactory implementation of an API for the appropriate check in the first place, given the aforementioned problems experienced by NIOTSEventLoop.inEventLoop. (See https://github.com/apple/swift-nio-transport-services/blob/master/Sources/NIOTransportServices/NIOTSEventLoop.swift#L84-L94 for details on that issue.)

While all of these uses of currentEventLoop are limited to expressing precondition()s (which is exactly as it should be), and thus these failures are not critical, the lack of these diagnostics tends to make debugging more difficult and delays the detection of such issues until after the problem has become worse. This is not a satisfactory state of affairs, given the recommendation that NIOTSEventLoopGroup be preferred over MultiThreadedEventLoopGroup whenever available - users are left with a recommended default which suffers from (admittedly minor) reduced usability.

It is also possible for other alternative EventLoopGroup implementations to exist, such as a threading model specialized for Windows support, or just for the sheer ridiculousness of it, an EventLoop based on Mach threads (yikes). This suggests that the problem would ideally be solved in a fully generic fashion, rather than providing some form of special-case behavior for NIOTS (if that were possible to begin with).

I have not yet come up with any kind of solution which would not require one of:

• Exposing the currentEventLoop as public API (which is obviously undesirable; it would only be misused in the same way dispatch_get_current_queue() historically has been)
• Providing some form of technically public but definitionally private API (as the stdlib does with underscored functions which do not appear in generated interfaces but are nonetheless usable if their names are known)
• Making NIO nominally aware of NIOTransportServices, which would be a massive layering violation and probably impossible anyway given the obvious circular dependency problem. Upwards dependencies are the bane of sensible build systems, ask anyone who's ever complained that they can't switch away from PBXBuild in their legacy Xcode project 🙃.

I would love to discuss alternatives, if anyone has any thoughts.

Docs & code claim that Network.framework treats SO_REUSEADDR & SO_REUSEPORT as the same, don't think that's true

I don't think this comment is right.

swift-nio-transport-services/Sources/NIOTransportServices/NIOTSListenerChannel.swift

Lines 311 to 312 in cefc701

	// Network.framework munges REUSEADDR and REUSEPORT together, so we turn this on if we need
	// either.

That is the equivalent of SO_REUSEADDR. From what I can tell, it's not possible to do SO_REUSEPORT from Network.framework, at least I haven't managed to bind two processes to the same port.

Compile failure on Windows

Expected behavior

The project properly compiles on Windows

Actual behavior

error: missing LinuxMain.swift file in the Tests directory appears in the console

Steps to reproduce

1. Attempt to compile a Vapor project on Windows Swift (using one of the latest development builds from https://github.com/compnerd/swift-build)
2. Note failure

If possible, minimal yet complete reproducer code (or URL to code)

[anything to help us reproducing the issue]

SwiftNIO version/commit hash

1.9.0

Swift & OS version (output of swift --version && uname -a)

C:\SourceCache\redacted\desktop_client\shared\redacted>swift --version
compnerd.org Swift version 5.3-dev (LLVM 145d2f6acb3fff0, Swift 62a6a460594fb07)
Target: x86_64-unknown-windows-msvc

copy-paste error in NIOTSConnectionChannel getOption0 allowLocalEndpointReuse

Looks like a copy-paste mistake here:

swift-nio-transport-services/Sources/NIOTransportServices/NIOTSConnectionChannel.swift

Lines 320 to 323 in e7f5278

	case is NIOTSChannelOptions.Types.NIOTSEnablePeerToPeerOption:
	self.enablePeerToPeer = value as! NIOTSChannelOptions.Types.NIOTSEnablePeerToPeerOption.Value
	case is NIOTSChannelOptions.Types.NIOTSAllowLocalEndpointReuse:
	self.allowLocalEndpointReuse = value as! NIOTSChannelOptions.Types.NIOTSEnablePeerToPeerOption.Value

allowLocalEndpointReuse is being set to the value of NIOTSEnablePeerToPeerOption, not itself.

Though it might not really matter, because from everything I can tell allowLocalEndpointReuse seems to be completely broken on NWListener (ref https://developer.apple.com/forums/thread/129452).

compilation on Linux

Currently SPM has no way of declaring dependency on a package per platform. This makes it impossible to dynamically depend on NIOTS only when on macOS / iOS (forbidding breaking cross-compilation with #if in Package.swift).

SPM should get the ability to declare dynamic dependencies, but until then it could be nice if we had a workaround solution.

I suggest making NIOTS compilable on Linux by wrapping all of the source code in #if canImport(Network). By doing this, packages that want to dynamically rely on NIOTS can safely add it as a dependency to their project, and only attempt to use it within #if canImport(Network)

Errors are not being reported while connection is in activating state

Expected behavior

Errors to be reported back

Actual behavior

If an error occurs NIOTSConnectionChannel.stateUpdateHandler is called with state .waiting(error). At this point if the state is activating the code chooses to do nothing. If this error is a DNS error the only way for the connection to fail after that point is for it to timeout.

Steps to reproduce

1. Using niots branch of https://github.com/adam-fowler/async-http-client/
2. Connect to web address that doesn't exist.
3. A DNS error is sent back from Network.framework but it is ignored

If possible, minimal yet complete reproducer code (or URL to code)

This is taken from async-http-client tests. I just changed "localhost" to "localhost2"

    func testGet() throws {
        let httpBin = HTTPBin()
        let httpClient = HTTPClient(eventLoopGroupProvider: .shared(self.clientGroup))
        defer {
            XCTAssertNoThrow(try httpClient.syncShutdown(requiresCleanClose: true))
            XCTAssertNoThrow(try httpBin.shutdown())
        }

        let response = try httpClient.get(url: "http://localhost2:\(httpBin.port)/get").wait()
        XCTAssertEqual(.ok, response.status)
    }

SwiftNIO version/commit hash

swift-nio-transport-services master branch
swift-nio 2.15.0

Swift & OS version (output of swift --version && uname -a)

Target: x86_64-apple-darwin19.3.0
Darwin Adams-MBP 19.3.0 Darwin Kernel Version 19.3.0: Thu Jan 9 20:58:23 PST 2020; root:xnu-6153.81.5~1/RELEASE_X86_64 x86_64

we need to link the docs from the README.

we need to link the docs from the README.

Is CocoaPods still supported?

I found that the CocoaPods specs are out-dated for all Swift-NIO projects. Are we dropping support for CocoaPods?

Generate docs for NIO Transport Services

Currently the Readme suggests

NIOTS provides an alternative EventLoop, EventLoopGroup, and several alternative Channels and Bootstraps

however there are no links to the actual alternative types provided by swift-nio-transport-services.

Using the ClientBootstrap from swift-nio for example would result in a runtime crash.

Could not cast value of type 'NIOTransportServices.NIOTSEventLoop' (0x1007c5a88) to 'NIO.SelectableEventLoop' (0x100513f90).
2018-11-30 20:24:55.782576+0100 NIOTest[24746:16198029] Could not cast value of type 'NIOTransportServices.NIOTSEventLoop' (0x1007c5a88) to 'NIO.SelectableEventLoop' (0x100513f90).

This is not obvious from going through the documentation.

It would be great if

• swift-nio-transport-services would document its own types that augment those of swift-nio
• the swift-nio documentation could add a note on using different types for users of swift-nio-transport-services

NIOTSListenerBootstrap incompatible with NIOExtras.ServerQuiescingHelper

Expected behavior

I would like to use NIOExtras.ServerQuiescingHelper with NIOTS so I can better handle server quiescing. It works as intended with NIO.ServerBootstrap but not with NIOTSListenerBootstrap

Actual behavior

The process crashes when processing a request:

Fatal error: tried to decode as type Channel but found NWConnection with contents other([C1 127.0.0.1:50360 tcp, interface: lo0, local: 127.0.0.1:50358, legacy-socket, server, path satisfied (Path is satisfied), interface: lo0, scoped]): file /Users/<truncated>/.build/checkouts/swift-nio.git--1696851023008440387/Sources/NIO/NIOAny.swift, line 200

Steps to reproduce

The following code snippet illustrates how to reproduce the crash

1. Create a NIOTS HTTP server and start it
2. Invoke it (e.g. with curl)

If possible, minimal yet complete reproducer code (or URL to code)

import NIO
import NIOTransportServices

let group = NIOTSEventLoopGroup()
let quiesce = ServerQuiescingHelper(group: group)
let serverChannel = NIOTSListenerBootstrap(group: group)
  .serverChannelInitializer { channel in
    // add the collection handler so all accepted child channels get collected
    channel.pipeline.add(handler: quiesce.makeServerChannelHandler(channel: channel))
  }
  .bind([...])
  .wait()

// make a request to the server, this will trigger the above crash.

SwiftNIO version/commit hash

NIO: 2.1.1
NIOTS: 1.0.2
NIOExtras: 1.1.0

Swift & OS version (output of swift --version && uname -a)

Apple Swift version 5.0.1

xcodebuild is failed

Expected behavior

My framework project uses Hedera-Protobuf-Swift which uses grpc-swift and it has a dependencies with swift-nio libraries including swift-nio-transport-services.
I don't use NIOCore in my code and there is no problem.
It is ok when I build and run on xcode and it should be successful with xcodebuild command.

Actual behavior

xcodebuild command build fails with error log which ends with following lines.

...
swift-nio-transport-services.build/Release-iphoneos/NIOTransportServices.build/Objects-normal/armv7/TCPOptions+SocketChannelOption.bc
<unknown>:0: error: module map file '/Users/chris/Library/Developer/Xcode/DerivedData/myproject-exsbzxdqjxcopweabsmmudoygaip/SourcePackages/checkouts/swift-nio-transport-services/build/GeneratedModuleMaps-iphoneos/CNIODarwin.modulemap' not found
<unknown>:0: error: module map file '/Users/chris/Library/Developer/Xcode/DerivedData/myproject-exsbzxdqjxcopweabsmmudoygaip/SourcePackages/checkouts/swift-nio-transport-services/build/GeneratedModuleMaps-iphoneos/CNIOLinux.modulemap' not found
<unknown>:0: error: module map file '/Users/chris/Library/Developer/Xcode/DerivedData/myproject-exsbzxdqjxcopweabsmmudoygaip/SourcePackages/checkouts/swift-nio-transport-services/build/GeneratedModuleMaps-iphoneos/CNIOAtomics.modulemap' not found
/Users/chris/Library/Developer/Xcode/DerivedData/myproject-exsbzxdqjxcopweabsmmudoygaip/SourcePackages/checkouts/swift-nio-transport-services/Sources/NIOTransportServices/NIOFilterEmptyWritesHandler.swift:15:8: error: no such module 'NIOCore'
import NIOCore
       ^

** BUILD FAILED **


The following build commands failed:
	CompileSwift normal arm64 (in target 'NIOTransportServices' from project 'swift-nio-transport-services')
	CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler (in target 'NIOTransportServices' from project 'swift-nio-transport-services')
	CompileSwift normal armv7 (in target 'NIOTransportServices' from project 'swift-nio-transport-services')
	CompileSwiftSources normal armv7 com.apple.xcode.tools.swift.compiler (in target 'NIOTransportServices' from project 'swift-nio-transport-services')
(4 failures)

Steps to reproduce

1. My project uses Package Manager and it has hedera-protobuf-swift library which has a dependencies on grpc-swift and it seems that it uses swift-nio libraries.
2. In the terminal, I run following command.

xcodebuild -target myproject BITCODE_GENERATION_MODE=bitcode OTHER_CFLAGS="-fembed-bitcode" ONLY_ACTIVE_ARCH=NO -configuration Release -sdk iphoneos BUILD_DIR=./build clean build

If possible, minimal yet complete reproducer code (or URL to code)

[anything to help us reproducing the issue]

SwiftNIO version/commit hash

grpc-swift 1.6.1
swift-nio 2.36.0
swift-nio-extras 1.10.2
swift-nio-http2 1.19.1
swift-nio-ssl 2.17.1
swift-nio-transport-services 1.11.3

[the SwiftNIO tag/commit hash]

Swift & OS version (output of swift --version && uname -a)

swift-driver version: 1.26.21 Apple Swift version 5.5.2 (swiftlang-1300.0.47.5 clang-1300.0.29.30)
Target: x86_64-apple-macosx11.0
Darwin Chriss-MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

XCode Version 13.2.1 (13C100)

Implement and fire waiting for connectivity event

NIOTS adopts the Network.framework recommendation of waiting for connectivity wherever possible, rather than failing connection establishment in cases where connectivity is not available. That's a good default, but we don't do a good job of communicating when we enter that state. In particular, there is this branch of the code:

swift-nio-transport-services/Sources/NIOTransportServices/NIOTSConnectionChannel.swift

Lines 686 to 692 in 2ac8fde

	case .waiting(let err):
	if case .activating = self.state, self.options.waitForActivity {
	// This means the connection cannot currently be completed. We should notify the pipeline
	// here, or support this with a channel option or something, but for now for the sake of
	// demos we will just allow ourselves into this stage.
	break
	}

that could take this opportunity to send an event down the channel pipeline.

This event would only be observed by handlers added in channelInitializer (the connect promise doesn't fire until the connection actually comes up), but that's probably sufficient. This information would allow users to implement the equivalent of URLSessionTaskDelegate.urlSession(_:taskIsWaitingForConnectivity), which is potentially very valuable.

See also grpc/grpc-swift#831.

Adding to iOS project hides all simulators and devices

Expected behavior

I'm building a framework project and I expected to be able to still compile and unit test.

Actual behavior

Adding NIO Transport Services changes the scheme icon to a cog and says there are no devices available.

How do I add this project to a iOS project?

There is no typed bind function that takes a unixDomainSocketPath

Expected behavior

NIOTSListenerBootstrap has all the typed bind functions that ServerBootstrap has.

Actual behavior

NIOTSListenerBootstrap.bind(unixDomainSocketPath:cleanupExistingSocketFile:serverBackPressureStrategy:childChannelInitializer:) does not exist

SwiftNIO version/commit hash

swift-nio-transport-services v1.20.0

should have api docs

we should have API docs for this at http://docs.swiftnio.io

master doesn't compile with 10.14 SDK

NWEndpoint.url isn't in the 10.14 SDK.

Support for datagram packets

Expected behavior

I expect the UDP to be supported.

Actual behavior

It's not implemented 😬

Steps to reproduce

1. Open Xcode or the docs
2. Look for UDP, Datagram or DGram in this repository
3. Successfully find nothing

SwiftNIO version/commit hash

1.1.1

[Cocoapods] is not up to date

Expected behavior

Cocoapods synchronized with last release

Actual behavior

Last release is 1.0.1 and Cocoapods is 1.0.0

Steps to reproduce

1. Open Cocoapods link and check version number
2. Open release link and check version number

SwiftNIO version/commit hash

3d0713d => The current last version in 1.0.1

Don’t use DispatchQueue.sync for local/remote socket addresses

When loading local/remote socket addresses from off the loop, we use DispatchQueue.sync. This is not a good idea: in particular, inEventLoop can softly false-negative, and in that case we can sync to a queue we’re already on and fail hard.

We should use locks instead.