9/24/2023 0 Comments Protocol message sequence diagram![]() Often a provider will want to maintain sequence numbers between disconnects. If you have two FIX sessions, then each session is tracking a pair of sequences. Every time the app receives a message, it increments the expected incoming number and makes sure the incoming message's tag 34 matches it.Every time the app sends a message, it increments the outgoing sequence number and sets it in tag 34.These sequence numbers are independent of each other. However I don't understand the relation between tag 34 and the internal sequence numbers.Īny FIX application must maintain two sets of sequence numbers per session: the incoming and the outgoing. I am guessing that this is because there might be GTC orders resting at the exchange and the two engines might 'sink up' on these resting orders upon a successful logon. The internal sequence numbers of the FIX ENGINE to the exchange are not reset to 1,1. In this configuration the Sell side FIX ENGINE's internal sequence numbers are reset to 1,1 upon login. However, it seems that each of these FIX engines has a INCOMING SEQUENCE number (what FIX engine is expecting for counter party) and an OUTGOING SEQUENCE NUMBER (what FIX engine is sending to counter party).Īre these internal sequence numbers independent of tag 34? There are two FIX adapters - one recieving the messages from the sell side and serving the messages to the process.Īnd another FIX engine that takes the messages from the process and sends them in FIX to the exchange.Įvery FIX message has a unique sequence number dented by tag 34. I have a process between the Sell side client and an exchange that does currency conversons. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |