Imported from previous forum
[ original email was from kay pa - kayur2510@yahoo.com ]
Hi All,
I am using Javelin’s Appia 1.1 with Fix 4.2 to send FIX messages. I have a client that sends Admin Messages randomly with a MsgSeqNum = 0.
my FIX engine disconnects the session bcs it receives a MsgSeqNum lower than what is expected.
is there a way that i can ignore this sequence number before my fix engine disconnects the client.
all answers are appreciated
tx
kayur
[ original email was from Matt Koehler - matt.koehler@transacttools.net ]
Hi Kayur -
Interesting problem. The FIX specification is pretty clear about this issue - your counterparty should not be doing this, strictly speaking. However, I have seen more than one implementation that posts non unique and/or zero-values in fields that are required, strictly speaking, to be unique and/or non-zero.
Consider it a non-standard, but somewhat common, "dialect" of FIX.
Your engine should be intelligent enough to capture messages like this, and allow you to dynamically specify behavior on how to handle situations like this. For example, you should be able to tell your engine that for a given counterparty, zero sequence numbers need to be checked to see if they’re ‘administrative’-type messages (for example, maybe check to see if they don’t have LastPx/LastQty, or however you define “administrative”) and allow the messages. Being able to define these rules on the fly will enable you to avoid lengthy product development-testing-release cycles with whatever vendor product you may be using.
Happy holidays,
-matt
> Hi All,
>
> I am using Javelin’s Appia 1.1 with Fix 4.2 to send FIX messages. I have a client that sends Admin Messages randomly with a MsgSeqNum = 0.
>
> my FIX engine disconnects the session bcs it receives a MsgSeqNum lower than what is expected.
>
> is there a way that i can ignore this sequence number before my fix engine disconnects the client.
>
> all answers are appreciated
>
> tx
> kayur
>
[ original email was from John Cameron - jc@cameronsystems.com ]
Hello Kayur,
I agree entirely with Matt about the necessity of being able to accommodate non standard "dialects" of FIX. As you have already dicovered, they are a fact of life. Hopefully your engine gives you the flexibility you require. However, I would add one note of caution:
Think very carefully before messing about with sequence numbers. The whole low level FIX protocol is designed to ensure that you can never lose a message without knowing about it. It does this using sequence numbers. You would have to look carefully at exactly which admin messages your client is sending with 0 sequence numbers and why they are being sent. Then, before you take the step of overridng FIX’s standard sequence number processing logic, you need to think through all possible scenarios to make sure there is no risk of losing a message.
John
> Hi Kayur -
>
> Interesting problem. The FIX specification is pretty clear about this issue - your counterparty should not be doing this, strictly speaking. However, I have seen more than one implementation that posts non unique and/or zero-values in fields that are required, strictly speaking, to be unique and/or non-zero.
>
> Consider it a non-standard, but somewhat common, “dialect” of FIX.
>
> Your engine should be intelligent enough to capture messages like this, and allow you to dynamically specify behavior on how to handle situations like this. For example, you should be able to tell your engine that for a given counterparty, zero sequence numbers need to be checked to see if they’re ‘administrative’-type messages (for example, maybe check to see if they don’t have LastPx/LastQty, or however you define “administrative”) and allow the messages. Being able to define these rules on the fly will enable you to avoid lengthy product development-testing-release cycles with whatever vendor product you may be using.
>
> Happy holidays,
> -matt
>
>
> > Hi All,
> >
> > I am using Javelin’s Appia 1.1 with Fix 4.2 to send FIX messages. I have a client that sends Admin Messages randomly with a MsgSeqNum = 0.
> >
> > my FIX engine disconnects the session bcs it receives a MsgSeqNum lower than what is expected.
> >
> > is there a way that i can ignore this sequence number before my fix engine disconnects the client.
> >
> > all answers are appreciated
> >
> > tx
> > kayur
> >
>
I also agree with Matt and John,
The old addage, "be generous in what you receieve and strict in what you send" should always apply.
HOWEVER,
I think it is also very important to stress to the suppliers that they fix up these problems to become compliant with the standards.
If this is not done the whole concept of a standard and interoperability goes out the window, or at least becomes very difficult. And what starts out as being one minor deviation becomes two, three, etc until compliance is almost impossible.
Cheers,
Ben
> Hello Kayur,
>
> I agree entirely with Matt about the necessity of being able to accommodate non standard “dialects” of FIX. As you have already dicovered, they are a fact of life. Hopefully your engine gives you the flexibility you require. However, I would add one note of caution:
>
> Think very carefully before messing about with sequence numbers. The whole low level FIX protocol is designed to ensure that you can never lose a message without knowing about it. It does this using sequence numbers. You would have to look carefully at exactly which admin messages your client is sending with 0 sequence numbers and why they are being sent. Then, before you take the step of overridng FIX’s standard sequence number processing logic, you need to think through all possible scenarios to make sure there is no risk of losing a message.
>
> John
>
> > Hi Kayur -
> >
> > Interesting problem. The FIX specification is pretty clear about this issue - your counterparty should not be doing this, strictly speaking. However, I have seen more than one implementation that posts non unique and/or zero-values in fields that are required, strictly speaking, to be unique and/or non-zero.
> >
> > Consider it a non-standard, but somewhat common, “dialect” of FIX.
> >
> > Your engine should be intelligent enough to capture messages like this, and allow you to dynamically specify behavior on how to handle situations like this. For example, you should be able to tell your engine that for a given counterparty, zero sequence numbers need to be checked to see if they’re ‘administrative’-type messages (for example, maybe check to see if they don’t have LastPx/LastQty, or however you define “administrative”) and allow the messages. Being able to define these rules on the fly will enable you to avoid lengthy product development-testing-release cycles with whatever vendor product you may be using.
> >
> > Happy holidays,
> > -matt
> >
> >
> > > Hi All,
> > >
> > > I am using Javelin’s Appia 1.1 with Fix 4.2 to send FIX messages. I have a client that sends Admin Messages randomly with a MsgSeqNum = 0.
> > >
> > > my FIX engine disconnects the session bcs it receives a MsgSeqNum lower than what is expected.
> > >
> > > is there a way that i can ignore this sequence number before my fix engine disconnects the client.
> > >
> > > all answers are appreciated
> > >
> > > tx
> > > kayur
> > >
> >
>
[ original email was from Matt Koehler - matt.koehler@transacttools.net ]
A great idea! But I think the reality of the situation is that there are more home-grown FIX implementations out there than any of us could possibly imagine. Heterogeneous FIX implementations are here to stay.
> HOWEVER,
>
> I think it is also very important to stress to the suppliers that they fix up these problems to become compliant with the standards.
> If this is not done the whole concept of a standard and interoperability goes out the window, or at least becomes very difficult. And what starts out as being one minor deviation becomes two, three, etc until compliance is almost impossible.
[ original email was from Ryan Pierce - rpierce@taltrade.com ]
> A great idea! But I think the reality of the situation is that there are more home-grown FIX implementations out there than any of us could possibly imagine. Heterogeneous FIX implementations are here to stay.
The view that heterogenous FIX implementations are here to stay is most certainly true, and flexibility can go a long way in attracting clients or having a wider range of vendors. But flexibility must be weighed against stability, development and support costs.
I rank protocol violations in four categories of increasing severity:
-
Violation of an internal convention not covered in the FIX spec. (I.e. inability to set TargetSubID to the value we mandate.)
-
Violation of our interpretation of an ambiguous part of the FIX spec. (I.e. FIX 4.0 handling of several scenarios regarding Cancel and Cancel/Replace.)
-
Violation of something definite in the FIX spec, but which does not significantly impair the stability of the protocol. (I.e. sending the leaves quantity rather than the total order quantity on a cancel request.)
-
Violation of something in the FIX spec that has a destabilizing effect. (I.e. substnntial change to the session layer).
Often, firms have a choice of who they do business with. A client can decline to do business with a vendor that does not accurately follow the FIX protocol, and a vendor can often decline a client’s business as well for the same reason.
If I were presented with the same situation of admin messages with sequence numbers of 0 for an order routing FIX session, I would probably make a case to upper management to decline the client’s business until the client corrects their system, on the following grounds:
-
Our FIX session code is a core, critical part of our system, and it is well tested and stable. Supporting this non-compliant FIX system would mean a significant modification to that code, which would involve significant coding and testing time (as well as the opportunity cost of not being able to devote that coding and testing time elsewhere), and could potentially harm the stability of the code base.
-
The proposed non-compliant change has a destabilizing effect on the FIX protocol. The standard FIX session layer is delicate, but if implemented exactly as specified, quite reliable. This change effectively kills the ordered message processing requirements that FIX imposes and opens up quite a lot of potential failure modes that didn’t exist before. Failures can cost quite a lot of money, and non-standard kludges generally have associated support and troubleshooting costs as well.