Re: [Quickfix-developers] What should be done if ResendRequest generated by doTargetTooHigh have never been received or acted upon

[len <le...@fa...>]

Caleb,

Thanks for insightful reply. My response is below

On 8/21/06, Caleb Epstein wrote:

>> The effect I have described occurs in version 1.11.x. I have already
>> downloaded latest source 1.12.2 and very quick check reveal addition of
>> Session level "m_sendRedundantResendRequests" variable which can be set
by
>> Application level code which control reissue of already sent
ResendRequest,
>> which is probably enough for my objectives - what can I say, stupid me, I
>> have to do it first before arrogantly asking the question.

>It doesn't seem like issuing more ResendRequests would help with this
>counterparty.

I believe that ResentRequest message was just simply swallowed somewhere
after network glitch and accordingly second re-send would make the
difference in our particular situation. Generally speaking when you
explicitly elaborated on timeouts when no messages in the PROPER sequence
are arriving - I like it a lot and I am going to test it really soon.

>Perhaps you could expoound on what changes you've made to the QuickFIX
>sources.  If they are beneficial to others, maybe you can have them
>incorporated into the upstream codebase to reduce the need for this
>sort of integration.

>QuickFIX already builds as a DLL doesn't it?
No, QuickFIX is not a DLL in the Windows project. It is a statically linked
library and there nothing wrong with it except that you will have a memory
overhead when you run more than one executable linked to it. It was not in
version 1.11 and I have checked 1.12.2 it is still not the case.

Besides some trivial configuration changes (debug symbols, locations) and
converting it to DLL (small config changes and I had to add MACRO expanding
to __declspec(dllexport) in few key classes to make them exportable) I have
made following changes to the project:

1. Add resource file (xxxx.RC) which includes QuickFIX version - that
allowed under Windows right-click on the quicfix.dll and see its version via
standard property dialog
2. Made bunch of changes which allowed me dynamically config
session/sessions. May be because of my in-expirience with QuickFIX engine
but I've got impression that its life-cycle is too straight-forward for our
needs: Global Application (and its infrastructure such as log, message
store, ThreadedConnection) is loaded and configured only once during
executable host startup. My modification allowed me to do it at any time
dynamically. In addition all our configuration details are stored in DB and
not init file - client code reads config from DB and (re)configure QuickFIX
application. But again there may be a way to achieve it in other way - I
just was not able to find it.
3. Moved Message's validate() method from private to public section -
because it was a beneficial to validate message prior to posting it.
4. Added two more types of logon. One just to check remote sequence number
and disconnect and second to realign local sequence number and continue
connection - this for pure testing purposes.
5. Added a client control methods to simulate loss of incoming or/and
outgoing messages - as well for testing only.

If you want me a share code I also can do it very easily.

Thanks.

Len.

-----Original Message-----
From: Caleb Epstein [mailto:cal...@gm...] 
Sent: Monday, August 21, 2006 4:45 PM
To: len
Cc: Joerg Thoennes; qui...@li...
Subject: Re: [Quickfix-developers] What should be done if ResendRequest
generated by doTargetTooHigh have never been received or acted upon

On 8/21/06, len <le...@fa...> wrote:

> The effect I have described occurs in version 1.11.x. I have already
> downloaded latest source 1.12.2 and very quick check reveal addition of
> Session level "m_sendRedundantResendRequests" variable which can be set by
> Application level code which control reissue of already sent
ResendRequest,
> which is probably enough for my objectives - what can I say, stupid me, I
> have to do it first before arrogantly asking the question.

It doesn't seem like issuing more ResendRequests would help with this
counterparty.

> Interestingly enough Caleb refers for time-out behavior which I did not
> discover yet by surfing through the code. I am planning to test it though

This is the standard FIX heartbeating mechanism.  If no messages are
received (in proper sequence) in <HeartbeatInterval> seconds, a
heartbeat message will be sent.  If still no messages (in proper
sequence) are received after 1.2 * <HeartbeatInterval>, a Test request
is sent, and the connection will eventually timeout if no messages are
received for 2.4 * HeartbeatInterval.  Look at the code in
SessionState.h and Session::next()

> but it will take me a week or two because I am on the other project and I
> will need to back-port our QuickFix sources changes (compiling it into DLL
> and dozen of other little things)

Perhaps you could expoound on what changes you've made to the QuickFIX
sources.  If they are beneficial to others, maybe you can have them
incorporated into the upstream codebase to reduce the need for this
sort of integration.

QuickFIX already builds as a DLL doesn't it?

-- 
Caleb Epstein