Session Identification

, ,
1

Imported from previous forum

2

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

3

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

Just a follow-up to this. I did some more reading, and it seems pretty clear that the SenderCompID/TargetCompID pair defines the session.

I am having this problem, because it seems to me the widely used QuickFix/J library breaks this contract since version 1.3.1. In fact, you can define multiple sessions in the config differing only by the SubID, and it will create multiple physical sessions (sockets), and track different sequence numbers for each connection. The session specification clearly states that any physical connections should be sequential, and not concurrent.

Users of QuickFix/J beware…

4

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

Just a follow-up to this. I did some more reading, and it seems pretty clear that the SenderCompID/TargetCompID pair defines the session.

I am having this problem, because it seems to me the widely used QuickFix/J library breaks this contract since version 1.3.1. In fact, you can define multiple sessions in the config differing only by the SubID, and it will create multiple physical sessions (sockets), and track different sequence numbers for each connection. The session specification clearly states that any physical connections should be sequential, and not concurrent.

Users of QuickFix/J beware…

OK, did not read this first. Yes, it is possible to identify session by additionally specifying Sub and Location IDs.

But if you just use Sender and Target CompID to identify a QF/J session, the you can send messages with different Sub and/or Location IDs over
this session without getting separate sequence number. Every session has its own TCP socket.

In summary, it is your choice.

Cheers, Jörg

5

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

Just a follow-up to this. I did some more reading, and it seems pretty clear that the SenderCompID/TargetCompID pair defines the session.

I am having this problem, because it seems to me the widely used QuickFix/J library breaks this contract since version 1.3.1. In fact, you can define multiple sessions in the config differing only by the SubID, and it will create multiple physical sessions (sockets), and track different sequence numbers for each connection. The session specification clearly states that any physical connections should be sequential, and not concurrent.

Users of QuickFix/J beware…

OK, did not read this first. Yes, it is possible to identify session by additionally specifying Sub and Location IDs.

But if you just use Sender and Target CompID to identify a QF/J session, the you can send messages with different Sub and/or Location IDs over
this session without getting separate sequence number. Every session has its own TCP socket.

In summary, it is your choice.

Cheers, Jörg

Thanks, and that is what we do (use one session but change the sub/location) but there s only a single set of sequence numbers. I think the spec SHOULD state explicitly that the session in terms of sequence numbers is defined solely by the sender/target comp Id, and this is what the CME expects, and will choke with any other behavior, but I can’t find a definitive statement in the spec that says how it should be handling one way or the other, or that it is by agreement.

6

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

Just a follow-up to this. I did some more reading, and it seems pretty clear that the SenderCompID/TargetCompID pair defines the session.

I am having this problem, because it seems to me the widely used QuickFix/J library breaks this contract since version 1.3.1. In fact, you can define multiple sessions in the config differing only by the SubID, and it will create multiple physical sessions (sockets), and track different sequence numbers for each connection. The session specification clearly states that any physical connections should be sequential, and not concurrent.

Users of QuickFix/J beware…

OK, did not read this first. Yes, it is possible to identify session by additionally specifying Sub and Location IDs.

But if you just use Sender and Target CompID to identify a QF/J session, the you can send messages with different Sub and/or Location IDs over
this session without getting separate sequence number. Every session has its own TCP socket.

In summary, it is your choice.

Cheers, Jörg

Thanks, and that is what we do (use one session but change the sub/location) but there s only a single set of sequence numbers. I think the spec SHOULD state explicitly that the session in terms of sequence numbers is defined solely by the sender/target comp Id, and this is what the CME expects, and will choke with any other behavior, but I can’t find a definitive statement in the spec that says how it should be handling one way or the other, or that it is by agreement.

Hi all,

Respectfully I must disagree re: explicitly stating one way or the other in the spec. There are many existing implementations with usage/rules for sub id and loc id bilaterally agreed upon between the counter parties.

Some use the sub id and loc id are used for uniquely identifying sources/destinations within the session (essentially what you indicate is the CME implementation - comp id is constant but sub id and loc id may change) and others require the sub id and loc id remain consistent for a given session.

The former usage is becoming less common in my experience as the parties block addressed some business needs which were previously solved via usage of sub id and loc id while other routing/protocol related needs have been addressed by internal routing by the counter parties (i.e. the sender no longer needs to expose that information to the receiver).

An example for of the latter implementation is where counter parties have multiple concurrent sessions between their various systems. Application instances on core servers are using common database resources for message storage. Sub id and loc id are used to distinguish between sessions and are established in the logon. Subsequent messages in the session with different sub id and loc id result in a logout (with error text) by the receiving party.

In a nutshell, I don’t think we should make either usage ‘against the spec’ because the flexibility has been demonstrated to have value.

Cheers,

Dennis

7

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

Just a follow-up to this. I did some more reading, and it seems pretty clear that the SenderCompID/TargetCompID pair defines the session.

I am having this problem, because it seems to me the widely used QuickFix/J library breaks this contract since version 1.3.1. In fact, you can define multiple sessions in the config differing only by the SubID, and it will create multiple physical sessions (sockets), and track different sequence numbers for each connection. The session specification clearly states that any physical connections should be sequential, and not concurrent.

Users of QuickFix/J beware…

OK, did not read this first. Yes, it is possible to identify session by additionally specifying Sub and Location IDs.

But if you just use Sender and Target CompID to identify a QF/J session, the you can send messages with different Sub and/or Location IDs over
this session without getting separate sequence number. Every session has its own TCP socket.

In summary, it is your choice.

Cheers, Jörg

Thanks, and that is what we do (use one session but change the sub/location) but there s only a single set of sequence numbers. I think the spec SHOULD state explicitly that the session in terms of sequence numbers is defined solely by the sender/target comp Id, and this is what the CME expects, and will choke with any other behavior, but I can’t find a definitive statement in the spec that says how it should be handling one way or the other, or that it is by agreement.

Hi all,

Respectfully I must disagree re: explicitly stating one way or the other in the spec. There are many existing implementations with usage/rules for sub id and loc id bilaterally agreed upon between the counter parties.

Some use the sub id and loc id are used for uniquely identifying sources/destinations within the session (essentially what you indicate is the CME implementation - comp id is constant but sub id and loc id may change) and others require the sub id and loc id remain consistent for a given session.

The former usage is becoming less common in my experience as the parties block addressed some business needs which were previously solved via usage of sub id and loc id while other routing/protocol related needs have been addressed by internal routing by the counter parties (i.e. the sender no longer needs to expose that information to the receiver).

An example for of the latter implementation is where counter parties have multiple concurrent sessions between their various systems. Application instances on core servers are using common database resources for message storage. Sub id and loc id are used to distinguish between sessions and are established in the logon. Subsequent messages in the session with different sub id and loc id result in a logout (with error text) by the receiving party.

In a nutshell, I don’t think we should make either usage ‘against the spec’ because the flexibility has been demonstrated to have value.

Cheers,

Dennis

I can agree with that, but then the session protocol document needs to identify the options, and under what conditions the sequence numbers are managed, otherwise it just leads to additional effort on the part of implementors. As it stands now, my reading of says that only the comp/target id form the session, but I will say it is not clear.

As an aside the maintainers of the quickfix C library seems to agree with me, but the quickfixj library has recently taken the “all fields” approach, but the upcoming release will offer both.

8

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

Just a follow-up to this. I did some more reading, and it seems pretty clear that the SenderCompID/TargetCompID pair defines the session.

I am having this problem, because it seems to me the widely used QuickFix/J library breaks this contract since version 1.3.1. In fact, you can define multiple sessions in the config differing only by the SubID, and it will create multiple physical sessions (sockets), and track different sequence numbers for each connection. The session specification clearly states that any physical connections should be sequential, and not concurrent.

Users of QuickFix/J beware…

OK, did not read this first. Yes, it is possible to identify session by additionally specifying Sub and Location IDs.

But if you just use Sender and Target CompID to identify a QF/J session, the you can send messages with different Sub and/or Location IDs over
this session without getting separate sequence number. Every session has its own TCP socket.

In summary, it is your choice.

Cheers, Jörg

Thanks, and that is what we do (use one session but change the sub/location) but there s only a single set of sequence numbers. I think the spec SHOULD state explicitly that the session in terms of sequence numbers is defined solely by the sender/target comp Id, and this is what the CME expects, and will choke with any other behavior, but I can’t find a definitive statement in the spec that says how it should be handling one way or the other, or that it is by agreement.

Hi all,

Respectfully I must disagree re: explicitly stating one way or the other in the spec. There are many existing implementations with usage/rules for sub id and loc id bilaterally agreed upon between the counter parties.

Some use the sub id and loc id are used for uniquely identifying sources/destinations within the session (essentially what you indicate is the CME implementation - comp id is constant but sub id and loc id may change) and others require the sub id and loc id remain consistent for a given session.

The former usage is becoming less common in my experience as the parties block addressed some business needs which were previously solved via usage of sub id and loc id while other routing/protocol related needs have been addressed by internal routing by the counter parties (i.e. the sender no longer needs to expose that information to the receiver).

An example for of the latter implementation is where counter parties have multiple concurrent sessions between their various systems. Application instances on core servers are using common database resources for message storage. Sub id and loc id are used to distinguish between sessions and are established in the logon. Subsequent messages in the session with different sub id and loc id result in a logout (with error text) by the receiving party.

In a nutshell, I don’t think we should make either usage ‘against the spec’ because the flexibility has been demonstrated to have value.

Cheers,

Dennis

I can agree with that, but then the session protocol document needs to identify the options, and under what conditions the sequence numbers are managed, otherwise it just leads to additional effort on the part of implementors. As it stands now, my reading of says that only the comp/target id form the session, but I will say it is not clear.

As an aside the maintainers of the quickfix C library seems to agree with me, but the quickfixj library has recently taken the “all fields” approach, but the upcoming release will offer both.

Re: Quickfix C - You can add a session qualifier if you want. From the config … “SessionQualifier - Additional qualifier to disambiguate otherwise identical sessions”.

9

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Yes, that is correct.

Cheers, Jörg

10

FIX sequence numbers are maintained for each FIX Session.

A FIX user can choose to identify a FIX Session as just a SenderCompID/TargetCompID pair (that may include SubId/LocID as well on some messages). It is also possible to identify a FIX Session by a combination of Comp, Sub, and/or Location IDs. It is a matter of counter-party agreement as to what fields will be used to identify the FIX Session.

Greg.

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

11

FIX sequence numbers are maintained for each FIX Session.

A FIX user can choose to identify a FIX Session as just a SenderCompID/TargetCompID pair (that may include SubId/LocID as well on some messages). It is also possible to identify a FIX Session by a combination of Comp, Sub, and/or Location IDs. It is a matter of counter-party agreement as to what fields will be used to identify the FIX Session.

Greg.

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

Ok, but… Are you certain this is what the specification implies, as I read the fix session protocol spec document again, ad it seems to state that is not correct (but not definatively). Regardless, I think the quick fix/j library since version 1.3.1 is incorrect as it will always define the session by all fields, when for counter-party’s like the CME is not correct and will cause bad behavior.

Can you point me to the exact line/chapter of the spec that says that is what defines the session? I think some counter parties might be doing this, (allowing) but it is not according to the spec.

12

FIX sequence numbers are maintained for each FIX Session.

A FIX user can choose to identify a FIX Session as just a SenderCompID/TargetCompID pair (that may include SubId/LocID as well on some messages). It is also possible to identify a FIX Session by a combination of Comp, Sub, and/or Location IDs. It is a matter of counter-party agreement as to what fields will be used to identify the FIX Session.

Greg.

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

this is in direct contradiction to what Jörg Thönnes stated, which leaves me to believe that it is not clearly definded. If it is, can someone please point me to the relevant documentation that states what governs a “session identifier” which in consequence governs the maintenance of sequence numbers?

Sorry, I realize I’m new here, but I came in late to the project and am trying to et up to speed, and this issue I nagging me.

13

Hi,

The FIX session in it’s strictest sense is initiated between two counterparties identified by two CompID’s and the sequence number relates to that session between those two counterparties.

Your probably right that this distinction isn’t as explicitly stated as perhaps it could be in the specs however the underlying premise borne out through the specs is that the sessions’ sequence numbers are managed between the two CompID’s who initiated the session.

Within a session various other sub-entities may be identified, normally for the purpose of routing or directing messages to an internal desk etc or an external but connected FIX counterparty/destination.

HTH’s
Aaron.

FIX sequence numbers are maintained for each FIX Session.

A FIX user can choose to identify a FIX Session as just a SenderCompID/TargetCompID pair (that may include SubId/LocID as well on some messages). It is also possible to identify a FIX Session by a combination of Comp, Sub, and/or Location IDs. It is a matter of counter-party agreement as to what fields will be used to identify the FIX Session.

Greg.

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

this is in direct contradiction to what Jörg Thönnes stated, which leaves me to believe that it is not clearly definded. If it is, can someone please point me to the relevant documentation that states what governs a “session identifier” which in consequence governs the maintenance of sequence numbers?

Sorry, I realize I’m new here, but I came in late to the project and am trying to et up to speed, and this issue I nagging me.

14

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

I am gathering from the responses here and the discussion on the quickfixj board, that the final result is “we know the spec is ambiguous, and different counter-parties handle it differently”.

Seems very strange that a spec that has been around so long and gone through as many revisions that is has is in such a state, but I guess that is what keeps the developers employed. Cheers. Thanks for the comments.

15

Hi Robert

I think that Greg Orsini said it best.

The short answer to your question is no.

Whatever the intentions of the original author(s) of this part of the FIX specification, the fact is that many counterparties in the real world use all of compID, subID and (more rarely) locationID to specify an individual FIX session. I think that is what was intended in the spec, but it doesn’t really matter what I think - that is the reality.

A big broker might identify two separate connection points, for example, as CompID=BigBroker SubID=Equities LocationID=Desk1 and CompID=BigBroker SubID=Derivatives

I know for a fact that CameronFIX supports identification of an individual session by any combination of of comp, sub and location (because it was required by CameronFIX users), and I am sure that all the other widely used implementations of FIX would do the same.

John

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

I am gathering from the responses here and the discussion on the quickfixj board, that the final result is “we know the spec is ambiguous, and different counter-parties handle it differently”.

Seems very strange that a spec that has been around so long and gone through as many revisions that is has is in such a state, but I guess that is what keeps the developers employed. Cheers. Thanks for the comments.

16

The problem is that it is not that simple. For instance the CME requires the sub and location fields be filled in, but requires that only a single session be used (per comp/target pair). I think the ambiguity of the spec leads to this sort of inconsistent craziness.

I am new to working in this industry and I guess I am just surprised.

It’s no big deal in the end, but still seems goofy.

Hi Robert

I think that Greg Orsini said it best.

The short answer to your question is no.

Whatever the intentions of the original author(s) of this part of the FIX specification, the fact is that many counterparties in the real world use all of compID, subID and (more rarely) locationID to specify an individual FIX session. I think that is what was intended in the spec, but it doesn’t really matter what I think - that is the reality.

A big broker might identify two separate connection points, for example, as CompID=BigBroker SubID=Equities LocationID=Desk1 and CompID=BigBroker SubID=Derivatives

I know for a fact that CameronFIX supports identification of an individual session by any combination of of comp, sub and location (because it was required by CameronFIX users), and I am sure that all the other widely used implementations of FIX would do the same.

John

Hello All,

Am I correct in understanding that a session is solely identified by the SenderCompID and TargetCompId in terms of sequence number management.

That is, using different SenderSubID or SenderLocationID does not create a new sequence number set.

Thanks,
Robert

I am gathering from the responses here and the discussion on the quickfixj board, that the final result is “we know the spec is ambiguous, and different counter-parties handle it differently”.

Seems very strange that a spec that has been around so long and gone through as many revisions that is has is in such a state, but I guess that is what keeps the developers employed. Cheers. Thanks for the comments.

17

Robert,

I would like to comment on your statement below from an FPL perspective. What you call ambiguity is called flexibility by others. A major part of the attractiveness of FIX is its flexibility. At the same time, I am very aware of many cases where I also see ambiguities rather than flexibilities. The downside of a standard is that one has to live with is that you cannot easily change the existing applications out there (the “reality” as John Cameron called it). An interface is much more than just a collection of fields. It reflects the core system design. If FPL were (able) to force everybody to use only CompID/TargetID to uniquely identify a session context and sequence numbering, then people are still not going to change their application architecture. They will use other fields or user-defined fields or, worst of all, use a proprietary interface instead of FIX. Your argument is valid for new applications where you still have a choice. FIX should always have a recommended approach but needs to be flexible enough to support alternate approaches to a certain extent. Drawing the line for that is often intentionally left to bilateral agreement, sometimes it is not. For example, some fields allow user-defined values, others do not because they are key to the FIX semantics.
In the end, the ambiguities a small price to pay for the huge benefits that the usage of a standard like FIX offers to a community.
Regards,
Hanno.

I am gathering from the responses here and the discussion on the quickfixj board, that the final result is “we know the spec is ambiguous, and different counter-parties handle it differently”.

Seems very strange that a spec that has been around so long and gone through as many revisions that is has is in such a state, but I guess that is what keeps the developers employed. Cheers. Thanks for the comments.

18

In this case, it is clearly more “ambiguity” and “convention” rather than “flexibility”. Robert is completely correct that something as fundamental as defining a session should be clearly laid out in a specification.

Kenny

19

In this case, it is clearly more “ambiguity” and “convention” rather than “flexibility”. Robert is completely correct that something as fundamental as defining a session should be clearly laid out in a specification.

Kenny

That is what I am getting at. The spec could still be very flexible and cover existing uses, but at least explicitly define what is “spec” and what is implementation specific.

Page 8 of the session protocol document describes some important restrictions on sessions, but unless you know how a session is defined, it is pretty meaningless.

My reading of all of the spec documents implies that a session is defined solely by the sender/target id, and I think original implementations bore that out. As the additional header fields were added, I do not see anything that states this was changed, but rather these allow for more specific routing/tracking of messages by the receiver.

But as the hot phrase states, “it is what it is”.

20

I agree that the spec could be clearer on this. Back in 1997 when I wrote CameronFIX, I interpreted the spec differently from yourself to mean that the all three of compID, subID and locationID were used to identify a Session - and CameronFIX has always had support for that (routing is supported by the onBehalfOf and deliverTo fields). So, two readers, two different interpretations. Clearly there is a problem.

I think that FIXwiki (http://fixwiki.org/) can help out here. It is a useful tool provided by FPL for capturing issues like this. I have taken the liberty of extracting some of the key comments from this discussion and adding them to FIXwiki - see http://fixwiki.org/fixwiki/SenderCompID. Feel free to modify/add to my notes.

FPL may consider moving some of these clarifying comments into the spec.

FIXwiki is also a useful place for recording common “real life” interpretations of the spec. For example, it might also be useful to record the nature and logic of CME’s use of the subID and locationID fields.

That is what I am getting at. The spec could still be very flexible and cover existing uses, but at least explicitly define what is “spec” and what is implementation specific.

Page 8 of the session protocol document describes some important restrictions on sessions, but unless you know how a session is defined, it is pretty meaningless.

My reading of all of the spec documents implies that a session is defined solely by the sender/target id, and I think original implementations bore that out. As the additional header fields were added, I do not see anything that states this was changed, but rather these allow for more specific routing/tracking of messages by the receiver.

But as the hot phrase states, “it is what it is”.