Unable to re-open NetworkP2P listen port after exceptions

[ID]

Hello,

I was just experimenting with uLink 1.3 beta 5's changes to Open() and Close(). I noticed that it's no longer possible to re-open ports that are not listening due to exceptions without using the deprecated Open/Close methods.

This can be easily demonstrated by creating a scene with two game objects. Attach a uLink.NetworkP2P component to each game object and set their initial listening port to something, such as 7200.

Now, starting the game will cause an exception, as one of the two objects will be unable to open the relevant port - the other game object has already opened it.

Next, attach the following script to both game objects:

public class P2PInitializer : uLink.MonoBehaviour

{

public int startPort = 7200;

public int endPort = 7299;

private uLink.NetworkP2P p2p = null;

void Start()

{

p2p = networkP2P;

StartCoroutine(TryOpen());

}

IEnumerator TryOpen()

{

int currentPort = startPort;

while (!p2p.isListening && currentPort <= endPort)

{

p2p.

p2p.listenPort = currentPort;

currentPort++;

Debug.Log("Attempting to listen on " + currentPort.ToString());

yield return new WaitForSeconds(0.1f);

}

}

}

When you next start the game, you'll find that, despite having reset the listening port, p2p.isListening never becomes true.

[ID]

Obviously, remove the extraneous "p2p." from the first line of the while loop. Oops. :)

[Aidin Abedi]

Hello Ian,

The NetworkP2P component is only listening/open if it's also enabled and vice verse. If it's not open. it will by definition also be disabled - because a enabled but not open P2P component makes no sense, and if made possible would just call its network update in vein. So if your using the vanilla beta 5, you'll need to add "p2p.enabled = true;" after "p2p.listenPort = currentPort;". However we realize this is not intuitive, and we're extremely passionate about making things as simple and straightforward as possible (while keeping power and flexibility). So in the upcoming final release, we've changed the behavior of the P2P API so that when assigning NetworkP2P.listenPort, it will automatically also enable the P2P component (unless the port is unavailable). Please note that "listenPort = 0;" doesn't mean disabled, but means the OS should automatically find a available port. If you want to close a P2P component just disable it. If you find this counter-intuitive, please let us know - we appreciate feedback.

I've attached a custom build, which includes this new API behaviour along with other improvements such as 2 new utility functions: NetworkUtility.IsPortAvailable(...) and NetworkUtility.FindAvailablePort(...). However, your script code is the recommended approach because ports can be made available and unavailable at any given time by other processes. So just because NetworkUtility.IsPortAvailable() returns true, doesn't mean another process can't use it before you get the chance to.

Sincerely,

Aidin

--