I wanted to consolidate my understanding of the states delivered via NWListener.stateUpdateHandler for ConnectedUDP and verify if this interpretation is correct. From what I understand, the following states can occur: .setup This state occurs immediately after creating the NWListener instance and persists until start(queue:) is called. .waiting This occurs when the listener is unable to bind or become ready at that moment, but may recover. Typical scenarios include: Required network interface is temporarily unavailable Port is temporarily unavailable (e.g., already in use but may be released) Local network permission has not yet been granted .ready This occurs when the listener has successfully bound to a port and selected a viable interface/path. At this point, it is ready to receive incoming traffic. .failed This represents a non-recoverable error that prevents the listener from functioning. Typical scenarios include: Invalid parameters during initialization (e.g., EINVAL) Binding to an invalid or unavailable address (EADDRNOTAVAIL) Permission explicitly denied (EACCES) Port in use by another long-lived process (EADDRINUSE) .cancelled This occurs after cancel() is explicitly called on the listener and represents a terminal state. State Transition Understanding Based on this, my current understanding is: Once the listener transitions out of .setup, it does not return to .setup. In the normal (“happy path”) case, the state progression is: .setup → .ready → .cancelled .waiting is a recoverable state, whereas .failed is non-recoverable. In other words, once the listener enters .failed, it will not transition to any other state except .cancelled.

I had some more queries on receiveMessage(completion:): In case error remains nil, can I still receive Data as null? Is there any performance/efficiency gain that we get while using receive(minimumIncompleteLength:maximumLength:completion:) over receiveMessage(completion:)?

I agree with what you stated above, and I apologize for not mentioning that we will prepare the datagram while keeping the maximum MTU in mind. The datagram size will be less than the maximum MTU. I had two queries following that: What are the pros and cons of using receive and receiveMessage, and when each should be used? We understand that in the case of receiveMessage, we will only receive nil data if some kind of error has occurred. Howerver if we use receive - in what situations can the data be nil?

We are building our own custom protocol, and we will be assembling the bytes that we are receiving. We wanted to reduce the kernel overhead of assembling bytes that receiveMessage(completion:) does. The question we have is that while using the receive api can the completion handler can be called even if data==nil?

No, I am only connected to only a single wifi interface which supports IPv6 multicast. For IPv4, it is working fine. I am able to send/receive data using the code mentioned here: [quote='788532021, vishalsehgal, /thread/788532, /profile/vishalsehgal'] import Network import Foundation // Creating a mutlicast group endpoint [/quote] But for IPv6, it is failing with the following errors/warnings: nw_endpoint_flow_failed_with_error [C1 ff02::1.49153 waiting parent-flow (unsatisfied (Local network prohibited), interface: en0[802.11], ipv4, ipv6, uses wifi)] already failing, returning nw_socket_connect [C1:1] connectx(7, [srcif=0, srcaddr=::.62838, dstaddr=ff02::1.49153], SAE_ASSOCID_ANY, 0, NULL, 0, NULL, SAE_CONNID_ANY) failed: [48: Address already in use] nw_socket_connect [C1:1] connectx failed (fd 7) [48: Address already in use] nw_socket_connect connectx failed [48: Address already in use] nw_endpoint_flow_failed_with_error [C1 ff02::1.49153 in_progress socket-flow (satisfied (Path is satisfied), interface: en0[802.11], ipv4, ipv6, dns, uses wifi)] already failing, returning I tried specifying the .requiredInterfaceType property as .wifi too but it didn't affect the output in both the cases. My questions are: Why is it failing for IPv6 but not for IPv4? Are there any configurations or setup that I need to do for IPv6 to make it work?

[quote='844214022, DTS Engineer, /thread/788532?answerId=844214022#844214022'] Are you still working on the protocol you outlined in your previous thread? [/quote] Yes similar, my project 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 an IPv6 as well as IPv4 multicast address passed through a NWMulticastGroup and a specific multicast port. For IPv6, I am unable to send multicast packets to the IPv6 multicast group using NWConnectionGroup even though I allow the access of the local network as mentioned here. But for IPv4, I am able to send multicast packets to the IPv4 multicast group.

Hi @DTS Engineer, As a requestor, I send a multicast packet to a multicast group through which a responder responds back using .reply. Using .reply, I will able to invoke the newConnectionHandler on the requestor side for my use cases. I necessarily want to invoke this newConnectionHandler so that I can further create a unicast connection with the responder. If I use .send on the responder side too, it will again invoke the receiveHandler on the requestor side which I don't want for my use cases.

Hi @DTS Engineer, I have two flows- one is requestor and another one is responder. As a requestor, when we perform .send to the responder which invokes receiveHandler of the responder. Now using .reply, we want to invoke the newConnectionHandler on the requestor side. [quote='837614022, DTS Engineer, /thread/771207?answerId=837614022#837614022'] Once you do this, a send from the group like this: [/quote] This will only cause the receiveHandler to be invoked from the requestor side when responder sends the packet using .send instead of .reply. Due to which I have following 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?

Hi @DTS Engineer, any updates?

Hi @DTS Engineer, did you miss it?

Hi @DTS Engineer, I am using .reply method on NWConnectionGroup object to reply back to the multicast messages received. [quote='824417022, harshal_goyal, /thread/771207?answerId=824417022#824417022, /profile/harshal_goyal'] ** Step 2: Local IP: 10.20.16.45 Local Port: 5000 Remote IP: 239.0.0.25 Remote Port: 5000 Step 5: (working tuple) Local IP: 10.20.16.28 ( a linux device jonied on same multicast ip and group) Local port: 5000 Remote IP: 239.0.0.25 Remote Port: 5000 Step 5 : (failing tuple) Local IP: 10.20.16.144 (Apple device running Network Framework using NWConnectionGroup) Local Port: 53000 (because responses are sent from ephemeral ports) Remote IP: 239.0.0.25 Remote Port: 5000 ** [/quote] For the given use case, I have sent the message from the port 5000 but receiving it back on port 53000 which causes the firewall to block the incoming packets. 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?

Hi @DTS Engineer, For the above observation, I am using the following piece of code: pathMonitor.pathUpdateHandler = { path in if path.status == .satisfied { multicastEndpoints.removeAll() for interface in path.availableInterfaces { if interface.type == .wifi || interface.type == .wiredEthernet { let multicastEndpoint = NWEndpoint.hostPort(host: multicastHost, port: multicastPort) multicastEndpoints.append(multicastEndpoint) } } if !multicastEndpoints.isEmpty { do { let multicastGroupDescriptor = try NWMulticastGroup(for: multicastEndpoints, disableUnicast: false) var multicastParams = NWParameters.udp multicastParams.allowLocalEndpointReuse = true let ip_options = multicastParams.defaultProtocolStack.internetProtocol as! NWProtocolIP.Options ip_options.disableMulticastLoopback = true connectionGroup = NWConnectionGroup(with: multicastGroupDescriptor, using: multicastParams) connectionGroup?.stateUpdateHandler = { state in print("Connection group state: \(state)") if state == .ready { connectionGroup?.send(content: "Hello from machine on 15".data(using: .utf8)) { error in print("Send completed with error \(error?.errorCode ?? 0)") } } } connectionGroup?.newConnectionHandler = { connection in print("Received new connection on endpoint") } connectionGroup?.setReceiveHandler { message, content, isComplete in if let content = content, let messageString = String(data: content, encoding: .utf8) { print("Received message: \(messageString)") message.reply(content: "Hello back from mac 15".data(using: .utf8)) } } connectionGroup?.start(queue: .global()) } catch let error { print("Error creating multicast group: \(error)") } } else { print("No valid network interfaces found.") } } else { print("No network interfaces available.") } } Here, I am creating an NWMulticastGroup with the available multicastEndpoints tracked using pathMonitor. The multicastGroupDescriptor returned by NWMulticastGroup is further used to create NWConnectionGroup which is then used for send/receive operations over the available interfaces (in this case .wifi and .ethernet). Now, the above issue occurs since the system has taken one of them as primary interfaces (in my case it is .ethernet). Due to this, I am unable to send/receive using other interfaces (.wifi in my case). I have confirmed this behavior using wireshark as stated earlier.

Sorry for the delay in response. As per the suggestion, I tried to used NWPathMonitor() to get all the interfaces I have. And then I create a NWMulticastGroup object passing all the interfaces whose file descriptor is further used to create a NWConnectionGroup object which is used for send/receive operations. However, the issues still occur for the interfaces where the system has taken one of them as the primary interface (let us say we have two interfaces, ethernet and wifi and ethernet is taken as primary interface) and I am unable to send/receive packets through other interfaces (wifi). I have confirmed this behavior using wireshark where I am unable to send/receive multicast packets from the receiver using the other interfaces (wifi), but I am only able to get those messages from the primary interface (ethernet).

Sorry for the delay in response. I am currently using “.reply” method using NWConnectionGroup to reply back to the multicast messages received. Now since I have sent the message from the port “X” and the responder is replying from the port “Y” the firewall blocks the incoming packets from the responder. 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?