Replaying messages in FIX protocol
In FIX Protocol two FIX engines communicate with each other using FIX messages and every FIX messages is assign with unique sequence number denoted by tag 34. Apparently every FIX engine has two sequence numbers Incoming Sequence Number (which FIX engine is expecting from counter party) and Outgoing Sequence Number (which FIX engine is sending to counter party). This sequence numbers along with rules specified in FIX protocol technical specification ensures that no FIX engine should lose any FIX messages in the event of any disconnect.
In this FIX Protocol Tutorial we will discuss some scenarios where disconnect between two FIX Engine occurs and how they recover from that situation. Normally disconnect and reconnect can cause replay of messages which would be require from either party e.g. either client or broker based upon who has higher sequence number.
This FIX Protocol Tutorial is in continuation of my earlier tutorial FIX Protocol Session or Admin messages tutorial and Difference between FIX 4.2 vs FIX 4.4 in FIX connectivity.
