Is it possible in production to use quickfix/j to generate session name from messages

Question

I was wondering if you generally hardcode session names when receiveing FIX messages? I noticed that you can receive FIX messages with the SENDER and TARGET ID's missing.

For example my sessions can look like this:

FIX.4.1:FIX_INBOUND->STANDALONE_INITIATOR

That information can not be built up from certain messages , ie 8=FIX.4.19=4935=D11=137388006585721=138=140=154=155=LNX10=042

So am i correct that you often have to keep track of session names manually?

Answer 1

FIX messages should never be missing SenderCompID and TargetCompID in the header. Whoever is sending that to you is sending you an invalid FIX message.

I can't explain why your QF engine is not rejecting this "D" message. Maybe you have disabled some validation checks in your config. (Or maybe the C++ version of QF doesn't validate those fields the same way as the other QF ports do.)

I suspect, however, that your original Login message/response had the correct IDs, and your engine used those IDs to identify the socket that it setup for your session. After the socket was set up, it stopped verifying the IDs. To be honest, it doesn't really need to on a TCP socket -- once the session is established, any message received on that socket must be part of the same session.

So, to your question, the answer is "No", you should not have to keep track of session names. This situation is highly irregular. Your counterparty is sending you bad messages.

To work around this, though, you can just look at the SessionID that is passed into the QF callbacks. That'll tell you which session this message came from.

Answer 2

> FIX messages should never be missing SenderCompID and TargetCompID in
> the header. Whoever is sending that to you is sending you an invalid
> FIX message.

@Grant - SenderCompID and TargetCompID were not mandatory header fields until FIX 5.0. It's a valid message for FIX 4.1.

@Fututoad - Typically messages on older versions were tracked by their Originating Unique Order ID or ClOrdID (11=13738800658572) and verified against the OMS for which trader made this order (you should look in that for the information or what you use to track trades and ensure traders aren't breaching their risk limits).

Nowadays, as FIX is gaining popularity, those two fields are now required in newer FIX (5.0 onward) message headers to identify the trader making the order and the counter-party at which the order is targeted at.

• 8=FIX.4.1 *Standard Used
• 9=49 *Length
• 35=D *New Order Single
• 11=13738800658572 *Originating Unique Order ID (ClOrdID)
• 1=1 *Account
• 38=1 *Order Quantity
• 40=1 *Market
• 54=1 *Buy Side
• 55=LNX *Ticker
• 10=042 *Checksum