re: FIX over HTTP or TCP
Ryan Pierce / Townsend Analytics Ltd. / Archipelago LLC
26 Feb 2003 4:16PM ET> I've got another question regarding how FIXML is transported. Usually XML is transported over HTTP, I am just just wondering whether FIXML is over HTTP or not. If not, what is the performance implication of HTTP vs TCP??
FIX (not FIXML) has a defined message representation (Tag=Value[SOH]) and a session layer that supports message sequencing and checksums. In theory, any transport mechanism, reliable or unreliable, could be used for FIX. In practice, FIX's recovery mechanisms aren't robust enough to maintain business connectivity over an unreliable transport mechanism like UDP or a noisy modem connection with no error correction.
So in practice, almost all FIX is run over TCP, which is a reliable transport protocol. However, nothing in the FIX spec dictates that TCP must be used.
FIXML, unlike FIX, has no defined session layer, checksum, or sequence numbering. FIXML defines business content only, and it must rely on something else to provide reliable, ordered message delivery.
The only method currently defined for transporting FIXML is to encapsulate it inside a normal Tag=Value FIX message (which usually sits on top of TCP.) FIX will provide for ordered, reliable delivery, and FIXML conveys all the business content.
Anything else could be used as well, as long as it provides for ordered, reliable message delivery. (Imagine the business implications of line noise transposing the letters of the symbol for an order, or re-ordering messages so that a Cancelled message for an order comes before a Partially Filled message!)
Currently, the Global Derivatives working group is investigating defining a standard way to send FIX over MQSeries. I don't know of anyone doing FIXML over HTTP, but I'd imagine you'd need some other layer in addition to handle ordering your messages, detecting message gaps, etc.
