A Perspective in Transport Independence Framework
Mahesh Kumaraguru <>
16 Oct 2007 1:34AM ET
Hi FIX Folks,
I would like to share a perspective in Transport Independence Framework.
Actors in a FIX Buy client - FIX Sell Server connection are
1) Producer - source of business messages.
2) Transport - takes business messages at one point and delivers it at another point maintaining strict order as produced in 1). Transport is a black box to the producer and consumer, but internally has three players :-
2.1) End point at Producer - mediates between producer and mover.
2.2) Mover - Physically moves the data between End point at Producer to End point at Consumer.
2.3) End point at Consumer - mediates between mover and consumer.
3) Consumer - destination of business messages.
I am trying to look at modified FIX Message structure(s) and its parsing / validation sequence from the Transport Independence Framework point of view. Take a sample message with this structure (note differences in placement of Tags) :-
1.--------Header----------------------------------------|---Body-----------------------------------|-Tail-|
2.--------Header--------------------------|-----------------Body-----------------------------------|-Tail-|
8=FIX.6.0^9=123^34=456^49=SENDER^56=TARGET^35=D^1128=100^55=MAX^54=1^38=1000^11=7890^21=3^40=1^59=0^10=007^
Note :- In the above FIX message ^ represents FIX delimiter SOH char, Body length[9] and CheckSum[10] may be incorrect (random numbers from my head), formatting may be lost / line maybe broken / wrapped because of window width.
Now, walkthru the psuedocode of parser / validator for the above message could be as follows :-
Step-1) Check Begin string [8], get FIX Version.
Step-2) Check Body length [9], read body length chars into buffer.
Step-3) Check End of Message [10] is present, verify Checksum.
Step-4) Check Message Sequence number [34]. Compare seqn num of this message with Next expected sequence number:-
4.1) Less - Do Poss Dup [43] / Poss Resend [97] processing.
4.2) Greater - put this message on pending queue, Do Resend request.
4.3) Equal - continue parsing.
Step-5) Check Comp IDs - Sender CompID [49], Target CompID [56] and other CompIDs which are present.
Step-6) Check Message Type [35],ApplVerID [1128], CstmApplVerID[1129]
Step-7) Parse message body (the remaining bytes in the buffer) and validate based on FIX Version[8], Message type[35], ApplVerID[1128], CstmApplVerID[1129]
Step-8) Perform FIX Action based on 7) and Current state of Session.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Transport applies checks from 1) to 5) to ensure that
1) Message integrity is maintained.
2) Order of messages is maintained.
3) Message is delivered to the valid destination.
End point at Consumer performs Step 6) and 7) and delivers only the application part of successful messages to Consumer (many tags of the session part are not needed by consumer). But it should be noted here that there will be fields in Header like CompIDs which would be needed by Consumer to know who's business object it is dealing with.
Then the consumer applies Step 8) and becomes Producer of "Response FIX message" - the circle starts over :-)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
From the above, I conclude the following :-
1. Decoupling Session and Application layers is necessary for Transport Independence. This decoupling should improve performance in most (if not all) Transports.
2. Newer versions of FIX should move away from the "bag of tags" style message structures, ie all session tags should come before any business tags and these two cannot occur intermixed in a valid FIX message. The FIX message has three parts - header followed by body followed by trailer. The transport / session use only header and trailer and requires no tags occuring in the body. The only non body tags required by application are CompIDs, all other tags the Application uses are only from body and no other tags from the header and / or trailer are needed.
3. Message Type[35] should be moved down to "end of header" or "start of body" :-(Both may not mean the same to me, Refer http://fixprotocol.org/discuss/read/d5962a4b :-)
If a FIX message of older version comes in the pipe (with FIX Version[8] = FIX.4.0 and / or Message Type[35] in position 3), then Transport will ignore Tag(s) that are needed later in processing in this new FIX format and look for other Tags which are required to do the Transport. This flexibility is in place to support backward compatibility till producer and consumer applications are not upgraded to this newer Fully Transport Independent FIX version. The downside is, FIX messages in older formats would cause poorer performance due to the need to parse a "full bag of tags" - the transport layer would need to parse thru many business tags before finding all fields needed for transport.
4. XMLDataLen[212] and XMLData[213] may be moved to body. Anyway if XML/FIXML content is to be sent, we can use MesgType[35]=n
5. Message Type[35], ApplVerID[1128] and CstmApplVerID[1129] should come next to each other before other tags in the message body.
6. This may also pave the way to permit multiple FIX message bodies to be carried in a "single" FIX message - repeating group of messages.
7. Another use I can think of is Non-FIX trading platforms integration. Define custom Message Type[35] = UN like U1, U2 etc. and in Format 1. of the FIX message above, replace the Body (55=MAX^54=1^38=1000^11=7890^21=3^40=1^59=0) with a non-FIX record. All the fields required to perform reliable Transport and maintain Session are available in the header and Trailer.
Based on the above logic, the Structure of a Transport Independent FIX Message should be:-
----------------------------------
Note : In the below represtation:-
+ represents strict order - ie "a + b" means "b always follows a"
# represents interchangeable order - ie "a # b" means a and b come next to each other in any order, ie "a b" and "b a" are both valid.
- - - - - - - - - - - - - - - - - - -
FIX Message = Header + Body + Trailer
Header = BeginString[8] + Body length[9] + MesgSeqNum[34] + DupFlags +
CompIDsGroup + OtherHeaderFields + TimeDetails + EndOfHeader
DupFlags = PossDup[43] # PossResend[97] # LastMsgSeqNumProc[369]
TimeDetails = SendingTime(52) + OrigSendingTime(122)
CompIDsGroup = SenderCompID[] # TargetCompID[] + otherCompIDs
otherCompIDs in any order between them.
OtherHeaderFields = SecureFields + MessageEncoding[347] + HopsGroup
SecureFields = SecureDataLen[90] + SecureData[91]
HopsGroup = NoHops[627] + HopCompID[628] + HopSendingTime[629] + HopRefID[630]
EndOfHeader = MesgType(35) + ApplVerID(1128) + CstmApplVerID(1129)
//End of Header may be redefined as Start of Body ;-)
Body = Tags of the Business message
Trailer = SignatureLength(93) + Signature(89) + CheckSum(10)
- - - - - - - - - - - - - - - - - - - -
Please share your views on this subject.
Regards,
K. Mahesh
+1-203-252-4039
