View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000313510000-004: ServicesSpecpublic2015-07-26 08:562017-01-09 14:56
ReporterMatthias Damm Assigned ToMatthias Damm  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.03 
Summary0003135: Variations of PublishingInterval handling
Description

There may be different scenarios where the strict handling of the PublishingInterval makes no sense:

(1) Client and/or server want to reduce latency to a minimum but still need to optimize network transport
This would require a combination of PublishingInterval as maximum wait time but should allow a server to send a Publish response if data is collected (e.g. an internal sampling class was executed) or an important event is available.

(2) Max message size is reached
In subscriptions that produces a lot of data, max message size (or any other max parameter like may array size) may be reached before the PublishingInterval expires

Additional Information

There are different options to solve this:

(1) Allow use of negative values
-> Negative value is setting the behavior
-> Value is the max wait time

(2) Add a configuration method for subscriptions that sets the behavior

(3) Just allow a server to do this optimization
The current description of revisedPublishingInterval may allow this already:
'The Server should attempt to honour the Client request for this parameter, but may negotiate this value up or down to meet its own constraints.'

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Jim Luth

2015-08-18 15:44

administrator   ~0006303

Need to discuss when Matthias is on the call to agree on a mechanism for this.

Matthias Damm

2016-12-20 17:29

developer   ~0007675

Discussed in UA WG:

Simple solution would be to give a server more control over the send time (PublishResponse).

TBD:
Check if this is already allowed.
Prepare a proposal for a descripiton of conditions where we want to allow this or where it makes sense.

Matthias Damm

2017-01-05 10:13

developer   ~0007696

Added the following clarification:
A Client must be prepared for receiving Publish responses faster than the publishing interval. One example is the situation where the number of available notifications exeeds the Subscription setting maxNotificationsPerPublish. A Client is always able to control the timing of the Publish responses by sending less Publish requests. If a Client does not queue Publish responses in the Server, the Server can send only a Publish response if it receives a new Publish request. This would increase latency for delivery of notifications but allows a Client to throttle the number of received Publish responses in load situations.

Made changes in document version OPC UA Part 4 - Services 1.04 Specification Draft 07.docx

Jim Luth

2017-01-09 14:56

administrator   ~0007701

Agreed to changes edited in telecon.

Issue History

Date Modified Username Field Change
2015-07-26 08:56 Matthias Damm New Issue
2015-07-26 08:56 Matthias Damm Severity minor => major
2015-08-18 15:44 Jim Luth Assigned To => Matthias Damm
2015-08-18 15:44 Jim Luth Status new => assigned
2015-08-18 15:44 Jim Luth Note Added: 0006303
2016-12-20 17:29 Matthias Damm Note Added: 0007675
2017-01-05 10:13 Matthias Damm Note Added: 0007696
2017-01-05 10:13 Matthias Damm Status assigned => resolved
2017-01-05 10:13 Matthias Damm Resolution open => fixed
2017-01-09 14:56 Jim Luth Note Added: 0007701
2017-01-09 14:56 Jim Luth Status resolved => closed
2017-01-09 14:56 Jim Luth Fixed in Version => 1.04