### Motivation:
The datagram-related types logically mirror the TCP-based ones
(`NIOTSDatagramListenerBootstrap` vs `NIOTSListenerBootstrap`;
`NIOTSListenerChannel` vs `NIOTSDatagramListenerChannel`;
`NIOTSDatagramChannel` vs `NIOTSDatagramConnectionChannel`;
`NIOTSDatagramBootstrap` vs `NIOTSConnectionBootstrap`).
However, some of the type names could more closely resemble their TCP
counterparts to make it easier to navigate the code/understand what
their purpose is.
Additionally, the docs for some of these types are wrong, as they've
been copy-pasted into the datagram versions without changes.
### Modifications:
There are separate commits for each of the following changes:
- Fix docs for `NIOTSDatagramListenerBootstrap` and rename the file to
match the type name.
- Rename `NIOTSDatagramConnectionChannelTests` to
`NIOTSDatagramBootstrapTests` (to match `NIOTSBootstrapTests`).
- Rename `NIOTSDatagramChannel` to `NIOTSDatagramConnectionChannel` (to
match `NIOTSConnectionChannel`)
- Fix docs for `NIOTSConnectionBootstrap`.
- Rename `NIOTSDatagramBootstrap` to `NIOTSDatagramConnectionBootstrap`
(to match `NIOTSConnectionBootstrap`). This one required a deprecate and
replace since it's a public type.
### Result:
Better docs and more consistency in our type names.
Allow users to provide a closure taking an `NWParameters` to customise
them before they're used to create `NWConnection`s.
### Motivation:
`NWParameters` are currently created using the provided TLS and UDP
options, and then passed over to new `NWConnection`s. However, there are
more ways in which `NWParameters` can be customised, so this new API
provides a way for users to do this.
### Modifications:
Introduce new `configureNWParameters` methods to the existing bootstraps
to allow configuring a closure for customising `NWParameters`.
### Result:
Users can now customise the `NWParameters` used to create new
`NWConnection`s.
Motivation:
Dispatch wasn't imported in `NIOTSSingletons.swift` where `.default` was
used for the default QoS. This causes some build issues.
Modifications:
- Add missing Dispatch import
Result:
Fewer build issues
---------
Co-authored-by: Cory Benfield <lukasa@apple.com>
### Motivation:
To migrate to GitHub actions and centralised infrastructure.
### Modifications:
Changes of note:
* Adopt swift-format using rules from SwiftNIO. Modified so that it
ignores `NoAssignmentInExpressions` in some `XCTAssert` functions.
* Remove scripts and docker files which are no longer needed
### Result:
Feature parity with old CI.
Motivation:
Users are stuck with the hardcoded parameters for receiving data from a
connection.
Modifications:
- Add new options to `NIOTSChannelOptions` for configuring how to
receive data from a connection.
Result:
Users can configure how they receive data from a connection.
### Motivation:
Allow different devices to leverage the capabilities of Mutipath TCP
(MPTCP) to enhance the network reliability. Thanks to MPTCP, a
connection can for example automatically migrate to another interface if
it deteriorates on the first one. This can be especially interesting on
MacOS X and iOS, where devices may frequently benefit from multiple
interfaces (ethernet + Wi-Fi for Macs and Wi-fi + cellular for iOS).
Allowing developers to enable MPTCP on their connections seems thus like
a fine addition to this library.
### Modifications:
Added a function "withMultipath" on NIOTSConnectionBootstrap, that allow
to configure the type of service used for MPTCP (defaults to disabled).
This value will be stored in a field, and then propagated to the
underlying channel when the connect method will be called. Also updated
the parameters field of NIOTSConnectionChannel to set the
multipathServiceType accordingly.
### Result:
Users will now be able to easily enable Multipath TCP, allowing them to
benefit from seamless handover, interactive mode to automatically use
the lowest delay interface or aggregate mode to send data in parallel on
both interfaces.
Example:
```swift
let group = NIOTSEventLoopGroup()
defer {
try! group.syncShutdownGracefully()
}
let bootstrap = NIOTSConnectionBootstrap(group: group)
.withMultipath(.handover) // set handover mode
.channelInitializer { channel in
channel.pipeline.addHandler(MyChannelHandler())
}
try! bootstrap.connect(host: "example.org", port: 12345).wait()
/* the Channel is now connected */
```
Co-authored-by: Cory Benfield <lukasa@apple.com>
# Enhancement: Integration of Viability Handler in `Network.framework`
We have successfully integrated the `viabilityUpdateHandler` from
`Network.framework` into `NIOTransportServices`, enabling developers to
leverage the full potential of the `Network.framework` API.
This enhancement provides adopters with critical insights into the
viability of connections to remote endpoints. By being informed about
the current network status, developers can implement a more responsive
and adaptive approach to network behavior and conditions.
## Modifications
- Introduced two new methods along with corresponding calls to these
methods within the `Network.framework` handler.
- These handlers trigger the `NIO` *InboundEventsTriggered* method,
allowing consumers to respond to network changes effectively.
- Developed two structs within *NIOTSNetworkEvents* to accompany the
*InboundEventsTriggered* methods, ensuring seamless data transfer.
- Conformed these structs to Sendability for compatibility with the
required operating systems.
## Result
Clients can now receive viability events from `Network.framework`,
enhancing their ability to manage network connections dynamically
---------
Co-authored-by: George Barnett <gbarnett@apple.com>
Co-authored-by: Cory Benfield <lukasa@apple.com>
Motivation:
In some cases users may want to access APIs we haven't exposed
in NIOTransportServices. We should have a fallback that allows users
to do this.
Modifications:
- Add ChannelOptions for getting NWConnection and NWListener.
Result:
Users have an escape hatch
Motivation:
Looks like when we previously added syncOptions support to our
channels, we had a few issues. The listeners had code added, but
the code never worked. This is because the code was defined in
subclasses, but the protocol conformance comes from the parent class,
and that parent class did not have a customized protocol witness.
The datagram channel was also entirely missing its support.
Modifications:
- Added the missing unit tests for sync options.
- Added syncOptions to StateManagedListenerChannel base class.
- Added overrides to the listener subclasses.
- Added syncOptions to datagram channel
Result:
Sync options actually work across the board.
# Motivation
After the recent changes in NIO where we introduced the `executeThenClose` method on the `NIOAsyncChannel` our tests here became flaky since we were waiting for something to happen but potentially closed the client channels before we wrote out the data.
# Modification
This PR makes sure we are awaiting for the event in the `executeThenClose` scope; hence, making sure we are not closing the client channels too early.
# Result
Less flakey tests.
# Motivation
We missed a few availability guards in our tests which caused errors when compiling for older Darwin platforms. Additionally the latest NIO release deprecated a few APIs on `NIOAsyncChannel`.
# Modification
This PR adds the missing guards and fixes all of the deprecation warnings.
# Result
We should build on all supported platforms again
* Revert "Back out SPI(AsyncChannel) changes"
This reverts commit 33d2b2993f.
* Add new typed async bootstrap APIs back and drop SPI
# Motivation
We just merged the removal of the `AsyncChannel` SPI in NIO and can now add back the new APIs in transport services as well.
# Modification
This PR brings back the previous SPI and promotes it to API.
# Result
New typed async bootstraps API for `NIOTransportServices`.
* George review
* Fire the pipelines error caughted method when NWConnection's state changes to failed
* Added check if failed error is ChannelError.eof and added a unit test for forwarding failed connnection state errors
* Completing a promise for the error caught
* Fixed Typo
* Removed whitespace
* Binding the listener to port 0 and connecting to listerner's localAddress
Motivation:
The datagram tests use a handler which sets its event loop in
`channelRegistered`. A function on the handler is called which relies on
the EL being set. However, this can race: the function can be called
before `channelRegistered` is called.
Modifications:
- set the EL in `handlerAdded`
Result:
Fewer crashes
Motivation:
This change was made because UDP support was lacking on iOS. It's needed by my DNS client implementation, which I am in turn using for an iOS app I'm working on relying on SRV typed records.
Modifications:
Adds a NIOTSDatagramListenerBootstrap for making UDP services
Adds a NIOTSDatagramListenerChannel that accepts UDP connections
Adds a NIOTSDatagramChannel for UDP client connections
Adds a NIOTSDatagramBootstrap that can create a new UDP client
# Motivation
We want to release a new `NIOTS` version without the SPI changes for now.
# Modification
This PR backs out the new `NIOAsyncChannel` APIs.
# Result
No more SPI usage so we can safely release.
# Motivation
We had some breaking changes in the NIO AsyncChannel SPI which we have to adapt here.
# Modification
This PR updates to the latest AsyncChannel SPI
# Result
No more warnings and errors when building.
# Motivation
After my recent PR we failed to compile on 5.6 since the compiler isn't capable to infer the return type of one of the closures.
# Modification
This PR adds the closure's return type explicitly.
# Result
Compiling on 5.6 again
# Motivation
We introduced some breaking SPI(AsyncChannel) changes in NIO that we have to adopt here.
# Modification
This PR adopts the latest `NIOProtocolNegotiationResult` APIs. Additionally, it also drops all bind/connect methods on the bootstraps that are specific to protocol negotiation or `NIOAsyncChannel`.
# Result
Green CI on `main` and alignment between `NIOPosix` and `NIOTS.
# Motivation
We introduced a new configuration struct for `NIOAsyncChannel` to make handling and configuring it easier.
# Modification
This PR adopts the new APIs.
# Result
Less boilerplate in our bootstrap methods
* Extract the NWConnection code into StateManagedNWConnectionChannel
* Add a general setup for NWListener implementations
* Add support for UDPOptions as a NWOptionsProtocol type
* Complete the rebase to main
* Fix nits from PR review
* Clean up some of the invalid rebase
* Async methods for `NIOTSListenerBootstrap` and `NIOTSConnectionBootstrap`
# Motivation
We want to support async bootstrapping with all our bootstraps.
# Modification
This PR adds support for the `NIOTSListenerBootstrap` and `NIOTSConnectionBootstrap`. It also adds the three variants of methods to it (abstract output, `NIOAsyncChannel` based and protocol negotiation based)
# Result
We now support asynchronous interaction with the `NIOTSListenerBootstrap` and `NIOTSConnectionBootstrap`
* Use protocolHandlers properly
* Update NIO version
* code review
* REview
* Doc indention
Motivation
As we've rolled out support for multicast on Linux, it makes sense to
add equivalent configuration for swift-nio-transport-services. The two
features aren't one-to-one, as Network.framework has substantially more
capability than the Linux functionality.
Modifications
- Expose a multipathServiceType channel option
- Add a test to confirm we use it properly
Result
Multicast service types are available.
Motivation:
#fileID introduced in Swift 5.3, so no longer need to use #file anywhere
Modifications:
Changed #file to #filePath or #fileID depending on situation
* Allow retrieval of metadata for a specific protocol from the underlying `NWConnection`
* Address review comments
* Address review comment
* Add availability annotation to tests
* Rename `NIOTSChannelIsNotATransportServicesChannel ` to `NIOTSChannelIsNotANIOTSConnectionChannel `
Motivation:
Lock has been deprecated in favour of NIOLock. Warnings aren't great.
Modifications:
- Replace Lock with NIOLock
- Update the minimum required NIO version to 2.42.0.
Result:
Everything builds cleanly
NIO Transport Services is not capable of launching services with existing NWConnection or NWListener objects. Being able to get
an existing NWConnection through a connection bootstrap and into a channel is a useful capability for advanced use cases.
Modifications:
* Added an option to bootstrap with existing NWListener and NWConnection
* Completed promise connection earlier within NIOTSChannels when AlreadyConfigured is called
* Added test with new NWConnection and NWListener to register Channels
Result:
Able to create and register a channel using an existing NWListener and NWConnection
Motivation
Documentation is nice, and we can help support users by providing useful
clear docs.
Modifications
Add Docc to 5.6 and later builds
Make sure symbol references work
Add overview docs
Result
Nice rendering docs
Motivation:
When we're waiting for connectivity, the user might tell us that they
aren't interested in waiting. In that case we take advantage of the
signal and close early.
However, the code as-written had a bug: we didn't care whether the user
told us they _didn't_ want to wait, or they _did_: we just closed
because they had an opinion! That's no good! We should only close if
they don't want to wait.
Modifications:
- Only close if the user doesn't want to wait.
- Add tests
Result:
We won't close if users don't want us to.
Motivation:
Private Relay kicks in to secure unencrypted data transfers, and
connections to port 80 are a good signal. As a result, the current
construction of this test will invoke Private Relay and attempt to route
over it.
While Private Relay is in beta this is a bad outcome, as it risks
causing bugs in unusual network scenarios. So let's tell Private Relay
we don't need it.
Modifications:
Pretend we're gonna connect to 443 instead.
Result:
More reliable test.
Motivation:
With NIO 2.32.0 we broke the core NIO module up into modules that split
apart the POSIX layer and the core abstractions. As a result, this
package no longer needs to express a hard dependency on the POSIX layer.
Modifications:
- Rewrote imports of NIO to NIOCore.
- Added NIOEmbedded imports where necessary in tests.
- Note that the main package still _depends_ on NIO, which is necessary
for backwards-compatibility reasons. This dependency is unused.
Result:
No need to use NIOPosix.
Motivation:
NIO 2.27.0 added optional support for synchronous channel options.
NIOTSListenerChannel and NIOTSConnectionChannel should support this.
Modifications:
- Add synchronous options for NIOTSConnectionChannel and
NIOTSListenerChannel
- Avoid an allocation in 'getOption' for each channel if the caller is
already on the right event loop by using 'makeSucceededFuture'
- Remove a no longer used internal function and an already dead private
helper
Result:
- Support for sync options and fewer allocations
Motivation:
We shouldn't crash if the user gives us a bad port.
Modifications:
- Check the ports are in-band before we move on.
Result:
We won't crash.
Motivation:
The zero-length writes handler will crash if it receives channelInactive
before channelActive. Sadly, that's totally possible if a channel is
closed from the connect promise.
Modifications:
- Tone back the preconditions a bit.
- Add a test that triggers this path.
Result:
Channel handler behaves better on early close
Motivation:
Network.framework will crash when we attempt to connect to the host
string "". That's not ideal, so we should detect that case and avoid it.
Modifications:
- Add code to detect the empty host string.
Result:
No crashes when accidentally connecting to "".
Motivation:
The NetworkFramework directly supports the concept of allowLocalEndPointReuse. Currently to get through the nio system, this is mapped to the SO_REUSEADDR option.
Now there is a shorthand option for this, it is sad to map from allowLocalEndPointReuse to SO_REUSEADDR and back again.
Modifications:
Add a new NIOTS channel option for this setting.
Set the underlying based on any of new setting, reuseAddr or reusePort.
Add a override to interpret the shorthand option directly into the new option.
Add shorthand options for client with tests of equivalence to long options.
Result:
Behaviour is identical but we can feel happier that the option mapping is less confusing.
Motivation:
On Apple's devices it is considered a best practice to wait for network
connectivity in cases when a connection request cannot immediately be
satisfied, rather than erroring out. This reflects the dynamic and fluid
network environment on Apple devices, with their many network interfaces
and complex interactions between radios, VPNs, and network devices.
While NIOTS supports this model of interaction (and indeed uses it out
of the box), and supports configuring it (by setting
`NIOTSChannelOptions.waitForActivity`), a key pillar is missing:
observability. Right now we don't actually _tell_ the user when we're
waiting for connectivity. This makes it difficult to act on this
information.
Modifications:
- Added a user event, `NIOTSNetworkEvents.WaitingForConnectivity` that
is fired when connectivity could not be established, but the situation
may change in future.
Result:
Our users can tell their users when they're waiting for something!
* Initial draft implementation of new channel options for NWConnection.currentPath, metadata for a given NWProtocol, establishment report and data transfer report. Add a new error for not existing connection. Add tests for all of these. The data transfer report option has to be implemented in another way, as the collection of the final data transfer report does not seem very straightforward.
* Fix incorrect available attributes. Make the Value of NIOTSEstablishmentReportOption an EventLoopFuture returning an optional report. Move handling of NIOTSEstablishmentReportOption and NIOTSDataTransferReportOption to getOption0. Remove nwConnection0().
* Use full type on currentPath too.
* Add a DispatchQueue to do collect of the pending data transfer report, use a DispatchGroup to wait for completion of report collection. Remove redundant attribute. Fix nits related to spacing and file header.
* Fix available attributes for tests too.
Motivation:
Today, we just expect the ELGs passed to the bootstraps to be the
correct ones, if not, we crash.
Modifications:
Offer an alternative validatingGroup: init that just returns nil
if the ELGs are of the wrong types.
Result:
Easier to work with multi-stack systems for example when the user might
pass an ELG for either NIO on Sockets or NIO on Network.framework.
This is the NIOTS companion for https://github.com/apple/swift-nio/pull/1464
Add filter removing empty writes to remedy a bug in Network Framework. This is a work in progress, after some initial discussions and suggestions by @weissi.
Motivation:
There is a known bug in Network Framework affecting iOS devices, which will stall a TCP connection after an empty, zero length write. This bug is not found in Network Framework on MacOS. While the bug fix will be rolled out in future versions of iOS it may take some time. Also, to better support the current and older versions of iOS where the bug remains, @weissi suggested to add a ChannelOutboundHandler, that filters out empty writes.
Modifications:
Add a FilterEmptyWritesHandler, which on affected iOS versions can be added by default to all Channels.
Unit tests for all additions and modifications.
Result:
With this workaround NIOTransportServices can support all iOS versions with Network Framework.
Motivation:
Syncing onto the event loop queues is essentially never acceptable: we
can't appropriately guard against it going terribly wrong.
Modifications:
- Use locks instead, locks are good.
Result:
Removes some crashes.
Resolves#70.
Gus Cairo
George Barnett
Rick Newton-Rogers
Clinton Nkwocha
Anthony Doeraene
Cartisim Development
Cory Benfield
Si Beaumont
Franz Busch
Joannis Orlandos
Johannes Weiss
carolinacass
David Nadoba
David Nadoba
Peter Adams
Pasi Salenius
Marcus Liotta