psnet2 always opens UDP socket

[asarium]

psnet_init is always called at startup which opens a UDP socket. Apart from consuming resources this also causes a firewall dialog to appear on Windows even when only playing in single-player.

Could the psnet_init call be delayed until it is actually needed e.g. when starting a multi-player session?

[chief1983]

If we get FSO to add an exception for itself to Windows Firewall, that would prevent the dialog from ever happening right?

Additionally, if it's going to open the dialog at all, wouldn't having that happen immediately be the preferred time?

I do agree though, if we do get the exception adding written, then waiting to open the port until needed would be better resource-wise.

[asarium]

FSO shouldn't open a socket without reason.

The Windows API can be used for adding an exception but only if it is actually needed.

[notimaginative]

I've been looking into this a bit with the IPv6 rewrite. Calling psnet_init() only when required shouldn't be that big of an issue. The issue is just the usability problem with the Windows firewall popup.

From what I can tell the API for adding firewall exceptions requires being run with administrator privileges. And I assume that requiring FSO be run with admin privileges isn't something we want.

Would it not be a better option to add that functionality to Knossos? It wouldn't require any specific build support, and Knossos has all of the needed info (path to exe and port number). I don't know enough about the Knossos code base to know if it's possible though.

[asarium]

I was also thinking that could be done. It is not really a pressing issue though since the user will just see the pop-up but having Knossos do that automatically would be nice.

[notimaginative]

As a general fix for this I'm planning to reorganize things just a bit so that multi can have a pre-init to setup the basic requirements and then be closed. This will give us the early firewall popup but then close the socket(s). Switching to multi mode will then init multi for real, and switching to single can again close things out cleanly.

[notimaginative]

This was addressed in Knossos.NET PR 352 but was ultimately reverted due to it causing even worse issues.

As such, I'm putting the pre-init trick back on my todo list for 26.0 and we can just stick with that until a less troublesome solution is found for Knossos.NET.

[wookieejedi]

As a general fix for this I'm planning to reorganize things just a bit so that multi can have a pre-init to setup the basic requirements and then be closed. This will give us the early firewall popup but then close the socket(s). Switching to multi mode will then init multi for real, and switching to single can again close things out cleanly.

I'll note that in FotG we use scripting to auto switch between single and multiplayer, so it would be awesome if any pre init trucks could allow that to still work as well. I'm also happy to answer any questions or do any tests to help!