issue with GetLastClientContact and LastTimeoutReset

Questions regarding the use of the ANSI C SDK for Server or Client development or integration into customer products ...

Moderator: uasdkc

Post Reply
Lou_III
Jr. Member
Jr. Member
Posts: 4
Joined: 20 Dec 2013, 18:34

issue with GetLastClientContact and LastTimeoutReset

Post by Lou_III »

I have a UA client who subscribes to our UA server at 50ms for one item only. I am trying to detect a network disconnection on the server side by using the "UaServer_Session_GetLastClientContact" which uses the underlying public member of "LastTimeoutReset" to determine the time of the last reset (which looks to be the last time the client had contact with the server). Problem is the LastTimeoutReset variable seems to be updated at only 500ms. I would like this number to be 100ms or so. I can see that when the client calls a method on the Server side the LastTimeoutReset is immediately reset. How can I get the "LastTimeoutReset" updated a little more frequently on the server side?

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: issue with GetLastClientContact and LastTimeoutReset

Post by Support Team »

Hello Lou_III,

OPC UA is designed in a way that applications (especially servers) should not need to care about temporary network interruptions or network monitoring at all. In case of network interruptions, the subscription mechanism ensures that no data gets lost using the Republish UA service. The timeouts of sessions and subscriptions usually are in a range of many minutes or hours, so network interruptions of a few minutes can be handled without problems.

If you subscribe to a single node with a SamplingInterval of 50ms, this does not mean that there is communication to the server every 50ms. In contrary, OPC UA tries to reduce the number of messages being exchanged to reduce network traffic and server/client load. Depending on the PublishingInterval, the MaxKeepAliveCount and on how often the value actually changes, there might be no communication for some time at all.
Best regards
Unified Automation Support Team

Lou_III
Jr. Member
Jr. Member
Posts: 4
Joined: 20 Dec 2013, 18:34

Re: issue with GetLastClientContact and LastTimeoutReset

Post by Lou_III »

Hello, thank you for your response but your answer is not completely accurate. When you say servers should not care about network interruptions that only is half true. Our server controls real world outputs/relays/sensors. When there is a network interruption and these real world items are no longer being controlled by a client this state must be detected by our server and it must put all outputs/relays/sensors into "safe" states. So it is critial that our OPC server detects when a client got disconnected due to a network cable being pulled or broken. This is a necessary failsafe.

So again I ask, we are using the UaServer_Session_GetLastClientContact function to try and implement some sort of watchdog on the client but the LastTimeoutReset is not consistent (which I guess you explained in your answer.) So what parameters / functions can I change or call to get a required watchdog on the server side at around 100ms ? What is UA's recommendation, surely this can not be the only server in the world that has this type of requirement. Perhaps UaServer_Session_GetLastClientContact is not intended for this kind of usage....what else is there?

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: issue with GetLastClientContact and LastTimeoutReset

Post by Support Team »

Hello Lou_III,

in general, an OPC UA server cannot make any assumptions on clients being connected or not, as any client might be connected to the server at any time.

In your case you might, for example, have a test client connected that knows nothing about any underlying hardware of the server. Your server would then assume that the underlying hardware is being controlled (because one client is connected) and would keep the hardware in running mode, even if the client does nothing about it.

What you intend to achieve is out of scope of OPC UA, as it targets on real-time connection monitoring instead of reliable data transfer. UaServer_Session_GetLastClientContact() is a convenience function to check for the last client contact. As I described earlier, this is not at all intended for checking if the client is still connected, as there might be long periods of time without communication while the connection is still alive. For safety and failsafe operation you need a deterministic (real time) protocol, which OPC UA is not.
Best regards
Unified Automation Support Team

Lou_III
Jr. Member
Jr. Member
Posts: 4
Joined: 20 Dec 2013, 18:34

Re: issue with GetLastClientContact and LastTimeoutReset

Post by Lou_III »

In you example, a Client that knows "nothing" about the h/w attached to the server would not change any parameters anyways so it is harmless (in fact we use the UA Test Client just like this). When a "real" client connects and starts controlling the h/w through OPC UA there should be some way of detecting it's departure through network interruption. Perhaps not "real time" but there should be someway to do this...hard to believe the protocol and UA's implementation of it don't account for something like this. If you think outside the box can you recommend anything to me? It is not good enough to just check the NIC for connections...perhaps the network is physically OK but the program operating the client has crashed. Short of forcing a watchdog to be hit from the client I don't understand how something this basic is not in the protocol already. Am I missing something really really basic?

User avatar
Support Team
Hero Member
Hero Member
Posts: 3064
Joined: 18 Mar 2011, 15:09

Re: issue with GetLastClientContact and LastTimeoutReset

Post by Support Team »

Maybe some basic functions of OPC UA communication are unclear. OPC UA is a fully asynchronous protocol using Request/Response mechanism. The protocol itself is very robust, there are different mechanisms on different layers in the communication that ensure that no data gets lost, not even during (short) network interruption. However the communication is asynchronous, meaning a Client can send a request (e.g. write a value) and the server will (whenever he wants to) send a response back (e.g. success of writing the value). Not being forced to wait infinite, the Client can give a timeout hint within his Request (indicating how long the Client is willing to wait for a Response). When being subscribed to value change, the Client is monitoring the data point for changes (in value, timestamp, status or combination thereof). There is a scan rate and a publish rate, meaning the Server can "fast" scan the data point, put data in a queue and "slow" transfer the complete queued values (no data gets lost, highly efficient transfer) but no guarantee "when exactly" the data will be received. If data is being published (send) during a network interruption the Server will buffer the data and will resend it when connection is up again (sequence numbers and acknowledgement of published data). Again, "no data loss", however no determinism when exactly the data arrives.

There is no difference between "real" Clients and others. Typically there would be several Clients being connected to the Server and read/write values to the same data points. For detecting the presence of one certain Client, the OPC UA way of doing could be a "dead-man-button" in the Server. A certain data point or a UA-Method that needs to be written/called by the Client within a defined time frame ("cyclic" every 50ms). The logic in the Server would validate this "watchdog" and switch all critical "outputs" to a safe value if the "watchdog" was not called/reset in time. This requires "logic/knowledge" on both sides, Client must know which value to write within which timeframe and Server must validate and must know failsafe values to be used whenever the "one" Client is not hitting the "dead-man-button" in time. A permanent "cyclic" data transfer is needed. Again, both this connected Client and Server have a "logical" connection on the application layer, and because of that, it must be implemented/solved in the application (not in the protocol, which tries to avoid wasting bandwidth, and by design has no cyclic transfer of data).

You are the only one asking this, because you are the only one using OPC UA for a use case it was not designed for. If someone needs "cyclic" traffic on the network in a deterministic fashion for very "few" (one) data point, than OPC UA is not the preferred protocol to be used. OPC UA was not designed for IO-control commands. It was designed exactly for the opposite: low bandwidth monitoring of huge amounts of data. You can and you should solve your use case with a standard deterministic (cyclic) field bus having failsafe capabilities. Instead, if you want to transfer hundreds and thousands of data values without loosing data in a very efficient way (only when they really have changed), than you can solve this with OPC UA in a secure fashion. In OPC UA nobody cares on the exact "time" the data arrives, because each value comes with a timestamp, indicating when this value was "real".

So there is nothing "missing" in OPC UA (we are glad that it is not there), OPC UA gives you the option to solve a very application specific problem, in the application layer for your software (but not generally in the protocol layer). E.g. if you must "pay" for every byte you send over the wire (e.g. satellite connection) you would be glad that OPC UA avoids waisting bandwidth. E.g. if you transfer data over an unstable wireless connection you would be glad that the server is not going into failsafe all the time, just because a single telegram (from one of 100 clients) did not came through. E.g. if you write an HMI or MES Client application, why schould there be a watchdog and machine going into stop just because the watchdog was not received for some reason, the machine could probably run for hours without anybody putting in a new recipie or hitting a dead-man button.
Best regards
Unified Automation Support Team

Post Reply