Imported from previous forum
Hi
Is it valid if two sessions have the same
SenderCompId
TargetCompId
BeginString
SocketConnectHost
but different
SocketConnetPort
I read through the specification, but could not find a satisfying answer to this.
NOTE: This question is for all FIX versions 4.1,4.2,4.3 and 4.4
thanks
R Shamanth
The FIX Protocol specification does not preclude this. You would, however, need to arrange and agree upon such a configuration with your counterparty. A lot of it depends upon how your counterparty’s system identifies and differentiates their various FIX sessions.
> Hi
>
> Is it valid if two sessions have the same
>
> SenderCompId
> TargetCompId
> BeginString
> SocketConnectHost
>
> but different
>
> SocketConnetPort
>
> I read through the specification, but could not find a satisfying answer to this.
>
> NOTE: This question is for all FIX versions 4.1,4.2,4.3 and 4.4
>
>
> thanks
> R Shamanth
>
IMHO, the question here is which FIX message fields are uniquely identify a FIX session.
I would say SenderCompID, TargetCompID (and BeginString).
Since FIX does not mandate a specific communication protocol, the details of a TCP connection (e.g. host, port etc.) are not part of the FIX message. Therefore, it would be better in this case if for each connection a different pair of SenderCompID/TargetCompID is choosen.
Regards, Jörg
> The FIX Protocol specification does not preclude this. You would, however, need to arrange and agree upon such a configuration with your counterparty. A lot of it depends upon how your counterparty’s system identifies and differentiates their various FIX sessions.
>
> > Hi
> >
> > Is it valid if two sessions have the same
> >
> > SenderCompId
> > TargetCompId
> > BeginString
> > SocketConnectHost
> >
> > but different
> >
> > SocketConnetPort
> >
> > I read through the specification, but could not find a satisfying answer to this.
> >
> > NOTE: This question is for all FIX versions 4.1,4.2,4.3 and 4.4
> >
> >
> > thanks
> > R Shamanth
> >
>
There are FIX engines out there that will send multiple different sender/target comp ID combinations down the same connection and consider them to be part of the same session - in particular one large European Exchange immediately leaps to mind…
If you are writing an engine to connect to existing counterparties then the below is a reasonable but not necessarily true. If on the other hand you are writing an engine for people to connect to you, then learn to love the sub tags - ie SubSenderCompID - and routing tags - ie OnBehalfOfCompID.
> IMHO, the question here is which FIX message fields are uniquely identify a FIX session.
> I would say SenderCompID, TargetCompID (and BeginString).
>
> Since FIX does not mandate a specific communication protocol, the details of a TCP connection (e.g. host, port etc.) are not part of the FIX message. Therefore, it would be better in this case if for each connection a different pair of SenderCompID/TargetCompID is choosen.
>
> Regards, Jörg
>
> > The FIX Protocol specification does not preclude this. You would, however, need to arrange and agree upon such a configuration with your counterparty. A lot of it depends upon how your counterparty’s system identifies and differentiates their various FIX sessions.
>
> >
> > > Hi
> > >
> > > Is it valid if two sessions have the same
> > >
> > > SenderCompId
> > > TargetCompId
> > > BeginString
> > > SocketConnectHost
> > >
> > > but different
> > >
> > > SocketConnetPort
> > >
> > > I read through the specification, but could not find a satisfying answer to this.
> > >
> > > NOTE: This question is for all FIX versions 4.1,4.2,4.3 and 4.4
> > >
> > >
> > > thanks
> > > R Shamanth
> > >
> >
>
>> There are FIX engines out there that will send multiple different sender/target comp ID combinations down the same connection and consider them to be part of the same session
Well the FIX Protocol specification does address that…
- See Volume 2’s “Overview of Session Layer” which states “The TargetCompID on all messages should be set to some predefined value…The SenderCompID on all messages should be set to some predefined, static value…”
- See Volume 2’s "Message Routing Details – One Firm-to-One Firm (point-to-point):
- See Volume 2’s “FIX Session-level Test Cases and Expected Behaviors” case 1S-b “…message received with duplicate identity (e.g. same IP, port, SenderCompID, TargetCompID, etc. as existing connection)”
The overall recommendation for someone looking to implement the FIX session layer is to attempt to be as flexible as possible. That is, make sure that you can configure your system to represent you with more than one CompID for your various sessions and that you can configure your system to support mapping more than one CompID received from your various sessions back to the same counterparty identity.
You should not, however, ever “change” CompID values on a single session. If one wants to represent different CompIDs, then one should be using DeliverToCompID/OnBehalfOfCompID semantics and follow Volume 2’s “
Message Routing Details – Third Party Message Routing”.
> There are FIX engines out there that will send multiple different sender/target comp ID combinations down the same connection and consider them to be part of the same session - in particular one large European Exchange immediately leaps to mind…
>
> If you are writing an engine to connect to existing counterparties then the below is a reasonable but not necessarily true. If on the other hand you are writing an engine for people to connect to you, then learn to love the sub tags - ie SubSenderCompID - and routing tags - ie OnBehalfOfCompID.
>
>
> > IMHO, the question here is which FIX message fields are uniquely identify a FIX session.
> > I would say SenderCompID, TargetCompID (and BeginString).
> >
> > Since FIX does not mandate a specific communication protocol, the details of a TCP connection (e.g. host, port etc.) are not part of the FIX message. Therefore, it would be better in this case if for each connection a different pair of SenderCompID/TargetCompID is choosen.
> >
> > Regards, Jörg
> >
> > > The FIX Protocol specification does not preclude this. You would, however, need to arrange and agree upon such a configuration with your counterparty. A lot of it depends upon how your counterparty’s system identifies and differentiates their various FIX sessions.
> >
> > >
> > > > Hi
> > > >
> > > > Is it valid if two sessions have the same
> > > >
> > > > SenderCompId
> > > > TargetCompId
> > > > BeginString
> > > > SocketConnectHost
> > > >
> > > > but different
> > > >
> > > > SocketConnetPort
> > > >
> > > > I read through the specification, but could not find a satisfying answer to this.
> > > >
> > > > NOTE: This question is for all FIX versions 4.1,4.2,4.3 and 4.4
> > > >
> > > >
> > > > thanks
> > > > R Shamanth
> > > >
> > >
> >
>
IMHO, the question here is which FIX message fields are uniquely identify a FIX session.
I would say SenderCompID, TargetCompID (and BeginString).
Since FIX does not mandate a specific communication protocol, the details of a TCP connection (e.g. host, port etc.) are not part of the FIX message. Therefore, it would be better in this case if for each connection a different pair of SenderCompID/TargetCompID is choosen.
> The FIX Protocol specification does not preclude this. You would, however, need to arrange and agree upon such a configuration with your counterparty. A lot of it depends upon how your counterparty’s system identifies and differentiates their various FIX sessions.
>
> > Hi
> >
> > Is it valid if two sessions have the same
> >
> > SenderCompId
> > TargetCompId
> > BeginString
> > SocketConnectHost
> >
> > but different
> >
> > SocketConnetPort
> >
> > I read through the specification, but could not find a satisfying answer to this.
> >
> > NOTE: This question is for all FIX versions 4.1,4.2,4.3 and 4.4
> >
> >
> > thanks
> > R Shamanth
> >
>