View Issue Details

IDProjectCategoryView StatusLast Update
0006996NodeSets, XSDs and Generated CodeApi Changepublic2021-07-06 16:50
ReporterJim Luth Assigned ToRandy Armstrong  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Summary0006996: Keep-alive message in JSON unclear or unfeasible
Description

In JSON DataSetMessage text, we have: "DataSetWriters may periodically provide keep-alive messages which are DataSetMessages without any Payload field.".

This needs explanation - or need to be removed.

The period mention here cannot be the normal KeepAliveTime because its minimum is PublishingInterval, and there WILL be one DataSetMessage each PublishingInterval, because there are no delta frames and no event messages in JSON.

So, can there ever be a keep-alive in JSON? Or, is it meant to provide a keep-alive that is somehow more frequent than the PublishingInterval? How would that be configured - and would it be good for anything (I doubt it)?

TagsNo tags attached.
Commit Version
Fix Due Date

Relationships

related to 0005372 closedMatthias Damm 10000-014: PubSub Keep-alive message in JSON unclear or unfeasible 

Activities

Matthias Damm

2021-06-07 17:38

reporter   ~0014484

KeepAlive message depend on the parameter

  • PublishingInterval (WriterGroup)
  • KeepAliveTime (WriterGroup) (The minimum value shall equal the PublishingInterval)
  • KeyFrameCount (DataSetWriter)

These three parameters are independent of the Message Mapping.

If KeyFrameCount is 0 or >1, there can be KeepAlive messages (also for JSON message mapping)

Zbynek Zahradnik

2021-06-07 17:38

reporter   ~0014485

I disagree with MatthiasD's note https://opcfoundation-onlineapplications.org/mantis/view.php?id=5372#c12220 .

The part where he has it wrong is: "If KeyFrameCount is 0 or >1, there can be KeepAlive messages (also for JSON message mapping)".
That might be what the intent of the spec was, but the spec does not allow that currently.

In reality, the Delta Frames are only defined in UADP mapping. As opposed to that, for JSON, the spec does not describe that they exist, nor how they should look like. The only logical conclusion for the reader is that they do not exist in JSON - because he cannot construct them.

Matthias Damm

2021-06-07 17:38

reporter   ~0014486

Technically Delta Frames exist for JSON. The spec may be silent on it.

In UADP Delta Frames are special since they contain an array of index/value pairs for the changed fields.
In JSON, the name of the field is always provided and therefore the index is not necessary.
A Delta Frame with JSON is just a regular message that does not contain all fields.

If the missing clarification for Delta Frames is the only remaining issue, this can be fixed.

Matthias Damm

2021-06-07 17:38

reporter   ~0014487

Added clarification for key and delta frames in JSON encoding:

7.2.3.3 DataSetMessage
A key frame DataSetMessage or an event based DataSetMessage contains name and value for all fields of the DataSet.
A delta frame DataSetMessage contains only name and value for the changed fields.

Added in OPC 10000-14 - UA Specification Part 14 - PubSub Draft 1.05.26.docx

Zbynek Zahradnik

2021-06-07 17:38

reporter   ~0014488

I think the clarification resolves 99% of the issue, thank you.

But I am reopening this issue just for one last consideration: If both delta and key frames exist in JSON, and their only distinction is that the key frame "contains all fields", it is impossible to distinguish key frames without having the metadata. You can say that this was the intent and that the subscriber always must have the metadata. But, it would be easy to resolve it e.g. by adding something MessageSubtype or MessageKind field to JSON NetworkMessage header.

Consider the following use cases where the necessity to have the metadata causes a problem:

The Delta Frames is basically a protocol-only concept to save bandwidth. Semantically, on the application level, it "should not exist": a (data-based) DataSet is is seen by the consuming application as a stream of incoming "packets" where each packet has all the fields.

If all you want to do is, for example, transform the stream with Delta/Key frames to a stream that can be consumed by the application (the one that always has all fields), you need to assemble the data from the last Key Frame and the data from subsequent Delta Frames. This means that you cannot emit any data to the application before the first Key Frame arrives. If you have explicit indication of which frame is the Key Frame (as it is in UADP), you can simply wait for a message with that indication. But with JSON, I would have no way to tell which frame is the key frame, without having to do all the stuff that relates to obtaining the metadata. I cannot, for example, write a simple logger that would log one DataSet data per row, without the metadata. I cannot even write a processor that would remove the Delta Frames and generate a stream with Key Frames only, for easy consuming by other applications, without the metadata. And what's missing is really just a single bit of information that would distinguish the Key Frames from Delta Frames.

Matthias Damm

2021-06-07 17:38

reporter   ~0014489

Added MessageType to 6.3.2.3.1 DataSetMessageContentMask
Added MessageType to 7.2.3.3 DataSetMessage

Jim Luth

2021-06-07 17:38

administrator   ~0014490

Agreed to changes edited in Draft 1.05.27 in virtual F2F.

Matthias Damm

2021-06-07 17:38

reporter   ~0014491

We should have an 1.04 errata for this issue

Matthias Damm

2021-06-07 17:38

reporter   ~0014492

Added to errata 1.04.10
Need to clone to Nodeset for 1.04.10

Jim Luth

2021-06-07 17:40

administrator   ~0014493

Bitmask needs to be defined in 1.04.10 nodeset.

Randy Armstrong

2021-07-03 08:10

administrator   ~0014620

Add MessageType bit to JsonDataSetMessageContentMask.

Randy Armstrong

2021-07-06 16:50

administrator   ~0014655

Reviewed in UA WG meeting.

Issue History

Date Modified Username Field Change
2021-06-07 17:38 Jim Luth New Issue
2021-06-07 17:38 Jim Luth Status new => assigned
2021-06-07 17:38 Jim Luth Assigned To => Randy Armstrong
2021-06-07 17:38 Jim Luth Issue generated from: 0005372
2021-06-07 17:38 Jim Luth Note Added: 0014484
2021-06-07 17:38 Jim Luth Note Added: 0014485
2021-06-07 17:38 Jim Luth Note Added: 0014486
2021-06-07 17:38 Jim Luth Note Added: 0014487
2021-06-07 17:38 Jim Luth Note Added: 0014488
2021-06-07 17:38 Jim Luth Note Added: 0014489
2021-06-07 17:38 Jim Luth Note Added: 0014490
2021-06-07 17:38 Jim Luth Note Added: 0014491
2021-06-07 17:38 Jim Luth Note Added: 0014492
2021-06-07 17:38 Jim Luth Relationship added related to 0005372
2021-06-07 17:39 Jim Luth Project 10000-014: PubSub => NodeSets, XSDs and Generated Code
2021-06-07 17:39 Jim Luth Category Spec => Api Change
2021-06-07 17:40 Jim Luth Note Added: 0014493
2021-07-03 08:10 Randy Armstrong Status assigned => resolved
2021-07-03 08:10 Randy Armstrong Resolution open => fixed
2021-07-03 08:10 Randy Armstrong Note Added: 0014620
2021-07-06 16:50 Randy Armstrong Status resolved => closed
2021-07-06 16:50 Randy Armstrong Note Added: 0014655