quickfix-developers

[Quickfix-developers] Configuration Failover Settings

[Jon D. <jd...@wi...>]

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

Re: [Quickfix-developers] Configuration Failover Settings

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

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
>

Re: [Quickfix-developers] Configuration Failover Settings

[Jon D. <jd...@wi...>]

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...

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...
>
>
>

Re: [Quickfix-developers] Configuration Failover Settings

[Jon D. <jd...@wi...>]

Understood. However we are setting ResetOnDisconnect and ResetOnLogout to
1 so I would assume session state is not that big of a deal then. Unless
of course I am reading the config documentation incorrectly.

jd

> 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...


-- 
Jon Dahl
jd...@wi...

Re: [Quickfix-developers] Configuration Failover Settings

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

Oh, then why are sequence numbers a concern?  If you are always 
resetting to 1, then you should never have a situation where sequence 
numbers are too high.  Am I understanding this correctly?

--oren

On Jun 9, 2004, at 2:13 PM, Jon Dahl wrote:

> Understood. However we are setting ResetOnDisconnect and ResetOnLogout 
> to
> 1 so I would assume session state is not that big of a deal then. 
> Unless
> of course I am reading the config documentation incorrectly.
>
> jd
>
>> 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...
>
>
> -- 
> Jon Dahl
> jd...@wi...
>
>
>

Re: [Quickfix-developers] Configuration Failover Settings

[Jon D. <jd...@wi...>]

It's not, I just wanted to see what kind of failover scenarios we could
setup based upon how the QF failover was designed. It's to be determined
if we are going to reset the Sequence Numbers once in production.

Thanks for the help

JD

> Oh, then why are sequence numbers a concern?  If you are always
> resetting to 1, then you should never have a situation where sequence
> numbers are too high.  Am I understanding this correctly?
>
> --oren
>
> On Jun 9, 2004, at 2:13 PM, Jon Dahl wrote:
>
>> Understood. However we are setting ResetOnDisconnect and ResetOnLogout
>>  to
>> 1 so I would assume session state is not that big of a deal then.
>> Unless
>> of course I am reading the config documentation incorrectly.
>>
>> jd
>>
>>> 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...
>>
>>
>> --
>> Jon Dahl
>> jd...@wi...


-- 
Jon Dahl
jd...@wi...