in HTTP/1, you reap connections manually from within channel handlers based on keepalive and timeout heuristics.
but in HTTP/2, the connection layer is completely abstracted away, and the channel handlers can only control the third-level channels corresponding to a a single HTTP/2 stream within a multiplexed connection.
while i would expect configuring the connection lifecycle behavior to be a pretty basic use case for SwiftNIO, the library is so poorly documented (1, 2) that i have no idea where to add additional logic to manage incoming connections or reap them when they become idle.
Put a ChannelHandler in the parent Channel that manages idle timeouts. In the API linked in (1), that would be added in the h2ConnectionChannelConfigurator.
We send a wide range of user events down that Channel that tell you what is going on. You can see them all here. Relevantly for your use-case you can use the stream created/stream closed events to keep track of the behaviour.
Finally, from this location you can also send PING frames and wait for responses, which can be used for keepalive probing.
This is the kind of thing that is really best done with a ChannelHandler. grpc-swift uses a handler that keeps track of swift-nio-http2's user events to determine whether a channel is active or not.
(A sidebar regarding this timer: you want to double-check your count of active streams before you actually close, as you may find that the timer fired but before it could be processed we got a new stream.)
It would be reasonable to move much of this functionality to swift-nio-http2 itself, please feel free to open a bug report requesting it.
i’m not convinced a channel handler is needed here. right now i’m using this noncopyable abstraction to start a monitoring task that runs alongside the main task that reads the NIOAsyncChannel:
import Atomics
struct TimeCop:~Copyable, Sendable
{
let epoch:UnsafeAtomic<UInt>
init()
{
self.epoch = .create(0)
}
deinit
{
self.epoch.destroy()
}
}
extension TimeCop
{
func reset()
{
self.epoch.wrappingIncrement(ordering: .relaxed)
}
func start(interval:Duration = .milliseconds(1000)) async throws
{
var epoch:UInt = 0
while true
{
try await Task.sleep(for: interval)
switch self.epoch.load(ordering: .relaxed)
{
case epoch:
// The epoch hasn’t changed, so we should enforce the timeout.
return
case let new:
// The epoch has changed, so let’s wait another `interval`.
epoch = new
}
}
}
}
it checks the value of the atomic counter every second, but since the connection would usually be accompanied by at least one request fragment, it gives the client about two seconds to trigger some activity on the channel.
/// Reap connections after one second of inactivity.
let cop:TimeCop = .init()
async
let _:Void =
{
(cop:borrowing TimeCop) in
try await cop.start(interval: .milliseconds(1000))
try await connection.channel.close()
} (cop)
every time something is read from the inbound stream, i am resetting the timeout by incrementing the counter:
var inbound:NIOAsyncChannelInboundStream<HTTP2Frame.FramePayload>.AsyncIterator =
stream.inbound.makeAsyncIterator()
var headers:HPACKHeaders? = nil
while let payload:HTTP2Frame.FramePayload = try await inbound.next()
{
cop.reset()
...
then when we are ready to send the response, i am incrementing the counter once more:
Note that the NIOAsyncChannels that produce HTTP2Frame.FramePayload are channels representing HTTP/2 streams, not connections. Closing them does not release the underlying TCP resource.