Ni Server Locator stopping

[didje007]

Hello,

I am using Ni service locator to establish connexion between two LabVIEW exe running on the same computer.

Sometimes as the application has been running smoothly previously, the communication between the exe stops.

I found the solution is to stop Ni Service locator ant restart it. ( even though Ni server locator display state is running)

This seems to happen when there has been a change in the network settings of the machine ( for example a new wifi network has been found) but not always.

Do you have any idea what could stop NI service locator and how I could prevent it?

I am using LabVIEW 2018 ( 32 bit and 64 bits). This problem has been observed in windows 7 and windows 10.

Thank you

[rolfk]

It's likely not stopped but as it starts up, it opens up a listener socket on which it waits for HTTP style requests for service registration, service queries and possible maintenance tasks of its service registry. With the Windows TCP/IP stack getting reconfigured there is a chance that the network socket that the service bound to for the listener gets effectively disconnected from the stack as it refers now to an invalid network address and mask. This happens under Windows easily with Wifi network when the system is configured to automatically connect and disconnect from the wired network as soon as the Wifi is connected. I'm not even sure there is a standard method in the Windows socket library to detect such changes in order to close the old socket and reopen it.

[didje007]

Thank you for your reply.

Your analysis seems to correspond to what we observe.

However I was looking for a solution to avoid monitoring the state of the connection and restart the service when required.

[rolfk]

I'm not sure there is a solution. While I understand the desirability for that, I also think it may be hard to detect that the network configuration has potentially changed in a way that makes open sockets going invalid. For connected sockets it is fairly easy, just try to use them and they fail. For a listen socket there is nothing the listener can do to detect that the socket is suddenly only connected to nirvana.

It would need to hook into some operating system message that indicates network changes and preemptively restart the listener every time it receives such an event. Likely it should use NotifyIpInterfaceChanges() for that. As it doesn't seem to do that yet, all you can do is to report it to NI and see if there has been a fix in a certain version or at least let them create a corrective action request in their bug tracking system.

[didje007]

Thank you for your feedback.
i've contacted the Support from NI and I am waiting for their answer on this problem.

[StevenHowell]

---

@rolfk wrote:

It's likely not stopped but as it starts up, it opens up a listener socket on which it waits for HTTP style requests for service registration, service queries and possible maintenance tasks of its service registry. With the Windows TCP/IP stack getting reconfigured there is a chance that the network socket that the service bound to for the listener gets effectively disconnected from the stack as it refers now to an invalid network address and mask. This happens under Windows easily with Wifi network when the system is configured to automatically connect and disconnect from the wired network as soon as the Wifi is connected. I'm not even sure there is a standard method in the Windows socket library to detect such changes in order to close the old socket and reopen it.

---

Rolf,

I know this is an old post but I wanted to clarify as behavior that I am seeing. 

Above you mentioned that it opens a listener socket on which it waits for HTTP style requests.

I have noticed on one of my cRIO 9057 deployments that if I disable the NISystemWebServices that the TCP Listener no longer works because the port does not open when the application starts up. We have verified this through a sniffer.

Does that sound right? Is there some other way to use the listener without the need for the web services to be up? 

Thanks!

[rolfk]

The NI Service Locator has a rather varied history. In it’s first implementation it was simply a VI library that got invoked on system or LabVIEW startup to run in the LabVIEW runtime engine. Later NI created a system service to run as Windows service while on non-Windows system the VI powered service locater remained in use. Somewhere around 2014 to 2018 they moved the service locator into the NI web server service because it was in essence a HTTP service too and well known TCP/IP ports on an average computer are getting a scarce resource.