Added buffer pool to NIOTSConnectionChannel for reading messages.
### Motivation:
In order to avoid creating a new `ByteBuffer` for every single message
read from the channel, we decided to reuse the
`NIOPooledRecvBufferAllocator` type from NIOCore to leverage a pool of
buffers.
### Modifications:
Used the buffer allocation mechanism provided by the
`NIOPooledRecvBufferAllocator` to reuse and adapt previously created
receive buffers.
### Result:
Channel reads can now reuse previously created buffers, avoiding
unnecessary overhead by creating new buffers every single time.
Motivation:
Swift 5.9 is no longer supported, we should bump the tools version and
remove it from our CI.
Modifications:
* Bump the Swift tools version to Swift 5.10
* Remove Swift 5.9 jobs where appropriate in main.yml, pull_request.yml
Result:
Code reflects our support window.
Current strict concurrency checks don't work consistently in Xcode. This
PR adds an additional flag (`-Xfrontend`) to our set of strict
concurrency flags to make sure nothing has been missed when building. It
also fixes an additional error uncovered after adding it.
Enable MemberImportVisibility check on all targets. Use a standard
string header and footer to bracket the new block for ease of updating
in the future with scripts.
### 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.
This reverts commit 40ffcdef46 in PR #209.
Unfortunately, Swift's behaviour around imports tends to be somewhat
"leaky". In this case, the leak is that the dependency on the
Package.swift allows downstream projects to import `NIOFoundationCompat`
without needing to actually specify the package dependency. This has
affected Hummingbird, which we noticed on our internal integration
testing functionality:
```
hummingbird/Sources/Hummingbird/Codable/JSON/JSONCoding.swift:18:8: error: no such module 'NIOFoundationCompat'
import NIOFoundationCompat
^
```
cc @Joannis @adam-fowler for the Hummingbird report.
Unfortunately, we can't make this change until we're willing to use a
semver major to achieve it. There may be some argument for doing that
now, as the semver major will be very cheap to adopt across the
ecosystem. But we'll need to do this in a considered way.
@Cyberbeni please feel free to reopen your PR targetting main, where we
can discuss whether this is worth issuing a semver major for.
Don't depend on NIOFoundationCompat in NIOTransportServices on Linux
### Motivation:
I'm trying to build a small utility tool based on mqtt-nio which depends
on NIOTransportServices. I noticed that NIOTransportServices depends on
NIOFoundationCompat on all platforms but only imports it where the
Network framework is available. Removing this dependency on non-Apple
platforms allows us to not import Foundations, significantly reducing
the size of the build product when using the Swift Static Linux SDK.
### Modifications:
This PR and a similar one to mqtt-nio.
### Result:
Hello world docker image depending on mqtt-nio went from 169MB to 85MB.
Motivation:
Swift Package Index builds our docs for us and will automatically insert
the dependency.
Modifications:
- Remove the docc-plugin dependency
Result:
Fewer dependencies
# 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
Motivation:
Now that Swift 5.9 is GM we should update the supported versions and
remove 5.6
Modifications:
* Update `Package.swift`
* Delete the 5.6 docker compose file and make a 5.10 one
* Update docs
Result:
Remove support for Swift 5.6, add 5.10
# 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
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
* 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
`swift-nio` has deprecated `NIOPreconcurrencySendable` in `2.51.0`. Removing the protocol conformance would be an API breaking change. Keeping the conformance is low cost and not worth the risk.
### Changes
- replace `NIOPreconcurrencySendable` with underscore version `_NIOPreconcurrencySendable`
### Result
We compile again with the latest `swift-nio` release without warnings
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
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
As outlined in a [Swift forums post in November ’21](https://forums.swift.org/t/swiftnio-swift-version-support/53232), SwiftNIO will only support the latest non-patch Swift release and the 2 immediately prior non-patch versions.
- drop support for Swift 5.2 and 5.3.
- update CI for Swift 5.4 to run on bionic instead of focal to ensure that we still test bionic.
- add a CI job for Swift 5.7
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:
`removeHandlers(channel:)` was deprecated in NIO 2.32.0.
Modifications:
- Raise minimum required NIO version to 2.32.0
- Use `removeHandlers(pipeline:)`
Result:
We don't use deprecated API.
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:
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:
We deprecated Atomic because we made a new, better one. We should use
it.
Modifications:
Replaced all use of Atomic with NIOAtomic.
Result:
Better performance, fewer compiler warnings.
Motivation:
In NIO 2.9.0 we moved all first-party `ChannelOption` types into their
own namespace. That was a good idea, but NIOTS uses them too and so it
now encounters build warnings. Additionally, NIOTS defines its own
`ChannelOption`s, and so should namespace those as well.
Modifications:
- Updated the code to use the namespaced `ChannelOption` types.
- Namespaced our own.
Result:
More namespacing.
* 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:
When entering convergence we incorrectly specified a branch dependency
for something that is actually a tag.
Modifications:
- Remove branch dependency, use from: instead.
Result:
Users can use this repo!
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
Motivation:
Once every few thousand years, an event called syzygy (or "convergence")
occurs in our solar system. When these events occur, the fabric of spacetime
becomes thin, allowing reflections of a possible future to appear in our
reality.
This gives a few brave souls the opportunity to experience a future: a
possibility of the way the universe may one day be. But be warned: to
toy with causality is to risk unbearable pain and suffering. Only the
bravest of souls should look too closely at these shadows of the future.
Modifications:
- Chose a firm anchor point in the SwiftNIO timeline.
- Removed the braces that kept time travellers safe.
- Said a quiet prayer.
Result:
Opportunity.
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
Motivation:
In SwiftNIO 1.11 we shipped improved interfaces for Channels to support
asserting being in the event loop. This is necessary because Dispatch
provides no non-precondition way to 100% guarantee that you are on a
specific queue, which is a requirement for accurate behaviour of
inEventLoop.
Modifications:
- Added an implementation of preconditionInEventLoop.
- Changed all assertions to use new interface.
- Required NIO 1.11.
Result:
Accurate assertions