View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000960 | 10000-004: Services | public | 2010-02-04 09:27 | 2012-02-09 22:46 | |
Reporter | Wolfgang Mahnke | Assigned To | Matthias Damm | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.01 | ||||
Fixed in Version | 1.02 | ||||
Summary | 0000960: Publish and reconnect problem | ||||
Description | When client and server are losing the connection the client reestablishes the connection. There are cases when the connection gets lost when the server has sent a Publish response but the client has not received it. Then the client needs to call a Republish. The client can identify that a Publish message was lost as soon as he gets the next Publish response from the server. Typically this will happen soon after reconnect when the server has new data to publish. However, if the server does not have new data to publish it waits until the keep alive is send. That means that in this case the client identifies the lost publish after the keep-alive was send from the server. This is not perfect, especially if a low keep-alive frequency is chosen. Potential solutions:
| ||||
Tags | No tags attached. | ||||
Commit Version | |||||
Fix Due Date | |||||
related to | 0001826 | closed | Paul Hunkar | 10000-007: Profiles | Resolution to Mantis issue 960 causes significant increase in RAM requirements for Embedded Datachange Subscription Server Facet |
|
If you force the client to ask for republish, this will cause other issue with long lasting disconnection. One possible solution is to force the server to assume that, after a disconnection, the "unacknowledge" items as been lost so they need to be retransmitted in the right order. The only issue is if the SourceTimestamp is not transmitted, the client will not be able to identify which data as already been received. Following this rule, the client may use the timestamp to identify already received items, which is quite simple. |
|
We agreed that the worst case in a reconnect scenario the client may not detect a missting message for 2X the keep alive interval (instead of the normal one). Also the client may want to temporarily set a shorter keep alive interval after a reconnect to remedy this. To do this an SDK that does auto reconnect needs to notify the client that a reconnect occured. This scenario should be described in the spec. Also we need to make this normative change to Clause 5.13.1.1 (changed one interval to three intervals) i) Subscriptions maintain a retransmission queue of sent NotificationMessages. NotificationMessages are retained in this queue until they are acknowledged or until they have been in the queue for a minimum of three keep-alive intervals. Clients are required to acknowledge NotificationMessages as they are received. |
|
UA WG meeting March 16
|
|
Updated the minimum requirement for the retransmition queue of sent NotificationMessages from one to three keep-alive intervals but allowed the server to restrict the size of the queue to two times the minimum number of Publish requests per Session. Change is part of the draft version "OPC UA Part 4 - Services Draft 1.02.03 Body.doc" |
|
Reviewed in telco on March 23, 2011 |
|
This change was not reviewed yet. |
|
Need to enhance reconnect description in Republish. Proposed change: |
|
Added new chapter 6.4 Re-establishing connections. Changed in document version OPC UA Part 4 - Services 1.02.06 Draft.doc |
|
Discussed at F2F |
|
Need to add sentance indicating what to do if repiblish misses something and also that a profile may change the minimum count |
|
Updated Text: Added text to 5.13.1 Subscription model -> 5.13.1.1 -> (i) Added text to 6.4 Re-establishing connections Changed in document version OPC UA Part 4 - Services 1.02.11 Draft.doc |
|
Reviewed and agreed to changes in telecon. |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-02-04 09:27 | Wolfgang Mahnke | New Issue | |
2010-02-05 13:23 | Claude Lafond | Note Added: 0001522 | |
2010-03-30 18:05 |
|
Note Added: 0001622 | |
2010-03-30 18:05 |
|
Status | new => assigned |
2010-03-30 18:05 |
|
Assigned To | => Matthias Damm |
2011-03-16 21:38 | Matthias Damm | Note Added: 0002434 | |
2011-03-18 02:30 | Matthias Damm | Status | assigned => resolved |
2011-03-18 02:30 | Matthias Damm | Resolution | open => fixed |
2011-03-18 02:30 | Matthias Damm | Note Added: 0002503 | |
2011-03-23 06:55 | Randy Armstrong | Status | resolved => closed |
2011-03-23 06:55 | Randy Armstrong | Note Added: 0002526 | |
2011-03-23 09:28 | Matthias Damm | Status | closed => resolved |
2011-03-23 09:28 | Matthias Damm | Note Added: 0002527 | |
2011-05-23 16:05 | Matthias Damm | Status | resolved => feedback |
2011-05-23 16:05 | Matthias Damm | Resolution | fixed => reopened |
2011-05-23 16:05 | Matthias Damm | Note Added: 0002726 | |
2011-09-06 21:39 | Matthias Damm | Status | feedback => resolved |
2011-09-06 21:39 | Matthias Damm | Resolution | reopened => fixed |
2011-09-06 21:39 | Matthias Damm | Note Added: 0002915 | |
2011-09-15 16:30 | Randy Armstrong | Status | resolved => closed |
2011-09-15 16:30 | Randy Armstrong | Note Added: 0002998 | |
2012-01-08 14:34 | Paul Hunkar | Relationship added | related to 0001826 |
2012-01-11 15:17 | Paul Hunkar | Status | closed => feedback |
2012-01-11 15:17 | Paul Hunkar | Resolution | fixed => reopened |
2012-01-11 15:17 | Paul Hunkar | Note Added: 0003157 | |
2012-01-11 15:44 | Matthias Damm | Status | feedback => resolved |
2012-01-11 15:44 | Matthias Damm | Resolution | reopened => fixed |
2012-01-11 15:44 | Matthias Damm | Note Added: 0003166 | |
2012-01-17 18:11 | Jim Luth | Status | resolved => closed |
2012-01-17 18:11 | Jim Luth | Note Added: 0003203 | |
2012-02-09 22:46 | Jim Luth | Fixed in Version | => 1.02 |