@DTS Engineer I ran some more tests on this today. Here are the results: Device setup: Both the devices are connected to same infrastructure wifi and not connected to Ethernet. Case 1: Browser setup: parameters.prohibitedInterfaceTypes = [.wifi] parameters.includePeerToPeer = true Connection setup: .prohibitedInterfaceTypes([.wifi]) .peerToPeerIncluded(true) In above case The devices are getting discovered. But unable to connect. I see below error when trying to send a message after initiating a connection(The connection never moves to ready state): (Network.NWError error 89 - Operation canceled) Case 2: Browser setup: parameters.prohibitedInterfaceTypes = [.wifi] parameters.includePeerToPeer = true Connection setup: .prohibitedInterfaceTypes([]) .peerToPeerIncluded(true) In above case, devices are getting discovered as well as getting connected.

If you don’t want that behaviour, you can limit it to a specific interface type or a specific interface For most cases I am ok to let the Network framework decide the interface type. But there are some cases where I want to allow only peer to peer. I've been using prohibitedInterfaceTypes to restrict wiredEthernet but I've not been able to restrict it to use only peer to peer. If I put .wifi in the prohibitedInterfaceTypes it doesnt connect through peer to peer either. Is there a way to force peer to peer only? The original question was related to browsing alone. But I would want to do the interface type restriction for the connection as well.

Thanks. That's helpful. My bad about the automatic reconnection. There was a disconnection when the wifi went down and a new connection was started which triggered it to use AWDL.

[quote='867155022, DTS Engineer, /thread/807854?answerId=867155022#867155022'] Use TLS-PKI. [/quote] Are you suggesting to do this at the application layer? The NetworkConnection/ NetworkListener classes doesnt seem to support any custom TLS configuration using NWParameters. To start you out, lemme point you at two posts: Thank you! These were very helpful. The better path handler is typically not necessary in a peer-to-peer context. Understood. To add more context here, the communication I am trying to establish here is between two iOS devices. The multipeer connectivity framework used to switch from Infrastructure Wifi to Peer to Peer Wifi automatically when the Wifi went down. I'm trying to mimic that behaviour with Nework framework. The migration guide briefly touches upon this topic to set includePeerToPeer to enable peer to peer wifi but it isnt clear if that will mimic the behavior of Multipeer.

AFAIK that’s not currently supported (r. 159170556) I would prefer to use an encrypted channel for communication. What options do I have with NetworkConnection in that case? For the switching from Wifi and Peer to Peer part, I was curious if there was a guide on best practices for usage of onBetterPathUpdate and onViabilityUpdate for switching from an unstable interface to a better available interface. There doesnt seem to be much documentation on how these functions are supposed to be used.

[quote='863913022, DTS Engineer, /thread/805211?answerId=863913022#863913022'] Are these both Apple devices? [/quote] Yes, That is correct.

The 12 hour usage I mentioned is sporadic where one of the devices could be going into sleep intermittently and the other device is always active(and connected to power). The idea here is to have the devices be connected always but given that one of the devices can go to sleep, my initial thought was to have the active device be publishing always when there are no active connections. From my tests so far, it looks like the system stops the publishing after a few minutes if it doesnt find any connections. So I was restarting the publisher every time it stops so that its in "always publishing" mode to detect whenever the other device comes out of sleep and connect to it. I observe similar behaviour with the connection as well - the connection drops after a few minutes of inactivity so I need to have some kind of heartbeat to keep the connection alive. This makes me think if Wifi-Aware may not be the right fit for this use-case and probably using Network framework may be a better fit here.

Adding a related question - Assuming I would be connected to the devices over a long period of time(lets say 12 hours in a day) What is the impact on battery usage in using Wifi-Aware compared to Infrastructure Wifi/ Ethernet/ Apple Peer to Peer Wifi through Network Framework?

I have a followup question on this - Are the WAEndpoint's discovered ephemeral? I'm trying to understand what's the best way to reconnect a disconnected WifiAware connection - Can I just cache the endpoint and start a new connection with the same endpoint or do I need to browse again and get a new WAEndpoint?

One option that I like a lot is WebSocket. It works on top TCP (and TCP+TLS) and Network framework supports it on both the client and server side. Thanks for the pointer. I did consider this at first but lack of documentation and sample code drove me away at first :D. I do have a couple of follow up questions related to this though. Currently I am using Multipeer framework. Multipeer Framework has a parameter called MCSessionSendDataMode which I have currently set to reliable. How does this help with reliability underneath? Does it make a connection using TCP instead of UDP? I am trying to understand - by moving to Network framework and using TCP as underlying framework can I have a more reliable connection compared to Multipeer? A query in the behaviour of acknowledgements - Does the send API on NWConnection throw an error if there is no acknowledgement? Does the error differ based on the underlying protocol - meaning if I use TCP I would assume the send API would throw a failure when the sending fails or when there is no acknowledgement compared to UDP where I assume we get an error only when sending fails.

@eskimo, Thanks for the response. You are correct that you shouldn’t use Multipeer Connectivity for this. Would you be saying this just because it is an overkill to use MPC here or is there any other reason? From what I currently understand, MPC can get the job done for me without me having to write a lot of low level coding that Network framework requires me to do mentioned in the link that you shared. I had ruled out Network framework for the reason that I need to be quick to market :) and MPC/CoreBluetooth offers a higher level of abstraction compared to Network framework.