Hello!
I know that the SDK handles connection interruptions. If I understand it correct, an interruption of up to 20 minutes should be no problem.
Our server implementation delivers an array of values which is normally updated every second. In the client I have a monitored item to track the data changes. The order of the data packages is important. On interruptions I expect that I get all the data which could not be delivered in the correct order. After an interruption of two minutes I should get 120 packages at once.
We have a wireless setup with a lot of these interruptions and I want to ensure that the data is still valid.
Is there anything I need to take care off if I want to write a client which can handle such interruptions?
Order of data after network connection interruption
Moderator: uasdkcpp
-
haribo
- Full Member
- Posts: 9
- Joined: 24 Jan 2014, 12:06
-
Support Team
- Hero Member
- Posts: 3068
- Joined: 18 Mar 2011, 15:09
Re: Order of data after network connection interruption
Hi,
The general statement "an interruption of up to 20 minutes should be no problem" is not completely right.
There are different client requested and server revised settings involved.
(1) Session Timeout
This is the time in milliseconds the server will keep sessions alive even if no client request is received. The default for the C++ client SDK is 20 minutes (1200000ms) but this setting depends on the client configuration.
(2) Subscription Lifetime
The lifetime is a counter for the number of times the publish timer checks for new data to send without having a connection to the client available (Publish request available).
If the PublishInterval is set to 500ms, the LifetimeCount must be set to 2400 to have also a 20 minutes timeout on the subscription
If the settings for (1) and (2) are in sync, Subscriptions and Sessions can be reused after a connection interruption and the collected data in the subscription will be delivered if the reconnect is successful before the timeouts expire.
(3) MonitoredItem queue size
The amount of data delivered after a connection interruption is also requested by the client (and revised by the server). This is based on the monitored item queue size. If you expect a value change every second and you want to have all data received for a up to 20 minutes network interruption, the queue size must be set to 1200.
All data must be delivered in order (per monitored item) after the connection interruption.
In the case of an queue overflow, the server deletes the oldest value (depends on MonitoredItem DiscardPolicy setting) and sets a flag in the status code of the next value to indicate that a value was lost.
If you want to provide a more reliable and client independent delivery on the server side you should provide data history for the important variables in the server. You can create ring buffer of configurable length in the server and a client can use HistoryRead Raw to get the missed data in the case of a longer network interruption.
The following server example creates an in memory ring buffer for some variables in the server. A real server should persist the data.
http://documentation.unified-automation ... son07.html
Best Regards,
Unified Automation Support Team
The general statement "an interruption of up to 20 minutes should be no problem" is not completely right.
There are different client requested and server revised settings involved.
(1) Session Timeout
This is the time in milliseconds the server will keep sessions alive even if no client request is received. The default for the C++ client SDK is 20 minutes (1200000ms) but this setting depends on the client configuration.
(2) Subscription Lifetime
The lifetime is a counter for the number of times the publish timer checks for new data to send without having a connection to the client available (Publish request available).
If the PublishInterval is set to 500ms, the LifetimeCount must be set to 2400 to have also a 20 minutes timeout on the subscription
If the settings for (1) and (2) are in sync, Subscriptions and Sessions can be reused after a connection interruption and the collected data in the subscription will be delivered if the reconnect is successful before the timeouts expire.
(3) MonitoredItem queue size
The amount of data delivered after a connection interruption is also requested by the client (and revised by the server). This is based on the monitored item queue size. If you expect a value change every second and you want to have all data received for a up to 20 minutes network interruption, the queue size must be set to 1200.
All data must be delivered in order (per monitored item) after the connection interruption.
In the case of an queue overflow, the server deletes the oldest value (depends on MonitoredItem DiscardPolicy setting) and sets a flag in the status code of the next value to indicate that a value was lost.
If you want to provide a more reliable and client independent delivery on the server side you should provide data history for the important variables in the server. You can create ring buffer of configurable length in the server and a client can use HistoryRead Raw to get the missed data in the case of a longer network interruption.
The following server example creates an in memory ring buffer for some variables in the server. A real server should persist the data.
http://documentation.unified-automation ... son07.html
Best Regards,
Unified Automation Support Team
-
Lafond
- Hero Member
- Posts: 25
- Joined: 14 Oct 2008, 12:55
Re: Order of data after network connection interruption
Hi
Year ago, while implementing OPC UA ADI server, we encounter the same use case, just playing with the parameters above was almost enough!
We encounter two issues after reconnection:
1) The youngest value is sometime sent before unspooling the older values. This is not acceptable to some Historian which require always increasing time. This is also more difficult to know when unspooling is completed.
2) If you have multiple tags, the unspooling order of tags relative to each other was not what we expect. The behavior was: The first tag is unspooled, then the next one and so on. If you need to align data, this must be done on client side.
Knowing that, it is possible to create a fifo on the client side to align everything before pushing the data to an Historian which requires that the timestamp of the data is always increasing and at the same time knows when unspooling is completed.
Hoping this may help
BR
Year ago, while implementing OPC UA ADI server, we encounter the same use case, just playing with the parameters above was almost enough!
We encounter two issues after reconnection:
1) The youngest value is sometime sent before unspooling the older values. This is not acceptable to some Historian which require always increasing time. This is also more difficult to know when unspooling is completed.
2) If you have multiple tags, the unspooling order of tags relative to each other was not what we expect. The behavior was: The first tag is unspooled, then the next one and so on. If you need to align data, this must be done on client side.
Knowing that, it is possible to create a fifo on the client side to align everything before pushing the data to an Historian which requires that the timestamp of the data is always increasing and at the same time knows when unspooling is completed.
Hoping this may help
BR
-
Support Team
- Hero Member
- Posts: 3068
- Joined: 18 Mar 2011, 15:09
Re: Order of data after network connection interruption
Hi,
The ordering of multiple monitored items is not defined by the OPC UA specification. If this is relevant to your application, you must implement your own ordering and synchronization of the notifications between the different monitored items.
But the OPC UA 1.02 specification update included different enhancements and more detailed definitions for reconnect and queue handling. If the 1.02 behavior is implemented right by all OPC UA clients and server, there should be no out of order delivery of data for a monitored item.
The C++ SDK 1.4 implements the behavior defined in the OPC UA 1.02 specification. In addition we fixed some related issues.
Best Regards,
Unified Automation Support Team
The ordering of multiple monitored items is not defined by the OPC UA specification. If this is relevant to your application, you must implement your own ordering and synchronization of the notifications between the different monitored items.
But the OPC UA 1.02 specification update included different enhancements and more detailed definitions for reconnect and queue handling. If the 1.02 behavior is implemented right by all OPC UA clients and server, there should be no out of order delivery of data for a monitored item.
The C++ SDK 1.4 implements the behavior defined in the OPC UA 1.02 specification. In addition we fixed some related issues.
Best Regards,
Unified Automation Support Team