QWFIX run-time automatically manages the FIX sessions. Application developers don't have to deal with all the dirty details at all. All they need to know is that they can send FIX message messages by calling the API, and they can receive messages throug hregistered message handler callbacks. The run-time will manage the actual session control protocol and ensure the best effort quality of service.
Nevertheless, sometimes application do need to understand the "MsgSeqNum" of the incoming and outgoing FIX messages.
The FIX protocol mandates that MsgSeqNum field is embeded into the FIX message header and it is a mandatory field for every FIX message.
QWFIX handles the MsgSeqNum for incoming and outgoing messages in different ways.
For incoming messages, the MsgSeqNum is always the "real one" in the message header, which is the MsgSeqNum assigned to the message the counter-party.
The outgoing message is a little bit tricky. The "SendMessage" method call only writes the message into the persistence and cache the message. The message may not actually be sent at the time the method returns. And it is up to the run-time session control logic when the message can be sent (should happen ASAP, though). The actual MsgSeqNum is unknown at the time. How do we identify the message?
In order to solve the problem, the QWFIX run-time automatically assign an "internal" MsgSeqNum to every outgoing message. It starts from 1 and increments everytime. Uniqueness is guaranteed throughout the session. That "internal" MsgSeqNum is always embeded in the message and it is almost guaranteed that the value is different than the "actual" MsgSeqNum of the message seen by the counter-party.
QWFIX provides methods to access message by both "internal" and "actual" MsgSeqNum and conversion between them. Just keep in mind that value of "MseSeqNum" got from the outgoing message is not "real"!
// FIXSession.sendMessage() returns a message token
|