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:
xcodebuild complains during Cocapods validation (which fails as a
result) about a redundant availability check. It's redundant because for
watchOS the availability guard on the outer scope has the same
conditions (for other platforms the conditions are tighter in the
inner scope). We never hit this before because we only recently added
watchOS to the supported platforms for Cocapods.
Modifications:
- Remove a redundant availability check
Result:
- Cocapods can validate without error
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:
In a patch where we added some metadata options, we accidentally set the
availability wrong. This is a compile-time error, so we broke watchOS
compilation.
Modifications:
Update the availability of some types on watchOS.
Result:
Users can build on watchOS again.
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:
It's not obvious what happens when `childChannelInitializer` returns a
failed future. See https://github.com/apple/swift-nio/pull/1516
Modifications:
Add a note to the `childChannelInitializer` documentation.
Result:
Better docs.
Motivation:
See apple/swift-nio#1508 for rationale
Modifications:
Provides implementations of `preconditionInEventLoop(_:file:line:)` and `preconditionNotInEventLoop(_:file:line:)`.
Result:
NIOTSEventLoop will now use dispatchPrecondition(condition:) for the in/not in preconditions instead of relying on the default implementation, yielding improved correctness.
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.
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:
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:
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.
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.
Motivation:
In Network.framework it is possible for a bind operation to take a while
to complete if it ends up waiting for appropriate network conditions. As
a result, unlike in the POSIX case, we need to give users the ability
to configure the maximum amount of time they'd be willing to wait for a
bind call to succeed.
Modifications:
- Add a bind timeout.
Result:
Users won't have to wait forever.
Motivation:
When autoRead is on, the pipeline must observe the read calls in order
to be able to exert backpressure. Otherwise, autoRead is a
zero-backpressure mode, which isn't great.
Correctly call pipeline.read instead of self.read0 to avoid this.
Modifications:
- Updated NIOTSConnectionChannel to call pipeline.read().
Result:
Backpressure can be exerted.
Motivation:
`NWEndpoint` added a `.url` case for macOS 10.15 which commit afbbead added
support for. However, in doing so it also broke support for 10.14.
Modifications:
Handle `.url` in the `default` case and also remove `@unknown` from the
cases of the switch statements in NIOTSListenerChannel and SocketAddress
init.
Result:
Compiles on 10.14.
* 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:
macOS Catalina brings a .url endpoint to Network.framework, which is
currently causing build warnings. We should tolerate it and silence
those warnings.
Modifications:
Do the right thing when we receive a .url endpoint.
Result:
No build warnings.
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
Motivation:
The expectation is that server channels use Channel as their data type,
but the initial data type in NIOTSListenerChannel was actually
NWConnection. This is unnecessary and it makes it hard to interop
between NIOTS and NIO.
Modifications:
- Initialize the NIOTSConnectionChannel in the NIOTSListenerChannel
instead of in AcceptHandler.
- Added some missing @available annotations in the tests.
Result:
More consistency
* 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:
At least in some cases it's possible to have a local or remote address
that we cannot represent in a SocketAddress. In the face of that, we were
unnecessarily crashing. Crashes should probably be avoided there.
Modifications:
- Replace the crashes with throws.
Result:
Fewer crashes, more nils.
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:
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:
Some users may wish to use peer-to-peer networking with bonjour.
Modifications:
Expose peer-to-peer networking via a new channel option.
Result:
Users will be able to use peer-to-peer networking
(cherry picked from commit e9c1e41fd1)
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 some cases, such as when an event loop has been shutdown, channel
registration may fail. In these cases, we would incorrectly attempt to
deregister the channel, which would fail (and in debug builds, assert).
Really, we shouldn't transition into .registered until we know that we have,
in fact, registered.
However, we need to be cautious: we don't want to register unless we
believe we're in an acceptable state to register.
Modifications:
Updated the state enum to perform the registration at the correct
part of the state change function.
Result:
Harder to crash in debug mode
Motivation:
We were inadvertently modifying the registration information of
NIOTSEventLoop objects from multiple threads, which is very not good.
Modifications:
Add an event loop execute to hop loops.
Result:
Thread safe!
Motivation:
Sadly I overlooked the fact that Channel.isActive is supposed to be
safe to call from multiple threads: the implementation here was not.
Modifications:
Store the active state into an Atomic.
Result:
It will be thread-safe to ask if a channel is active.
Motivation:
In some cases users may prefer not to wait for Network.framework to
reattempt connection in the future. Users should be able to opt-out of the
default waiting behaviour in those cases.
Modifications:
- Added WaitForActivity ChannelOption.
Result:
Users can configure channels better.
Motivation:
It is possible to receive the dataReceived callback after we've called
cancel, mostly because there may be such a block in place in the queue
before that cancel call fires. We should tolerate that.
Modifications:
Removed the invalid assertion.
Result:
Fewer failures.
Motivation:
If the user sets an unsupported ChannelOption we should give the best
diagnostics possible.
Modifications:
Add the ChannelOption type to the error message that it's unsupported.
Result:
Happier users
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
Motivation:
One bugfix, some cleanliness.
Modifications:
`NIOTSListenerChannel.doClose0()` now evaluates and updates `self.bindPromise` irrespective of whether `self.nwListener` had been set.
Also, some case statements could be better: I've swapped `case _ as Thing:` with `case is Thing:`, and I've inlined the `let` value from `case _ as Thing: let thing = x as! Thing` to simply be `case let x as Thing:`.
Result:
If the call to create the `NWListener` in `NIOTSListenerChannel.beginActivating0()` throws an error, any promise passed to that method will now correctly be updated, where before it would be silently ignored, potentially causing a waiting caller to wait forever.
Also, no case statements remain that might cause damage to my tooth enamel.
* Use DispatchWorkItem.cancel() for cancellation. Make StateManagedChannel.beginActivating() use the same methodology as all the others.
* A needless `if let x = opt` that could be replaced with a question mark.
Motivation:
If an error is encountered early in the bootstrap process we should
probably not hit an assertion.
Modifications:
Added tests that we don't crash when closing idle channels.
Result:
Fewer crashes.
Motivation:
These are commonly-set socket options for channels, and we should
support them when using Transport Services as well.
Modifications:
Pass the socket options through to allowLocalEndpointReuse.
Result:
SO_REUSEADDR and SO_REUSEPORT will be available.