I have a service that has been running on a 3x cluster of headless M1 Mac Studios since Ventura, and before that on headless Mac minis since Monterey. Now, after updating the Studios from Sonoma to Sequoia, response times have slowed to a crawl. For example, generating and sending a 150KB PDF file normally takes around 20 milliseconds. Now it takes over 15 SECONDS! The daemon code didn't change between updates. The issue seems to center around TSO on the ethernet port. Connecting via a port without TSO works as expected. But the 10 GB ethernet port on the Studio has built-in TSO. I've tried to disable TSO using sudo sysctl -w net.inet.tcp.tso=0. This works for an hour or so before the daemon eventually becomes unresponsive. At this point the daemon has to be terminated and restarted. So for now I'm having to use cheap USB-C to Ethernet adapters to connect the Mac Studios. Is there a configuration setting I'm missing for proper TSO in Network Framework?

I have the following snippet of code for receiving incoming data on a NWConnection: self.Connection.receive(minimumIncompleteLength: 1, maximumLength: self.MAX_INTAKE) { (data, context, isComplete, error) in if let err = error { // receive <error> returned non-nil self.Connection.cancel() return // exit completion handler } ... } This generally works and rarely receives an error. But seemingly at random, will return 89. When this happens I've been sending a .cancel before returning from the completion handler. It will work great for tens of thousands of connections, then suddenly return 89 error codes. My question is: Should I be canceling the connection here or simply let NWFramwwork do as it will? Canceling the connection seems to throw my NGINX reverse proxy into fits, from which it never recovers without a restart. In short what is the best practice for handling errors when receiving bytes in NWFramework?

For the past three years, I have been writing and maintaining a small but active REST service. It started life as a classic BSD sockets service, then moved to Swift NIO, and all that entails. The latest incarnation is nothing but native Network Framework, which seems to be the most bullet-proof of all. I have yet to crash it with the ApacheBench (ab) tool. Slow it down, maybe, but yet to crash it. Kudos to Apple on the NW Framework! Now, I require adding a TLS-based listener. I have searched these forums and many other Internet sites for sample code, but to no avail. There is much about configuring an iOS client app, but almost nothing on the macOS listener side. Below is a snippet of code in the init?() of my HTTPService class. Any suggestions on how to code in the correct TLS options would be greatly appreciated. init?( port: UInt16, tls: Bool = false ) { . . . let TLS_opts = NWProtocolTLS.Options() let TCP_opts = NWProtocolTCP.Options()     TCP_opts.disableECN         = true    // Explicit Congestion Notification     TCP_opts.enableKeepalive    = false   // Send Keep-Alive packets     TCP_opts.connectionTimeout  = 5       // Connection handshake timeout (seconds)     TCP_opts.connectionDropTime = 5       // Seconds TCP will do packet retransmission if (tls) {   let sec_opts = TLS_opts.securityProtocolOptions   // I’m completely stuck in the sparse documentation at this point!   //   // For testing purposes, I have a self-signed certificate in the System keychain with   // the identifier: “Server.local”   //   // How do I enable TLS using this (or a real) certificate?   } let Parameters = NWParameters(tls: TLS_opts, tcp: TCP_opts)     Parameters.allowLocalEndpointReuse = true guard let L = try? NWListener( using: Parameters, on: NWEndpoint.Port(rawValue: port) )   else { return nil } self.Listener = L self.Listener.newConnectionHandler = NewConnection(_:) . . . }