SeqNum wars
Tag 34 (MsgSeqNum) orders every session message. Gaps look like data loss; duplicates look like replay attacks.
Incident of the day — Alice rebooted at 09:00. She Logged on with
34=1while Bob still expected34=847. ResendRequest fireworks ensued.
Gap fill
If Bob receives 34=850 but last was 848, he sends ResendRequest (35=2) asking for 849 onward. The peer Resends (35=4) with PossDupFlag=Y (43=Y).
Clean reset
Sunday maintenance? Logon may carry ResetSeqNumFlag (141=Y) so both sides restart at 1 — only when both agree.
Rules of thumb
| Situation | Typical action |
|---|---|
| Small gap after blip | ResendRequest |
| Planned restart | Logon + 141=Y |
| App message dup | Check 43=Y before acting |
4H SessionManager tracks inbound/outbound seq — application code should treat PossDupFlag seriously on business messages.