View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
000891910000-014: PubSubSpecpublic2023-04-24 10:222023-06-22 18:01
ReporterMartin Regen Assigned ToMatthias Damm  
PrioritynormalSeverityminorReproducibilityN/A
Status closedResolutionfixed 
Product Version1.05.03 RC1 
Summary0008919: How to handle sequence numbers in JSON headers
Description

The UADP part has a pretty description of how sequence numbers should be handled:

https://reference.opcfoundation.org/Core/Part14/v105/docs/7.2.2.3

However there is no indication in the JSON part, only that it should be monotonically increasing by 1.
Also the UADP number is a UInt16, in JSON its a UInt32.

Specifically there are use cases where the JSON headers may be reset because a Kubernetes pod or a docker container restarted.

The expected behavior would be that the sequence number would restart from 0 or 1 in this case.
How can the subscriber get an indication that the sequence number was restarted?
Could be a keyframe + sequence number 0 indicate that there was a reset?

TagsNo tags attached.
Commit Version
Fix Due Date

Activities

Marc Schier

2023-04-25 07:26

developer   ~0019236

Assumption on my side is that to reset the sequence number the metadata version must have changed. Everything else should be considered as dropped messages.

Jim Luth

2023-04-25 15:30

administrator   ~0019240

Agreed to clarify in Part 14 that the seqeuence number handling for JSON is the same as for UADP.

Matthias Damm

2023-06-21 19:55

developer   ~0019633

Moved chapter "SequenceNumber in headers" one level up to general message mapping.

Reference "SequenceNumber in headers" from Table 164 – JSON DataSetMessage definition

Randy Armstrong

2023-06-22 18:01

administrator   ~0019654

Accepted in Virtual F2F

Issue History

Date Modified Username Field Change
2023-04-24 10:22 Martin Regen New Issue
2023-04-25 07:26 Marc Schier Note Added: 0019236
2023-04-25 15:30 Jim Luth Note Added: 0019240
2023-04-25 15:30 Jim Luth Assigned To => Matthias Damm
2023-04-25 15:30 Jim Luth Status new => assigned
2023-04-25 15:30 Jim Luth Severity feature => minor
2023-06-21 19:55 Matthias Damm Status assigned => resolved
2023-06-21 19:55 Matthias Damm Resolution open => fixed
2023-06-21 19:55 Matthias Damm Note Added: 0019633
2023-06-22 18:01 Randy Armstrong Status resolved => closed
2023-06-22 18:01 Randy Armstrong Note Added: 0019654