Re: Why do we increase sequence numbers on HBt and Test Request messages?
Lisa Taikitsadaporn / Brook Path Partners, Inc. <>
25 May 2012 8:24AM ET
Heshan,
FIX 2.7 and 3.0 (early 1990s) had a session layer where the administrative messages did not increment. That changed with FIX 4.0 and since then only very minor changes were made until FIXT.1.1.
I can't tell you the history or the reasons for the change, perhaps someone involved in that decision making process can. I have dealt with FIX 2.7 and 3.0 implementations - was session recovery better in 2.7/3.0 than in 4.x? Not necessarily better or worse. From what I remember the 4.x session made it clearer what to expect in the different recovery testing scenarios.
Your comments is a bit worrisome:
> > > We're trying an implementation where Logon, Logout, Test Request and Resend Request messages are sequence-less.
> > >
> > > Further we're adding a Last Received Sequence to the Logon through which we're trying to avoid a Resend Request usage completely.
By implementing customization to the FIX Session as you indicated, wouldn't you be making it difficult for your counterparties that uses off the shelf FIX engines to connect to the exchange?
And what would be the "something new" you would try after FIXT.1.1? Share your thoughts.
> Thanks Xavier.
>
> My attempt is mainly to try and reduce the permutations on the session level and depend on the quality of the present networks for message delivery.
>
> Lets hope version after FIXT 1.1 would try something new.
>
> Thanks,
> Heshan.
>
> > Since FIX 4.4, there is the tag 789 (NextExpectedMsgSeqNum) in the logon message which is an alternative to the resend request.
> >
> > Since FIX 5.0, there is also the possibility of managing an applicative sequence number at business level. But it only works for messages from the exchange to the client. You can set 1181 (ApplSeqNum) in your execution reports. The client may request them again by sending an ApplicationMessageRequest (35=BW).
> >
> > > That is absolutely correct and that's my bad for not indicating that earlier.
> > >
> > > We're trying an implementation where Logon, Logout, Test Request and Resend Request messages are sequence-less.
> > >
> > > Further we're adding a Last Received Sequence to the Logon through which we're trying to avoid a Resend Request usage completely.
> > >
> > > Still wondering why FIX hasn't updated their session protocol to reduce certain inefficiencies.
> > >
> > >
> > > > It wouldn't avoid gap fills due to resend requests for example. And if any sequence number is set in a resend request, you won't be able to detect that you have missed it (if you miss it)...
> > > >
> > > > > With no sequence for the heartbeats and test requests, we can avoid gap fills fully assuming other session messages such as session rejects are replayed on a resend request.
@FIXProtocol
