Imported from previous forum
Hi All,
As a newbie, I’m having a little difficulty getting the relationships between connections, FIX Sessions and FIX Connections straight in my head. Hence, I’d like to shoot some questions, quoting from Vol 2 of the FIX spec as I do so.
(1) “A single FIX session can exist across multiple sequential (not concurrent) physical connections.” Despite this stipulation, I’m aware of implementations that have multiple concurrent TCP connections underlying a single FIX session/connection (in order to provide higher throughput & load balancing). These implementation take responsibility for ensuring correct sequence numbering across all such underlying TCP connections.
Is such an implementation non-compliant, then? Admittedly, a TCP connection isn’t a strictly physical connection; but there’s nothing to stop the TCP connections all following the same physical connection. What is the reason for this non-concurrency requirement?
(2) “FIX Connection is comprised of three parts: logon, message exchange, and logout.” Taken strictly, this definition implies that if a FIX connection is already active when a logon message is sent, then the FIX connection always continues uninterrupted (although the overlying FIX Session may be terminated and a new one begun). Is this correct?
Is there any situation apart from resetting the sequence number (and hence starting a new FIX Session) where you would want to send a logon message during an active FIX Connection? If not, is this actually illegal, or is does it merely ignored or have undefined consequences?
Is seems to me that the Logon message is really doing double-duty, managing both the FIX Connection and the FIX Session.
(3) “FIX Session is comprised of one or more FIX Connections, meaning that a FIX Session spans multiple logins.” This doesn’t explicitly specify that the multiple FIX Connections must be sequential (i.e. non-concurrent). However, I suspect that it intends that they be sequential. Am I correct in this?
(4) “Each message is assigned a unique (by connection) sequence number, which is incremented after each message.” This looks like a typo. The parenthetical really means “(by session)”, doesn’t it? After all, if the sequence number is reset during a FIX Connection, then there’s the potential for a message on the new FIX Session to have the same sequence number as on the prior FIX Session, even though they may have been transitted over the same FIX Connection.
(5) As I read the spec, not only may a FIX Session overlay multiple sequential, FIX Connections; but ipso facto a FIX Connection may underly multiple FIX Sessions. Indeed,
- the same FIX Session may continue operating if its FIX Connection dies and a new FIX Connection takes its place;
- the death of a FIX Session has no impact on the FIX Connection, and a new FIX Session may take its place in using that same FIX Connection. Am I correct in this?
(6) Indeed, at any given instant of time, a FIX Session will have either 0 or 1 FIX Connections underlying it; and a FIX Connection will have either 0 or 1 FIX Sessions overlaying it. Yes?
I apologize that this is such an involved set of questions - I’ve been spending quite a lot of time trying to make sense of this.
I am very appreciative in advance, though, for your feedback.
Angus Monro
Solutions Architect
s4b
It looks like your overall understanding is correct. At any given instant, a FIX Session will either have 0 (not connected) or 1 (connected) FIX connections underlying it. A FIX Connection will have either 0 (connected but haven’t exchanged logons, or have exchanged logouts but haven’t disconnected) or 1 (session established and exchanging messages) FIX Sessions. A FIX Connection can span multiple FIX Session by use of the ResetSeqNumFlag. As far as spanning a FIX Session across multiple FIX Connections goes, it sounds like that isn’t part of the core spec because it’s not a requirement, but doing so as a value-added extension is reasonable.
Alan Beale
TransactTools