Sequence Number in UAttributes?

[stevenhartley]

Many underlining communication protocols like zenoh, someip etc.. all support adding sequence numbers to the header so you know if a message came out of order. With uProtocol we have the timestamp in the id that allows us to deduce if a message arrived after a newer one and to sort messages however it won't tell us when we got a message out of order till the older one arrives and we do some calculations.

Should we add sequence number to UAttributes? If so should it be optional or mandator? Finally are messages sequenced per-type or in general (i.e. every message we create, we increment the sequence number in UMessageBuilder of the language libraries)?

Apart from adding support to add/remove the sequence numbers, I don't believe the protocol should then do anything specific with the attribute meaning that we shouldn't drop or reorder messages in dispatchers as that would not only complicate our dispatcher design but also can result in additional delays in the transmission of messages.

[evshary]

IMHO, if we don't do anything when we find a missing message, then there is no need to provide such information to users. Users can always add their sequence number in the UPayload if they care about the missing messages, but most of the time we don't need to take any action at that.

Another question for sequence numbers will be how to count the number. Should we increase the number every time we send out the message? Or should it depend on the destination and the message type? For example, if I send Publish data to EntityA, the seq_num will be 1. Then, if I sent Notification data to EntityA, should I increase the number? Furthermore, should I increase the number if I send an RPC Request to EntityB? I think when to increase the seq_num highly depends on the user application and it's difficult to be dealt with in the protocol layer.

[gregmedd]

I agree that it should be trivial to add sequence numbers as needed to the payload. If we don't intend to require uProtocol implementations to do something with the information, it probably doesn't belong in the attributes.

There's also another reason to keep this out of the lower layers of uProtocol: each application is different and likely to have different needs around ordering, dropped messages, and latency. It's easier to add layers on top of uProtocol than to try to bake a solution to every scenario into the base layers.

Maybe it would be helpful to put together an example of how sequence numbers could be added on top of the existing uProtocol APIs?

[stevenhartley]

Closing this issue.