|
From: Christoph J. <chr...@ma...> - 2021-06-15 10:24:18
|
Hi Sumanth, this is nothing QuickFIX specific. Rather this is specific to the FIX protocol. QuickFIX is only one of many engines implementing the FIX protocol. You can read more about it here: https://www.fixtrading.org/standards/ and especially here https://www.fixtrading.org/standards/fix-session-layer-online/#fix-session Quote: "A FIX session is a bidirectional stream of ordered messages between two peers within a continuous sequence number series beginning with 1. A single FIX session can exist across multiple sequential (not concurrent) FIX connections, which means that peers may intentionally or unintentionally connect and disconnect multiple times while maintaining a single FIX session. The FIX session can be thought of as a bi-directional durable session sharing characteristics of the guaranteed delivery and durable subscriber enterprise integration architecture patterns." Hope that helps. Cheers, Chris. On 15.06.21 06:39, krishna sumanth Rachamadugu wrote: > Hi Chris, > > Thanks for clarifying. > > I didn't understand the concept of LogOn and LogOut in QuickFIX clearly from documentation. > Although we had started the connection with initiator.start, which will help us to determine > whether a session connection has been established or not, in which context LogOn and LogOut will > help us? > > Why and when an initiator / acceptor will do this operation. > > I'm under the impression that even though an initiator/acceptor does LogOut, the session > associated with the acceptor/initiator will still be alive but the connection established with > that session will be closed. > > Thanks, > Sumanth. > > On Tue, Jun 15, 2021 at 3:53 AM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi Sumanth, > > if you have your message store on some shared medium (e.g. a data base or distributed file > system) you could have several acceptors for the same SessionID, albeit only one of them must > be active at any time. Actually this would work out of the box given that the connection will > only be tried against one of the acceptors at the same time. > I have to admit that there might be cases (due to network timeouts for example) when the > counterparty already tries to connect against another node while the connection still seems > active for the original node. This could then of course lead to a corruption or inconsistency > of the store. So you might be better off if your application implemented a more robust way of > determining the active node. > See also https://www.quickfixj.org/usermanual/2.3.0/usage/acceptor_failover.html > <https://www.quickfixj.org/usermanual/2.3.0/usage/acceptor_failover.html> > > When you're all set, the configuration "RefreshOnLogon=Y" will cause to reload the message > store from the shared medium on the next logon so that the active connector can continue where > the now inactive connector left off. > > Hope that helps. > Cheers, > Chris. > > > On 14.06.21 20:41, krishna sumanth Rachamadugu wrote: >> Hi Chris, >> >> Here, I'm trying to achieve the availability. Lets say, if the machine which is running >> QuickFIX Engine went down, We won't be able to communicate with other parties until we bring >> it up. >> >> Thanks, >> Sumanth. >> >> On Mon, Jun 14, 2021 at 3:42 PM Christoph John <chr...@ma... >> <mailto:chr...@ma...>> wrote: >> >> Hi, >> >> a FIX Session is more or less a point-to-point connection. That means the same SessionID >> cannot be active on two different machines at the same time. The message store (with >> sequence numbers and messages) should be accessed exclusively by one connector. >> >> Let me ask this way: what do you want to achieve? You could of course set up separate >> Sessions that access the same order management system for example. >> >> Cheers, >> Chris. >> >> >> On 14.06.21 07:32, krishna sumanth Rachamadugu wrote: >>> QuickFIX/J Documentation:http://www.quickfixj.org/documentation/ <http://www.quickfixj.org/documentation/> >>> QuickFIX/J Support:http://www.quickfixj.org/support/ <http://www.quickfixj.org/support/> >>> >>> >>> >>> Hi, >>> >>> I'm new to FIX. I understood that it works on message sequence numbers and felt a more >>> tightly coupled way of communication between two parties. >>> >>> 1. Can we have a number of acceptors/initiators with the same session id running on two >>> different machines?. To be more precise, does it support multi-tenant systems? >>> >>> > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |