Skip to content

Conversation

@ttypic
Copy link
Contributor

@ttypic ttypic commented Jul 17, 2025

Clarify that msgSerial should reset to 0 on clean connection attempts, including reconnects after SUSPENDED.

There is nothing in the spec about going back from SUSPENDED, and we have different implementation at least in js and java. js resets msgSerial after suspended, java doesn't. msgSerial reset is mentioned in resume attempts and manual connect() after terminal states.

Clarify that `msgSerial` should reset to `0` on clean connection attempts, including reconnects after `SUSPENDED`.
Copy link
Member

@SimonWoolf SimonWoolf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sort of requirement does not belong in TRxx, which is just listing the fields of a ProtocolMessage. Should be in the RTN section.

RTN15g already states:

** @(RTN15g)@ Connection state is only maintained server-side for a brief period, given by the @connectionStateTtl@ in the @connectionDetails@, see "CD2f":#CD2f. If a client has been disconnected for longer than the @connectionStateTtl@, it should not attempt to resume. Instead, it should clear the local connection state, and any connection attempts should be made as for a fresh connection

"clear the local connection state" technically does already imply setting the msgSerial to 0. But it's implicit; worth rewording that item to make it more explicit exactly what should be cleared (connectionId, connectionKey, msgSerial) if people are confused.

@lawrence-forooghian
Copy link
Collaborator

lawrence-forooghian commented Sep 17, 2025

I was doing something similar in #381 just now but realised that it's basically the same as this — I'm happy to take this one over if you want @ttypic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants