{{Quickfixn}} (no subject)

Christoph John christoph.john at macd.com
Fri Aug 5 10:43:49 PDT 2022


Hi

Just curious: what do you want to store the time for? I could imagine that in the "flooding" scenario the requests come in in short succession so after one range has been satisfied the other side should send a new range anyway.
Moreover, which time do you want to store and compare? A time local to your environment ("the time it finished to be sent"). Now on the next resend request which time do you compare it to? The sending time? That might be off by even seconds compared to the time you are using. Even earlier than the time you are using locally (except both sides are using NTP or the like which my experience isn't always the case).

Just my 2 cents.
Cheers
Chris

Aug 5, 2022 19:19:45 Antonio Meireles - GMail <antonio.meireles at gmail.com>:

> Hi,
> 
> Quickfix has the SEND_REDUNDANT_RESENDREQUESTS=N configuration that can be used to avoid sending ResendRequests of a gap that is already asked and will be redundant. 
> 
> This can avoid ResendRequest loops, but sometimes the counterpart do not use the same approach and may struggle the session with several Duplicated and Redundant ResendRequests. 
> 
> If we process duplicated ResendRequests we can send all the gap several times and this will only contribute to flood the connection. 
> 
> So, I am proposing a configuration DISCARD_DUPLICATED_RESEND_REQUESTS=Y (default=N) that will make possible to configure a session to discard these duplicated ResendRequests.
> 
> To do this, the session should store the last ResendRequest boundaries and the time it finished to be sent, and check new ResendRequests against these stored values. If the new asked gap is inside the stored boundaries and earlier than the stored time, the session should discard the ResendRequest message.
> 
> Do anyone have comments about this scenario or approach?
> 
> Do you think it is usefull to follow implementing It and proposing a PR?
> 
> BR,
> 
> Antonio Meireles (Guto)
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20220805/d2cc7311/attachment.htm>


More information about the Quickfixn mailing list