* Extract the NWConnection code into StateManagedNWConnectionChannel
* Process cory's feedback
* Remove dead code whose functionality is already handled by the helper protocol
* Make the address cache non-locked, because its lock has been moved to the accessors
* Move getting the Multipath option into the TCP channel, re-introduce the underscores to the addressCache properties
* Drop the umbrella import
---------
Co-authored-by: Cory Benfield <lukasa@apple.com>
* 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
* Drop support for Swift 5.5
Signed-off-by: Si Beaumont <beaumont@apple.com>
* fixup: Next version will be 1.17.0
Signed-off-by: Si Beaumont <beaumont@apple.com>
---------
Signed-off-by: Si Beaumont <beaumont@apple.com>
Motivation:
- NIOTSConnectionBootstrap was extended to be marked as non-Sendable,
this extenion missed the availability annotations.
Modifications:
- Add appropriate availability annotation
Result:
Resolves#159
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:
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:
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 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:
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
Motivation:
We can remove a couple of unnecessary flatMap { $0 } operations by way
of using flatSubmit, added in NIO 2.9.0.
Modifications:
- Replace flatMap { $0 } with flatSubmit().
Result:
Remove some code noise.
Motivation:
NIO on BSD Sockets had an issue where it wouldn't tolerate futures from
foreign EventLoops being returned from the channel initializers. NIOTS
should also have a test that tests this situation despite the fact that
it didn't have the same bug.
Modification:
- add a test case
- add more assertions
Result:
Better tests.
* Lower EventLoopGroup requirements for creating bootstraps
Motivation:
In NIO `ClientBootstrap` and `ServerBootstrap` are initialized with an
`EventLoopGroup`. Since `EventLoop` conforms to `EventLoopGroup` you can
initialize an bootstrap with an existing event loop. In NIO Transport
Services the bootstraps are initialized with a `NIOTSEventLoopGroup` and
as `NIOTSEventLoop` conforms to `EventLoop` and by extension
`EventLoopGroup` (but not `NIOTSEventLoopGroup`) it is not possible to
initialize a bootstrap with a pre-existing `NIOTSEventLoop`.
Modifications:
Change the bootstrap initializers to accept an `EventLoopGroup`.
Result:
NIO Transport Services bootstraps can be initialized with a
`NIOTSEventLoop`.
Motivation:
Networking software like SwiftNIO that always has explicit flushes
usually does not benefit from having TCP_NODELAY switched off. The
benefits of having it turned on are usually quite substantial and yet we
forced our users for the longest time to enable it manually.
Quite a bit of engineering time has been lost finding performance
problems and it turns out switching TCP_NODELAY on solves them
magically.
Netty has made the switch to TCP_NODELAY on by default, SwiftNIO should
follow. This patch is the equivalent of apple/swift-nio#1020.
Modifications:
Enable TCP_NODELAY by default.
Result:
If the user forgot to enable TCP_NODELAY, their software should now be
faster.
Motivation:
With Network.framework becoming available on watchOS, you should now be
able to run your favourite NIO applications on watchOS 6!
Modifications:
Updated availability annotations to allow NIO TS.
Result:
More NIO on more watches
* Annotate code with availability attributes
Motivation:
It was not possible to import NIOTS into a project where
Network.framework was not supported by all deployment targets.
Modifications:
All NIOTS code, where applicable, was annotated with availability
attributes.
Result:
It is possible for application developers to import NIOTS on platforms
which do not support Network.framework without a compile time error.
Motivation:
While we fixed a bug in SwiftNIO about setting multiple options of the same type in
apple/swift-nio#597, we never brought a fix for that issue forward. We did aim to resolve
this in SwiftNIO 2.0 by providing ChannelOptions.Storage, but unfortunately we forgot to
make the initializer for that type public (see apple/swift-nio#988). While SwiftNIO core
has to get its ducks in a row, users of this library should still be able to set more than
one socket option, in my humble opinion.
Modifications:
- Ported over ChannelOptions.Storage until apple/swift-nio#988 is fixed.
- Transitioned our code to use it.
- Tested it works.
Result:
Users can set multiple channel options.
Motivation:
NIOTS will not work on Linux but we can at least make it not fail
compilation when compiled on Linux. That way consumers of the API can
depend on NIOTS but make sure they only use NIOTS when wrapped in a
`#if canImport(Network)` block.
Modification:
Guard everything by `#if canImport(Network)`
Result:
This package will now build on Linux (without providing any useful
code).
Motivation:
Compiling code is good so let's make it compile again with the latest
NIO APIs.
Modifications:
- made NIOTS use `_NIO1APIShims`
- clicked 'Fix All' a couple of times to adjust the API
Result:
Code compiles again
Motivation:
SwiftPM from Swift 5.0 brings targets that only support certain systems
which is really handy for this package as it only support macOS 10.14+
and iOS/tvOS 12+
Modifications:
- made use of the Swift 5.0 manifests which can have restrictions on the
supported platforms
- adapted to NIO 2
Result:
- better development story
- using the latest & greatest