Maintaining multiple user sessions over a single FIX Session - Best Approach?

, ,
1

Imported from previous forum

2

We need to support multiple user sessions over a single FIX session using FIX.4.4.

Long term within FIX (FIX.5.0SP3 – likely) we will have a BusinessApplicationHeader with From/ToParty blocks where UserSessionID can be maintained.

For pre-FIX.5.0SP3 versions the initial thought was put UserSessionID in the Party block at the root level of the message (whatever that block happens to be named, not all messages have a Parties block yet).

There was push back from internal developers because the field is potentially on different messages throughout the API.

Does anyone see an issue in pre-FIX.5.0 versions carrying the User Session ID (as opposed to the FIX SessionID) in the SenderSubID / TargetSubID field in the StandardHeader?

3

Jim,

I tried searching for UserSessionID FIXTag and could not find anything. Is this a new FIXTag you are proposing for a future FIX version FIXT.1.2 / service pack FIX.5.0SP3 ?

Lets say there is a buy side HogHedgeFund which uses its industrywide CompID = HOG having multiple trading desks like US Equities trading desk using SubID=USEQ, Fixed income trading desk using SubID=FIXED etc. Now lets say there are three traders Dickenson, Thompson and Harrison in the US Equities trading desk. Now the need is to also send their HogHedgeFund Single signon IDs TOM / DICK / HARRY to the counterparty to identify which trader placed each trade. If the trader id is used as SubID, then the trading desk sub id USEQ would not be sent and I do not know if the business would accept it. There could be rippling effects of this change across organization affecting multiple systems in the workflow chain.

Whats is the objection to adding this new Tag UserSessionID to older versions ?

Regards,
K. Mahesh

We need to support multiple user sessions over a single FIX session using FIX.4.4.

Long term within FIX (FIX.5.0SP3 – likely) we will have a BusinessApplicationHeader with From/ToParty blocks where UserSessionID can be maintained.

For pre-FIX.5.0SP3 versions the initial thought was put UserSessionID in the Party block at the root level of the message (whatever that block happens to be named, not all messages have a Parties block yet).

There was push back from internal developers because the field is potentially on different messages throughout the API.

Does anyone see an issue in pre-FIX.5.0 versions carrying the User Session ID (as opposed to the FIX SessionID) in the SenderSubID / TargetSubID field in the StandardHeader?

4

Mahesh,

new tags are not added to older FIX versions in general with a few well-defined exceptions for regulatory purposes. Otherwise there would be no real need to have a version at all as there is always somebody who could use a new tag in an older version. I compare it to a software vendor rolling out new features under an old version of his software. You want X to be stable once you have tested against X. Changing X should mean to introduce Y where X and Y are version numbers with X<Y.

UserSessionID was probably not meant as a new field. There is a PartyRole 55=Session ID that could be used for this purpose.

Regards,
Hanno.

Jim,

I tried searching for UserSessionID FIXTag and could not find anything. Is this a new FIXTag you are proposing for a future FIX version FIXT.1.2 / service pack FIX.5.0SP3 ?

Lets say there is a buy side HogHedgeFund which uses its industrywide CompID = HOG having multiple trading desks like US Equities trading desk using SubID=USEQ, Fixed income trading desk using SubID=FIXED etc. Now lets say there are three traders Dickenson, Thompson and Harrison in the US Equities trading desk. Now the need is to also send their HogHedgeFund Single signon IDs TOM / DICK / HARRY to the counterparty to identify which trader placed each trade. If the trader id is used as SubID, then the trading desk sub id USEQ would not be sent and I do not know if the business would accept it. There could be rippling effects of this change across organization affecting multiple systems in the workflow chain.

Whats is the objection to adding this new Tag UserSessionID to older versions ?

Regards,
K. Mahesh

We need to support multiple user sessions over a single FIX session using FIX.4.4.

Long term within FIX (FIX.5.0SP3 – likely) we will have a BusinessApplicationHeader with From/ToParty blocks where UserSessionID can be maintained.

For pre-FIX.5.0SP3 versions the initial thought was put UserSessionID in the Party block at the root level of the message (whatever that block happens to be named, not all messages have a Parties block yet).

There was push back from internal developers because the field is potentially on different messages throughout the API.

Does anyone see an issue in pre-FIX.5.0 versions carrying the User Session ID (as opposed to the FIX SessionID) in the SenderSubID / TargetSubID field in the StandardHeader?

5

Hi Hanno,

Sorry for not being clear. What I meant was a user wanting a new tag has two options:-

  1. Define a user defined tag (as Jim has done for UserSessionID)

  2. Submit a gap analysis for new tag to GTC and after the new tag is added to next FIX version / service pack, “pull it to lower version”. For example Jeremy Sutton has explained using 35=AB^ New Order MultiLeg in 8=FIX.4.2^ session (refer http://www.fixprotocol.org/discuss/read/4e512492) and has pointed out “The mixed approach which I think makes a great deal of sense and makes progress towards upgrading versions” and I fully agree with Jeremy’s idea about adding functionality which would also be a step in the direction of upgrading to higher FIX version.

My point was rather than using UDF, let it be added to next FIX version / service pack and lets “pull the new tag” to a previous version and use the newly introduced and standardized functionality rather than customization.

Regards,
K. Mahesh

Mahesh,

new tags are not added to older FIX versions in general with a few well-defined exceptions for regulatory purposes. Otherwise there would be no real need to have a version at all as there is always somebody who could use a new tag in an older version. I compare it to a software vendor rolling out new features under an old version of his software. You want X to be stable once you have tested against X. Changing X should mean to introduce Y where X and Y are version numbers with X<Y.

UserSessionID was probably not meant as a new field. There is a PartyRole 55=Session ID that could be used for this purpose.

Regards,
Hanno.

6

Jim,

I tried searching for UserSessionID FIXTag and could not find anything. Is this a new FIXTag you are proposing for a future FIX version FIXT.1.2 / service pack FIX.5.0SP3 ?

Lets say there is a buy side HogHedgeFund which uses its industrywide CompID = HOG having multiple trading desks like US Equities trading desk using SubID=USEQ, Fixed income trading desk using SubID=FIXED etc. Now lets say there are three traders Dickenson, Thompson and Harrison in the US Equities trading desk. Now the need is to also send their HogHedgeFund Single signon IDs TOM / DICK / HARRY to the counterparty to identify which trader placed each trade. If the trader id is used as SubID, then the trading desk sub id USEQ would not be sent and I do not know if the business would accept it. There could be rippling effects of this change across organization affecting multiple systems in the workflow chain.

Whats is the objection to adding this new Tag UserSessionID to older versions ?

Regards,
K. Mahesh

We need to support multiple user sessions over a single FIX session using FIX.4.4.

Long term within FIX (FIX.5.0SP3 – likely) we will have a BusinessApplicationHeader with From/ToParty blocks where UserSessionID can be maintained.

For pre-FIX.5.0SP3 versions the initial thought was put UserSessionID in the Party block at the root level of the message (whatever that block happens to be named, not all messages have a Parties block yet).

There was push back from internal developers because the field is potentially on different messages throughout the API.

Does anyone see an issue in pre-FIX.5.0 versions carrying the User Session ID (as opposed to the FIX SessionID) in the SenderSubID / TargetSubID field in the StandardHeader?

My thoughts:

  1. I am not totally clear on what a “User Session ID” is, and how it is established. Is this a pre-defined value for each user that the counterparty has a registry of? Are there any “in-band authentication” steps around each user session id? If this is simply a pre-defined value for each user that the counterparty has a registry of, then I think SenderSubID (50) could be used for that.

  2. Firms like mine have been populating SenderSubID on New Order - Single messages with an value identifying the user for a some time, and brokers receiving these orders often have rules and a registry of my values which they validate against. My initial reaction is that this likely constitutes a form of “user session id”.

  3. Regarding Mahesh’s points concerning which desk orders are originating from, I believe this should be handled via (assuming 4.2) SenderLocationID (142) and TargetLocationID (143) – not SenderSubID (50) and TargetSubID (57).

  4. All of these values have a “perspective”, in that messages I send, I populate Sender___ fields for my values, and if applicable, I populate Target___ fields for my counterparty’s values. These values, and the “perspective”, are reversed for messages I receive. So, if you’re seeking to convey “user session id” information within ___SubID, you would need to determine if both sides of the session have “user sessions”, or if only one side has user sessions into a more centralized trading system/market.

  5. The spec does not specify the purpose and which type of values to use for the ____SubID fields, therefore, the use and interpretation of these must be bi-laterally agreed upon. Thus, I would assume the real world situation that needs the user session ids could establish use of ___SubID via bi-lateral agreement.

7

I agree with Scott’s views. I have held off commenting on this because I thought I may have been missing something.

However, my experience has been that CameronFIX customers have been been “multiplexing” multiple users’ messages over a single FIX session for many years using the good old fashioned subID’s and locationID’s.

I am not sure I see the need for introducing anything new to the protocol.

John

My thoughts:

  1. I am not totally clear on what a “User Session ID” is, and how it is established. Is this a pre-defined value for each user that the counterparty has a registry of? Are there any “in-band authentication” steps around each user session id? If this is simply a pre-defined value for each user that the counterparty has a registry of, then I think SenderSubID (50) could be used for that.

  2. Firms like mine have been populating SenderSubID on New Order - Single messages with an value identifying the user for a some time, and brokers receiving these orders often have rules and a registry of my values which they validate against. My initial reaction is that this likely constitutes a form of “user session id”.

  3. Regarding Mahesh’s points concerning which desk orders are originating from, I believe this should be handled via (assuming 4.2) SenderLocationID (142) and TargetLocationID (143) – not SenderSubID (50) and TargetSubID (57).

  4. All of these values have a “perspective”, in that messages I send, I populate Sender___ fields for my values, and if applicable, I populate Target___ fields for my counterparty’s values. These values, and the “perspective”, are reversed for messages I receive. So, if you’re seeking to convey “user session id” information within ___SubID, you would need to determine if both sides of the session have “user sessions”, or if only one side has user sessions into a more centralized trading system/market.

  5. The spec does not specify the purpose and which type of values to use for the ____SubID fields, therefore, the use and interpretation of these must be bi-laterally agreed upon. Thus, I would assume the real world situation that needs the user session ids could establish use of ___SubID via bi-lateral agreement.

8

I guess I possibly confused the question with the UserSessionID.

I was looking for the recommended practice from an FPL perspective on how to support multiple user sessions in a modern exchange environment.

Can we say that the use of UserRequest/UserResponse is appropriate to initiate sessions on an exchange environment for FIX.4.4 and that UserName or whatever is consider a unique user identifier will be carried int the *SubID field.

For FIX.4.2 - there is no message available to actually initiate a specific User Session over FIX Session.

Within FIX.5.0-FIX.5.0SP2 - the use of UserRequest/UserResponse in addition to carrying the User information within the Party block of the message is recommended.

FIX.5.0SP3 and later - we will likely have the Business Application Header which will support carrying User Session information independent of Session layer.

The part I was looking for was - should the User session identifier (UserName, unique id, session string, badge number, whatever) be subsequently carried in the *SubID fields (Sender, Target) once a User session has been established over a FIX Session.

I agree with Scott’s views. I have held off commenting on this because I thought I may have been missing something.

However, my experience has been that CameronFIX customers have been been “multiplexing” multiple users’ messages over a single FIX session for many years using the good old fashioned subID’s and locationID’s.

I am not sure I see the need for introducing anything new to the protocol.

John

My thoughts:

  1. I am not totally clear on what a “User Session ID” is, and how it is established. Is this a pre-defined value for each user that the counterparty has a registry of? Are there any “in-band authentication” steps around each user session id? If this is simply a pre-defined value for each user that the counterparty has a registry of, then I think SenderSubID (50) could be used for that.

  2. Firms like mine have been populating SenderSubID on New Order - Single messages with an value identifying the user for a some time, and brokers receiving these orders often have rules and a registry of my values which they validate against. My initial reaction is that this likely constitutes a form of “user session id”.

  3. Regarding Mahesh’s points concerning which desk orders are originating from, I believe this should be handled via (assuming 4.2) SenderLocationID (142) and TargetLocationID (143) – not SenderSubID (50) and TargetSubID (57).

  4. All of these values have a “perspective”, in that messages I send, I populate Sender___ fields for my values, and if applicable, I populate Target___ fields for my counterparty’s values. These values, and the “perspective”, are reversed for messages I receive. So, if you’re seeking to convey “user session id” information within ___SubID, you would need to determine if both sides of the session have “user sessions”, or if only one side has user sessions into a more centralized trading system/market.

  5. The spec does not specify the purpose and which type of values to use for the ____SubID fields, therefore, the use and interpretation of these must be bi-laterally agreed upon. Thus, I would assume the real world situation that needs the user session ids could establish use of ___SubID via bi-lateral agreement.

9

I would say the usage of *SubID fields is fine after having established a logical user session. You could think about providing a handle (unique ID) in the SenderSubID of the UserResponse message to be used instead of the Username as value in subsequent requests from the user. It makes the application messages shorter and allows you to audit trail the session in which messages were sent (by assigning a new ID every time a UserRequest to logon is made). Nothing big, just a thought.

I guess I possibly confused the question with the UserSessionID.

I was looking for the recommended practice from an FPL perspective on how to support multiple user sessions in a modern exchange environment.

Can we say that the use of UserRequest/UserResponse is appropriate to initiate sessions on an exchange environment for FIX.4.4 and that UserName or whatever is consider a unique user identifier will be carried int the *SubID field.

For FIX.4.2 - there is no message available to actually initiate a specific User Session over FIX Session.

Within FIX.5.0-FIX.5.0SP2 - the use of UserRequest/UserResponse in addition to carrying the User information within the Party block of the message is recommended.

FIX.5.0SP3 and later - we will likely have the Business Application Header which will support carrying User Session information independent of Session layer.

The part I was looking for was - should the User session identifier (UserName, unique id, session string, badge number, whatever) be subsequently carried in the *SubID fields (Sender, Target) once a User session has been established over a FIX Session.

10

Hi Scott,

Description for SenderCompID (49) says “Assigned value used to identify firm sending message.”

Description for SenderSubID (50) says “Assigned value used to identify specific message originator (desk, trader, etc.)”.

Description for SenderLocationID (142) says “Assigned value used to identify specific message originator’s location (i.e. geographic location and/or desk, trader)”

So based on these here are my thoughts:-

  1. SenderCompID (49) is the top level business entity

  2. The name SenderSubID implies it is ID of direct sub entity of the entity identified in SenderCompID

  3. Identification for desk, trader is mentioned in both SenderSubID (50) and SenderLocationID (142) making it ambiguous, but geographic location is mentioned only in SenderLocationID (142). My understanding was that if the same trading desk has more than one geographic location, then LocationID would be used to differentiate between these.

  4. Since Trading desk is above trader in heirarchy (i.e. trader works for a trading desk), SenderSubID should represent Trading desk rather than individual trader.

Within a company, I see the heirarchy of IDs as

SenderCompID > SenderSubID > SenderLocationID > SenderUserID

where SenderUserID is a new tag expected to be added to the next FIX version / service pack.

(Sorry for introducing a new Tag SenderUserID. I did this to avoid confusion with Jim’s UserSessionID)

Extending the 49=HOG^ example (trying to keep the example simple):-

Level 0 : SenderCompID = HOG

Level 1 : SenderSubID = {USEQ, FIXED}

Level 2 : SenderLocationID = {{NYC, SAN}, {NYC, ATL}}

Level 3 : Individual User = {{{TOM, DICK}, {HARRY}}, {{MAX}, {GRX}}}

Level 0 : HOG represents the topmost entity HogHedgeFund

Level 1 : USEQ represents the US Equities trading desk which is a sub-entity of HOG
FIXED represents the Fixed Income trading desk which is a sub-entity of HOG.

Level 2 : USEQ has locations at NYC (New York city) and SAN (SanFranscisco)
FIXED has locations at NYC (New York city) and ATL (Atlanta)

Level 3 : TOM and DICK work for USEQ desk at NYC
HARRY works for USEQ desk at SAN
MAX works for FIXED at NYC
GRX works for FIXED at ATL

I would recommend we prepare a gap analysis for this because I do not see any other way to convey three pieces of information - trading desk (SenderCompID sub entity), geographic location and individual User Id using only two tags SenderSubID and SenderLocationID without need for extra mapping to derive the third piece (and its associated performance issues).

Same applies to Target*IDs

Regards,
K. Mahesh

  1. Regarding Mahesh’s points concerning which desk orders are originating from, I believe this should be handled via (assuming 4.2) SenderLocationID (142) and TargetLocationID (143) – not SenderSubID (50) and TargetSubID (57).
11

Mahesh,

Given that the SubID and LocationID values and use are bi-laterally agreed upon, I do not think there is an explicit, nor implied hierarchy.

(I’m leaving out the DeliverTo/OnBehalfOf from this discussion as that only adds complexity)

  1. SenderCompID is a static value and represents the entity for the other end of the FIX session. I do not think it is really pertinent to this discussion.

  2. SenderSubID has been around since FIX was initially released and was the only ‘flexible’ field to provide any identification data (for the sender), but more importantly has been used to provide instruction/direction as to ‘where’ a message is to be directed (via TargetSubID). So, I have had brokers that ask me to populate TargetSubID with specific values (eg to route to algo/DMA system vs. salestrading desk, to route to a Convertible Bond desk/system, to route to FX dealing system, etc.

  3. SenderLocationID was added in 4.1, is not part of 4.0 which many equity trading sessions were initially established upon. It was added to support the ability to more clearly specify ‘where’. It was also added to provide the ability to convey more than one flexible value.

  4. The language in the spec for SenderSubID has existed since its introduction in 2.7, and as you point out, was not amended to remove its reference to ‘desk’ in the list of example uses. (‘desk’ appears in the description of both SenderSubID and SenderLocationID).

In practice and based upon my experience, some firms use (from an order initiator’s perspective) TargetSubID for things that could be conveyed in TargetLocationID. Overall, I think it is safe to say that the SubID is much more broadly used than LocationID.

Again, given that the use of the values are bilaterally agreed upon, I’m not sure that it is important to establish such a hierarchy (though you could certainly do so), especially if that means that in order to use a SubID value, one MUST also use a LocationID value.

Hi Scott,

Description for SenderCompID (49) says “Assigned value used to identify firm sending message.”

Description for SenderSubID (50) says “Assigned value used to identify specific message originator (desk, trader, etc.)”.

Description for SenderLocationID (142) says “Assigned value used to identify specific message originator’s location (i.e. geographic location and/or desk, trader)”

So based on these here are my thoughts:-

  1. SenderCompID (49) is the top level business entity

  2. The name SenderSubID implies it is ID of direct sub entity of the entity identified in SenderCompID

  3. Identification for desk, trader is mentioned in both SenderSubID (50) and SenderLocationID (142) making it ambiguous, but geographic location is mentioned only in SenderLocationID (142). My understanding was that if the same trading desk has more than one geographic location, then LocationID would be used to differentiate between these.

  4. Since Trading desk is above trader in heirarchy (i.e. trader works for a trading desk), SenderSubID should represent Trading desk rather than individual trader.

Within a company, I see the heirarchy of IDs as

SenderCompID > SenderSubID > SenderLocationID > SenderUserID

where SenderUserID is a new tag expected to be added to the next FIX version / service pack.

(Sorry for introducing a new Tag SenderUserID. I did this to avoid confusion with Jim’s UserSessionID)

Extending the 49=HOG^ example (trying to keep the example simple):-

Level 0 : SenderCompID = HOG

Level 1 : SenderSubID = {USEQ, FIXED}

Level 2 : SenderLocationID = {{NYC, SAN}, {NYC, ATL}}

Level 3 : Individual User = {{{TOM, DICK}, {HARRY}}, {{MAX}, {GRX}}}

Level 0 : HOG represents the topmost entity HogHedgeFund

Level 1 : USEQ represents the US Equities trading desk which is a sub-entity of HOG
FIXED represents the Fixed Income trading desk which is a sub-entity of HOG.

Level 2 : USEQ has locations at NYC (New York city) and SAN (SanFranscisco)
FIXED has locations at NYC (New York city) and ATL (Atlanta)

Level 3 : TOM and DICK work for USEQ desk at NYC
HARRY works for USEQ desk at SAN
MAX works for FIXED at NYC
GRX works for FIXED at ATL

I would recommend we prepare a gap analysis for this because I do not see any other way to convey three pieces of information - trading desk (SenderCompID sub entity), geographic location and individual User Id using only two tags SenderSubID and SenderLocationID without need for extra mapping to derive the third piece (and its associated performance issues).

Same applies to Target*IDs

Regards,
K. Mahesh

  1. Regarding Mahesh’s points concerning which desk orders are originating from, I believe this should be handled via (assuming 4.2) SenderLocationID (142) and TargetLocationID (143) – not SenderSubID (50) and TargetSubID (57).
12

Mahesh

Right now I am using a UDF field for UserSessionID.

Jim,

I tried searching for UserSessionID FIXTag and could not find anything. Is this a new FIXTag you are proposing for a future FIX version FIXT.1.2 / service pack FIX.5.0SP3 ?

Lets say there is a buy side HogHedgeFund which uses its industrywide CompID = HOG having multiple trading desks like US Equities trading desk using SubID=USEQ, Fixed income trading desk using SubID=FIXED etc. Now lets say there are three traders Dickenson, Thompson and Harrison in the US Equities trading desk. Now the need is to also send their HogHedgeFund Single signon IDs TOM / DICK / HARRY to the counterparty to identify which trader placed each trade. If the trader id is used as SubID, then the trading desk sub id USEQ would not be sent and I do not know if the business would accept it. There could be rippling effects of this change across organization affecting multiple systems in the workflow chain.

Whats is the objection to adding this new Tag UserSessionID to older versions ?

Regards,
K. Mahesh

We need to support multiple user sessions over a single FIX session using FIX.4.4.

Long term within FIX (FIX.5.0SP3 – likely) we will have a BusinessApplicationHeader with From/ToParty blocks where UserSessionID can be maintained.

For pre-FIX.5.0SP3 versions the initial thought was put UserSessionID in the Party block at the root level of the message (whatever that block happens to be named, not all messages have a Parties block yet).

There was push back from internal developers because the field is potentially on different messages throughout the API.

Does anyone see an issue in pre-FIX.5.0 versions carrying the User Session ID (as opposed to the FIX SessionID) in the SenderSubID / TargetSubID field in the StandardHeader?

13

Jim,

Where can I find more information regarding BusinessApplicationHeader you mentioned in your first post in this Thread?

Regards,
K. Mahesh

Mahesh

Right now I am using a UDF field for UserSessionID.

Jim,

I tried searching for UserSessionID FIXTag and could not find anything. Is this a new FIXTag you are proposing for a future FIX version FIXT.1.2 / service pack FIX.5.0SP3 ?

Lets say there is a buy side HogHedgeFund which uses its industrywide CompID = HOG having multiple trading desks like US Equities trading desk using SubID=USEQ, Fixed income trading desk using SubID=FIXED etc. Now lets say there are three traders Dickenson, Thompson and Harrison in the US Equities trading desk. Now the need is to also send their HogHedgeFund Single signon IDs TOM / DICK / HARRY to the counterparty to identify which trader placed each trade. If the trader id is used as SubID, then the trading desk sub id USEQ would not be sent and I do not know if the business would accept it. There could be rippling effects of this change across organization affecting multiple systems in the workflow chain.

Whats is the objection to adding this new Tag UserSessionID to older versions ?

Regards,
K. Mahesh

We need to support multiple user sessions over a single FIX session using FIX.4.4.

Long term within FIX (FIX.5.0SP3 – likely) we will have a BusinessApplicationHeader with From/ToParty blocks where UserSessionID can be maintained.

For pre-FIX.5.0SP3 versions the initial thought was put UserSessionID in the Party block at the root level of the message (whatever that block happens to be named, not all messages have a Parties block yet).

There was push back from internal developers because the field is potentially on different messages throughout the API.

Does anyone see an issue in pre-FIX.5.0 versions carrying the User Session ID (as opposed to the FIX SessionID) in the SenderSubID / TargetSubID field in the StandardHeader?