Context: We are using NWConnection for UDP and TCP Connections, and wanted to know the best way to keep the number of pending send completions in control to limit resource usage Questions: Is there a way to control the send rate, such that too many 'send pending completion' does not get queued. Say if I do a ‘extremely dense flurry of 10 million NWConnection.send’ will all go asynchronous without any complications? Or I would be informed once it reaches some threshold. Or no? And is it the responsibility of the application using NWConnection.send to limit the outstanding completion , as if they were beyond a certain limit, it would have an impact on outstanding and subsequent requests? If so – how would one know ‘what is supposed to be the limit’ at runtime? Is this a process level or system level limit. Will errors like EAGAIN and ETIMEOUT ever will be reported. In the test I simulated, where the TCP Server was made to not do receive, causing the 'socket send buffer' to become full on the sender side. On the sender side my send stopped getting complete, and became pending. Millions of sends were pending for long duration, hence wanted to know if we will ever get EAGAIN or ETIMEOUT.

We have a requirement to create a production quality application that also acts as HTTPS server for certain communication. The preference is for the server to support HTTP/1.1, HTTP/2 and HTTP/3 communication asynchronously, though not mandatory to support all the HTTP versions. Wanted to get the guidance, on which stack should be used, that is most reliable and that gives the maximum long term compatibility, sustainability and reliability. What is the recommended 'in-built' or 'available by default' stack on Apple Platform ? For HTTPS on HTTP/1.1 with synchronous mode operations ? For HTTPS on HTTP/1.1 with asynchronous mode operations ? For HTTPS on HTTP/2 with synchronous mode operations ? For HTTPS on HTTP/2 with asynchronous mode operations ? For HTTPS on HTTP/3 with asynchronous mode operations ? For HTTPS on HTTP/1.1 + HTTP/2 with synchronous mode operations ? For HTTPS on HTTP/1.1 + HTTP/2 with asynchronous mode operations ? For HTTPS on HTTP/1.1 + HTTP/2 + HTTP/3 with asynchronous mode operations ? What the generally recommended server stack that a typical application uses whether 'in-built' or 'available by default on Apple ' or 'not-available by default on Apple' stack. From the available stacks , we tried to evaluate the below stacks: https://opensource.apple.com/projects/swiftnio/ : We understand that while it’s not preinstalled as part of Apple's OSes, it is an official Swift package supported by Apple and can easily be added to your project. At the moment it supports HTTP/1.1 and HTTP/2. The link https://github.com/apple/swift-nio/issues/1730says that HTTP/3 will get added in the future. Is there any other HTTPS stack (built-in or third-party) that is recommended to the used on Apple's platform ? Our application is expected to be working on macOS, iOS, iPadOS, tvOS and watchOS. We understand that macOS also includes Apache HTTPD server. As our application is not primarily a Web Server (and also supports other protocols both in client and server mode), it looks integrating HTTPS directly into the application using a lightweight HTTP library with SSL/TLS support is a better option, in place of Apache HTTPD. From the document we know that swift-nio uses BoringSSL (swift-nio-ssl) which is prepackaged along with the swift-nio library, and it does not use the default Secure Transport. What is the reason being not using Secure Transport ? Now does it become the responsibility of the application using swift-nio to take care of updating BoringSSL with the patches.