Hi everyone, I'm currently working on establishing connections using either IPv4 or IPv6 in my Swift application. However, I've hit a snag with NWProtocolIP.Options. It appears that I'm unable to create its instance to configure additional options. I would appreciate any tips or advice on how to achieve IPv4 or IPv6 connections exclusively. Here's a breakdown of what I'm aiming to accomplish in my app: Initialize the protocol options and offer choices for IP versions and various other transport layer options. Initialize the endpoint by passing the IP address struct and port number. Create the connection object using the endpoint and parameters. If IPv4 was selected as the option and the IP address struct contained an IPv6 address, I expect the NWConnection to fail, providing the corresponding error code. Any insights or guidance on resolving this issue would be highly appreciated. Thank you in advance for your help!

Thank you for the response. I was trying to write a poc and validate this with the following code: import Foundation import dnssd var vSDRef: DNSServiceRef? let callback: DNSServiceGetAddrInfoReply = { (sdef, flags, interface_idx, errorcode, hostname, resolvedAddresses, ttl, context) in NSLog("Callback called...") if errorcode == kDNSServiceErr_NoError { if let hostname = hostname, let address = resolvedAddresses { var add_string = [CChar](repeating: 0, count: Int(INET6_ADDRSTRLEN)) switch Int32(address.pointee.sa_family) { case AF_INET: var ipv4_addr = address.withMemoryRebound(to: sockaddr_in.self, capacity: 1) { $0.pointee } inet_ntop(AF_INET, &(ipv4_addr.sin_addr), &add_string, socklen_t(INET_ADDRSTRLEN)) case AF_INET6: var addr6 = address.withMemoryRebound(to: sockaddr_in6.self, capacity: 1) { $0.pointee } inet_ntop(AF_INET6, &(addr6.sin6_addr), &add_string, socklen_t(INET6_ADDRSTRLEN)) default: NSLog("Unknown address family") return } NSLog("Resolved \(String(cString: hostname)) to \(String(cString: add_string))") } else { NSLog("Error resolving DNS address: \(errorcode)") } } } let returned_error = DNSServiceGetAddrInfo(&vSDRef, DNSServiceFlags(kDNSServiceFlagsLongLivedQuery), 0, DNSServiceProtocol(kDNSServiceProtocol_IPv4 | kDNSServiceProtocol_IPv6), "example.com", callback, nil) if returned_error == kDNSServiceErr_NoError { NSLog("DNS lookup started...") } else { NSLog("Error starting DNS resolution: \(returned_error)") } NSLog("Resolved if else") sleep (100)``` tcpdump showed that we are getting a response but the callback never gets triggered. Can you help me out here please. Thanks, Harshal.

Thank you for the detailed feedback and guidance. I really appreciate you taking the time to provide such helpful information. The code you referenced in your previous email was very useful, and I've incorporated the suggestions you provided. Specifically, I've moved the top-level code into a function called performDNSLookup(), which is a more appropriate structure for Swift. I've also used DNSServiceSetDispatchQueue to schedule the DNSServiceRef on the main queue, and I'm using dispatchMain() to "park" the main thread and keep the callback active. Additionally, I've replaced the use of inet_ntop with getnameinfo and NI_NUMERIC{HOST,SERV}, as you recommended, to handle the sockaddr type more effectively in Swift. I've tested the updated code, and it's working as expected. Thank you again for your valuable guidance. Regards, Harshal

Hello @eskimo , Just to confirm again, is their support for "getaddrinfo" on all the iOS platforms as well ?

Hello @DTS Engineer , Although the conversation is about new interop, but the conversation is about missing generated header to use swift apis in cpp, but my problem is regarding storing different types of swift class objects in a common artefact as retained objects in cpp.

Thank you @DTS Engineer ! I've also posted a similar query in Swift Forums. Here's the link in case someone comes across it later.

Hi @DTS Engineer , That was also posted by me. There was another thread which is not identical but had some similar case of interpreting Data in cpp , although it was an attempt with std::vector. (link) Could you help out on how can this be achieved? Thanks :) Harshal

@DTS Engineer Thanks, Given your explanation about the limitations of the Network framework's UDP support, could you clarify in which scenarios the allowLocalEndpointReuse property would actually be effective? Additionally, I’m also trying to set TCP-specific options like noDelay and connectionTimeout on a NWConnection. How can I configure these options correctly? I’ve noticed that even when creating NWParameters with an initializer that takes NWProtocolTCP.Options, it doesn’t seem to apply as expected. What should I do? Thanks :)

[quote='809609022, DTS Engineer, /thread/766433?answerId=809609022#809609022'] On an outgoing connection? Or on incoming connections spawned by the listener? [/quote] On an outgoing TCP connection.

Also posted the same on swift forums in hopes of getting swifter response :( here's the link: https://forums.swift.org/t/how-to-reply-to-a-message-received-by-multicast-receiver-and-extract-connection-for-communication/75454

Thanks for the response @DTS Engineer, now if i set an option say "EnableFastOpen" on a NWConnection object. How can I check the values for it at a later point in time. Is there a way I get it from "params" property of a "NWConnection" instance?

[quote='810445022, DTS Engineer, /thread/766557?answerId=810445022#810445022'] Why are you doing this? [/quote] @DTS Engineer To clarify our situation: While we are exploring mDNS-based discovery using Bonjour, our primary goal is to create cross-platform applications that can run on the same network and discover each other using IP-based multicast. We're facing challenges in this area and would like to better understand why these issues occur and how we can resolve them when using NWConnectionGroup. Unlike traditional service discovery, our use case isn’t about discovering specific services. Instead, we are focused on process discovery—identifying processes running on the same network, regardless of whether they expose a service. This changes the approach we need to take compared to service-based discovery. We are avoiding the use of multicast DNS (mDNS) because it adds overhead and costs. For a simple use case like ours, where IP multicast works seamlessly on other platforms, we want to avoid the complexity and resource consumption associated with mDNS queries. Additionally, when we use NWConnection to send a multicast request and the responder is a non-Apple process (e.g., a Linux process using BSD sockets), we notice that the responses from that process are not received by the NWConnection, unlike what happens in similar scenarios on other platforms. We are curious about why this occurs and how we can resolve it? Any guidance on how to handle these multicast challenges more effectively would be greatly appreciated. Apologies for the delayed response :)