Hi,

I think your description is pretty much how it is defined in the specification, see:

https://reference.opcfoundation.org/v104/Core/docs/Part4/5.4.5/ (RegisterServer service call)

https://reference.opcfoundation.org/v104/Core/docs/Part4/7.27/ (the RegisteredServer parameter)

https://reference.opcfoundation.org/v104/GDS/docs/4.2.2/ (flow chart of the process; note that I’m not sure is the “GDS” in the url path a typo, since that is Part 12 of the core specification, unless that is changed recently, which is very well in the realms of possibilities; https://reference.opcfoundation.org/v104/)

So I would say it is most likely a LDS implementation bug, if it wont mark the server as offline. Basically the system relies on the server periodically registering that it is still online and the LDS having a timeout that will mark it as offline and that timer would be refreshed each time the server calls it is online.

Though, once again in my personal opinion, it is a separate question that is that info of any practical use.

If a server would immediately or during the 10min go offline, the info received by a client from LDS would be out of date and not reflecting reality, thus a client cannot assume the server being online ever (i.e. it cannot 100% rely on this info). However it could assume that it is offline if it is not shown online, which could maybe potentially be useful in some complicated reduncancy server setups for chosing e.g. initial server of some set to which to connect to. However, even in this case it would most likely need to see one of them online, which could be outdated info, but it could maybe be a tie-breaker option if it would have to chose from 2 servers (i.e. better anyway to try to connect to the one that is marked as online).

If a server would be repeatedly starting up, registering as online, but then immediately crashing, but then being restarted by some sort of watchdog, we would get a situation where the LDS would continuously show the server as online, but in practice you could never connect to that (or the timing would be very narrow).

Also it should be noted, that this was assuming a separate LDS application was meant, each OPC UA Server will also usually have an internal LDS, that responds to the FindServers calls returning the server. That runs in the “bare port”, without a server name, with the idea I guess that you could in theory have multiple OPC UA servers running on the same port differentiated by the ServerName part of the url only (like a web-server hosting multiple sites etc.). That internal one would typically also shut down when the normal server is shutting down.

We do not have our own (standalone) LDS implemenation (just the internal mentioned above), thus you should report this bug to the implementor of that LDS application. Once your app stops sending the RegisterServer calls the LDS should notice that by itself at most 10mins. Though it should be noted that we do try to call it with it being false if you properly .shutdown the UaServer, so you should be doing the emulation right by doing what you said.

P.S.
Not exactly related, but could be useful info for anyone else reading in the future, the internal LDS cannot respond to FindServersOnNetwork, that is to be only implemented by standalone discoveryservers: https://reference.opcfoundation.org/v104/Core/docs/Part4/5.4.3/