[This message was posted by Ryan Pierce (FPL Technical Director) of FIX Protocol Ltd. <ryan.pie...@fixprotocol.org> to the "General Q/A" discussion forum at http://fixprotocol.org/discuss/22. You can reply to it on-line at http://fixprotocol.org/discuss/read/66307e53 - PLEASE DO NOT REPLY BY MAIL.]
> I'm just curious about something with respect to things like message > throttling - isn't that the whole point of having seperated the session > layer from the application layer in FIX 5.0/TIF? This is a very interesting point. While the session/application split happened back in 2006, it is important to note that this does not dictate software architecture. Just because FPL says Message X is part of FIXT.1.1 and Message Y is part of FIX 5.0 does not mean that the function behind Message X must be implemented solely by FIX engines, and the function behind Message Y must be implemented solely by business applications. Further, the concept of FIX gateways, which sit between business applications and FIX engines, muddy the water. I think it important to distinguish between the component(s) implementing a concept (e.g. FIX engine or business application) and whether something is defined in the session or application layer. > Why would any of this be implemented at the application layer in a FIX- > based application? It just seems like this is so naturally suited to the > session layer of the system - e.g. this is what a session layer is all > about in the first place, why would this need to impact application > layer messages? I would say throttling is an unusual use case that occupies an interesting position at the border between the two layers. Throttling, clearly, can be a very low level concept. But there are nuances that affect higher layers. For example, the case of algo and retail order flow sharing a FIX session is mentioned in the Gap Analysis. A typical black box algo trading system considers any latency to be hazardous. If a throttle limit is exceeded, the last thing such a system would want is for the recipient to queue it (possibly until the next second) and wait before processing it. An immediate reject is far preferable. But a retail investor clicking a button on a web page probably doesn't have the same latency requirement, and having the order rejected would be problematic. So the Gap Analysis identifies an application-level field (ThrottleInst) defined within specific application-level messages (e.g. New Order Single, Quote, etc.) that can be used to indicate the sender's preference should a limit be exceeded. Additionally, multiple firms have identified a requirement to identify throttle limits on a per-party (e.g. firm, trader, account, etc.) basis, which is a very high level business concept. This is not included in the current Gap Analysis because the proposed implementation involves using the Party Entitlements Report message, which itself is still in the Gap Analysis stage. So I'd say the area of throttling would be a liminal space, or a grey area, between the functions of a FIX engine and a business application. >From a purely practical standpoint, it was implemented as part of the >application layer, seeing as FPL can easily extend the application layer >through the Extension Pack / Service Pack processes, while the session layer >is far more difficult to modify. (Note that the "CME Enhancements for Trading >System Identification" gap analysis, which was also posted for public comment, >proposes that ultimately FPL should move in the direction of using Extension >Packs for the session layer.) It is also important to note that the method required in this Gap Analysis for rejecting messages in excess of the throttle limit is the Business Message Reject, while the current sole method to convey throttle limits between parties is the User Response message. Both of these are application level messages, but they are part of the "Infrastructure" group which is, arguably, the lowest level of the FIX application messages. For example, should a message be received that passes session level validation, but the business application that is supposed to process it is unavailable, the proper response is a Business Message Reject. This was done because the BMR is far simpler to generate than an Execution Report, and could, conceivably be generated by a FIX gateway or even a FIX engine. Also, the BMR is used as a generic reject for application level messages when application level rejects do not exist. Case in point: the IOI. If one party sends an IOI for an invalid symbol, the rec ipient's business application may process it and may decide to send back a BMR. For these reasons, I consider the BMR in this same grey area; it definitely is an application level message, but it could conceivably be generated by a FIX engine, gateway, or business application. [You can unsubscribe from this discussion group by sending a message to mailto:unsubscribe+100932...@fixprotocol.org] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to fix-proto...@googlegroups.com. To unsubscribe from this group, send email to fix-protocol+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
