swift-nio | driven network application framework for high performance | Networking library

Your questions aren't stupid at all!

1. Yeah, sharing a ChannelHandler probably counts as "not recommended". But not because it doesn't work, it's more that it's unusual and probably not something other NIO programmers would expect. But if you're comfortable with it, it's fine. If you're high-performance enough that you worry about the exact number of allocations per Channel then you may be able to save some by sharing handlers. But I really wouldn't optimise the prematurely.

   If you didn't want to share handlers, then you could use multiple handlers that share a reference to some kind of coordinator object. Don't get me wrong, it's really still the same thing: One shared reference across multiple network connections. The only real difference is that testing that may be a little easier and it would possibly feel more natural to other NIO programmers. (In any case be careful to either make sure that all those Channels are on the same EventLoop or to use external synchronisation (with say a lock, which might not be ideal from a performance point of view).

2. write just enqueues some data to be written. flush makes SwiftNIO attempt to send all the previously written data. writeAndFlush simply calls write and then flush.

   Why does NIO distinguish between write and flush at all? In high-performance networking applications, the biggest overhead might be the syscall overhead. And to send data over TCP, SwiftNIO has to do a syscall (write, writev, send, ...).

   Any SwiftNIO program will work if you just ignore write and flush and always use writeAndFlush. But, if the network is keeping up, this will cost you one syscall per writeAndFlush call. In many cases however, a library/app that's using SwiftNIO already knows that it wants to enqueue multiple bits of data to be sent over the network. And in that case doing say three writeAndFlush in a row would be wasteful. If would be much better to accumulate the three bits of data and then send them all in one syscall using a "vector write" (e.g. writev syscall). And that's exactly what SwiftNIO would do if you did say write, write, write, flush. So the three writes will all be sent using one writev system call. SwiftNIO will simply get the three pointers to the bits of data and hand them to the kernel which then attempts to send them over the network.

   You can take this even a little further. Let's assume you're a high-performance server and you want to respond to a flood of incoming requests. You'll get your requests from the client over channelRead. If you're now able to reply synchronously, you could just write them responses (which will enqueue) them. And once you get channelReadComplete (which marks the end of a "read burst") you can flush. That would allow you to respond to as many requests as you can get in a single read burst using just one writev syscall. This can be quite an important optimisation in certain scenarios.

Besides cleaning & re-building the project, you can try deleting the following files / directories:

• /.build
• /.swiftpm
• /Package.resolved

Then, run swift package update and try to build the project again.

This question was handled on the swift Forums https://forums.swift.org/t/swift-nio-based-proxy-reconfigures-pipeline-on-every-incoming-request/52043

Answer by Lukasa:

This is expected behaviour. HTTP/2 is multiplexed: this means you can run multiple request/response sequences over the same TCP connection. This manifests in SwiftNIO HTTP/2 in the form of the "stream channel initializer": this is called once per stream creation. The stream channel initializer here is the trailing closure being passed to configureCommonHTTPServerPipeline.

If you would like to create the handlers only once, you can do that. But now your handlers need to support being involved in multiple concurrent requests and responses.

You'll need to import NIOFoundationCompat to get any of NIO's method that work with Foundation data types such as Data (or JSONDecoder/JSONEncoder). NIOFoundationCompat is just another module of the swift-nio package so you won't need another dependency.

But just to be clear, under the hood, there will always be copies but probably you don't need to worry about them, copies are extremely fast on today's CPUs. If you absolutely want to avoid copies, you'll need to create ByteBuffers straight away. To help you with that, you may want to add where you get your data from that you want to send over the network.

I'm not 100% sure if that's what you're asking but are you trying to connect to a server using a custom CA, you probably want the following TLSConfiguraion:

The solution for SwiftNIO will require your handler to attach callbacks to the future returned from connect. These callbacks can close over the repeating task, and so can cancel it when a connection completes. For example: