FIX protocol assumes complete ordered delivery of messages between parties


Hello, my first participation here. I started working with FIX this week.
I am reading the FIX 4.4 specification Volume 2, page 3, and in the introduction, he says:

FIX was written to be independent of any specific communications protocol (X.25, asynch, TCP/IP, etc.) or physical
medium (copper, fiber, satellite, etc.) chosen for electronic data delivery. It should be noted that if an “unreliable”
or non-stream protocol is used, the Logon, Logout, and ResendRequest message processing is particularly
susceptible to unordered delivery and/or message loss.

but in the FIX MESSAGE DELIVERY >> Ordered Message Processing, he says:

The FIX protocol assumes complete ordered delivery of messages between parties.

Does not this sound a little contradictory?
Because FIX “was written to be independent of any specific communications”, it is natural to conclude that it works with unordered message too.


Not at all. It’s independent of any specific type of protocol, meaning it can use TCP/IP, X.25, UDP etc, it’s not tied to anything specific. The issue noted is that protocols such as UDP don’t use a SYN/ACK message to ensure that if packets are lost they are re-transmitted.So if you are using the UDP protocol and a packet is lost, it is lost and it affects the Logon, Logout, Resend/Request aspects of the message. Which can detrimentally affect your FIX session/message etc.
Edit: Typically UDP or other streaming protocols are sequential, but can become unordered which manifest as skips or glitches in streaming media. Not something good when dealing the FIX protocol


With regard to the application layer, e.g. order processing etc. the order is very important.
It matters whether you first update and then delete an order or vice versa.

@berensn told you about the session layer so I will not repeat it here.