Re: [Quickfix-developers] Configuration Failover Settings

[Oren M. <or...@qu...>]

Well you need to determine what it is exactly you are trying to make 
redundant.  If you are trying to make the FIX session redundant, than 
you should have the same compids while making sure that only one server 
is active at any given time.  These processes should share the same 
source for the state of the session.  This way no matter where they 
connect to, the sequence numbers will be the same.  In this case flat 
file storage probably won't do, in which case you would likely want to 
use a database.  For extra reliability you would also want to make the 
database redundant.

Now if you are simply trying to provide redundant lines, then you 
should use different compids.  In this case you are not making the 
session redundant, but you are making sure that they always have a path 
into the system.  The upside is that these lines are always on and are 
immediately available to accept traffic.  In fact they can accept 
traffic simultaneously (distributing the load), and the client can 
reroute excess traffic to the other lines if one goes down.  The 
downside is that if a session goes down, lost messages won't be 
retrieved until it can be brought back up.

You can also combine these by having redundant paths into the system 
which have redundant sessions.  It all depends on what you are trying 
to accomplish.  But the thing that should remain solid is that if I am 
connecting somewhere with the same compids, I should expect the 
sequence numbers to carry over.  If not, I can only assume something is 
catastrophically wrong and manual intervention is required.

--oren

On Jun 9, 2004, at 12:51 PM, Jon Dahl wrote:

> I understand about having the same SenderCompID's. SenderLocationID 
> can be
> used instead of the SenderCompID to indentify the source of the 
> message.
>
> But in the case of a failover, won't sequence numbers be an issue?
> If the failover server sequence numbers for a client were higher than 
> what
> the client was at, wouldn't there be a possiblity of a resend or 
> locking
> the client out until the sequence numbers caught up?
>
> jd
>
>> John,
>>
>> When you have multiple connection points that share the same comp 
>> id's,
>> cycling through the connections is a necessity because you can't keep
>> the same session alive simultaneously on multiple hosts/ports.  But if
>> you failover sessions with unique compids and unique sets of sequence
>> numbers, why would you not just keep these connections up at all 
>> times?
>>
>> --oren
>>
>> On Jun 9, 2004, at 10:46 AM, Jon Dahl wrote:
>>
>>> QuickFIX Documentation:
>>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>>> QuickFIX FAQ: 
>>> http://www.quickfixengine.org/quickfix/doc/html/FAQ.html
>>>
>>> I have been asked to research QuickFIX's scalability/failover
>>> capabilities
>>> by our Ops center and have come upon an issue. I think I found a
>>> situation
>>> where the clients won't be able to connect to an alternate gateway in
>>> case
>>> of a failure.
>>>
>>> Let's say a client has two hosts(gateways) to connect to. Each one 
>>> has
>>>  a
>>> separate SenderCompID. If the client detects a failure and tries to
>>> connect to the secondary host, it will fail to connect because its
>>> TargetCompID is for the primary host and not the secondary one.
>>>
>>> I was wondering if there was a way to have the [SESSION] settings 
>>> have
>>> alternate TargetCompID's to go a long with SocketConnectPort[n] and
>>> SocketConnectHost[n]?
>>>
>>> JD
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: GNOME Foundation
>>> Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
>>> GNOME Users and Developers European Conference, 28-30th June in 
>>> Norway
>>> http://2004/guadec.org
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>
> -- 
> Jon Dahl
> jd...@wi...
>
>
>