Hi everyone, I’m working with the DNSServiceGetAddrInfo API and came across the following statement in the documentation: If the call succeeds then it initializes the DNSServiceRef, returns kDNSServiceErr_NoError, and the query begins and will last indefinitely until the client terminates the query by passing this DNSServiceRef to DNSServiceRefDeallocate(_) I’m trying to understand exactly what this means in practice. Specifically, after receiving a response with kDNSServiceFlagsMoreComing, being set to 0 does it imply that the OS itself continues querying the DNS periodically or indefinitely, even after we've already received some results? Or does it only continue fetching additional results related to the initial query until we explicitly terminate it? Any clarification on the behavior of this query would be greatly appreciated! Thanks in advance!

Hi Everyone, I’m working on a communication system for my app using NWConnection with the UDP protocol. The connection is registered to a custom serial dispatch queue. However, I’m trying to understand what the behavior will be in a scenario where the connection is canceled while there are still pending receive operations in progress. Scenario Overview: The sender is transmitting n = 100 packets to the receiver, out of which 40 packets have already been sent (i.e., delivered to the Receiver). The receiver has posted m = 20 pending receive operations, where each receive operation is responsible for handling one packet. The receiver has already successfully processed x = 10 packets. At the time of cancellation, the receiver’s buffer still holds m = 20 packets that are pending for processing, and k = 10 pending receive callbacks are in the dispatch queue, waiting to be executed. At same time when the 10th packet was processed another thread triggers .cancel() on this accepted NWConnection (on the receiver side), I need to understand the impact on the pending receive operations and their associated callbacks. My Questions: What happens to the k = 10 pending receive callbacks that are in the dispatch queue waiting to be triggered when the connection is canceled? Will these callbacks complete successfully and process the data? Or, because the connection is canceled, will they complete with failure? What happens to the remaining pending receive operations that were initiated but have not yet been scheduled in the dispatch queue? For the pending receive operations that were already initiated (i.e., the network stack is waiting to receive the data, but the callback hasn’t been scheduled yet), will they fail immediately when the connection is canceled? Or is there any chance that the framework might still process these receives before the cancellation fully takes effect?

Hi everyone, I'm currently working on a project where I need to send multicast packets across all available network interfaces using Apple Network Framework's NWConnectionGroup. Specifically, the MacBook (device I am using for sending multicast requests, MacOS: 15.1) is connected to two networks: Wi-Fi (Network 1) and Ethernet (Network 2), and I need to send multicast requests over both interfaces. I tried using the .requiredInterface property as suggested by Eskimo in this post, but I’m running into issues. It seems like I can't create an NWInterface object because it doesn't have any initializers. Here is the code which I wrote: var multicast_group_descriptor : NWMulticastGroup var multicast_endpoint : NWEndpoint multicast_endpoint = NWEndpoint.hostPort(host: NWEndpoint.Host("234.0.0.1"), port: NWEndpoint.Port(rawValue: 49154)!) var connection_group : NWConnectionGroup var multicast_params : NWParameters multicast_params = NWParameters.udp var interface = NWInterface(NWInterface.InterfaceType.wiredEthernet) I get following error: 'NWInterface' cannot be constructed because it has no accessible initializers I also experimented with the .requiredInterfaceType property. Even when I set it to .wiredEthernet and then change it to .wifi, I am still unable to send requests over the Wi-Fi network. Here is the code I wrote: var multicast_params : NWParameters multicast_params = NWParameters.udp multicast_params.allowLocalEndpointReuse = true multicast_params.requiredInterfaceType = .wiredEthernet var ip = multicast_params.defaultProtocolStack.internetProtocol! as! NWProtocolIP.Options ip.disableMulticastLoopback = true connection_group = NWConnectionGroup(with: multicast_group_descriptor, using: multicast_params) connection_group.stateUpdateHandler = { state in print(state) if state == .ready { connection_group.send(content: "Hello from machine on 15".data(using: .utf8)) { error in print("Send to mg1 completed on wired Ethernet with error \(error?.errorCode)") var params = connection_group.parameters params.requiredInterfaceType = .wifi connection_group.send(content: "Hello from machine on 15 P2 on Wi-Fi".data(using: .utf8)) { error in print("Send to mg1 completed on Wi-Fi with error \(error?.errorCode)") } } } } Is this expected behavior when using NWConnectionGroup? Or is there a different approach I should take to ensure multicast requests are sent over both interfaces simultaneously? Any insights or suggestions would be greatly appreciated! Thanks in advance, Harshal

Hello Everyone, I’m working on a project that involves multicast communication between processes running on different devices within the same network. For all my Apple devices (macOS, iOS, etc.), I am using NWConnectionGroup, which listens on a multicast address "XX.XX.XX.XX" and a specific multicast port. The issue occurs when a requestor (such as a non-Apple process) sends a multicast request, and the server, which is a process running on an Apple device using NWConnectionGroup (the responder), attempts to reply. The problem is that the response is sent from a different ephemeral port rather than the port on which the multicast request was received. If the client is behind a firewall that blocks unsolicited traffic, the firewall only allows incoming packets on the same multicast port used for the initial request. Since the multicast response is sent from a different ephemeral port, the firewall blocks this response, preventing the requestor from receiving it. Questions: Is there a recommended approach within the NWConnectionGroup or Network.framework to ensure that responses to multicast requests are sent from the same port used for the request? Are there any best practices for handling multicast responses in scenarios where the requestor is behind a restrictive firewall? Any insights or suggestions on how to account for this behavior and ensure reliable multicast communication in such environments would be greatly appreciated. Thanks, Harshal