FIX protocol assumes complete ordered delivery of messages between parties


#1

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.


#2

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


#3

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.