Imported from previous forum
Hello all,
I’ve been working with the Trading Session Status and Trading Session Status Request messages.
Trading Session Request messages include a unique "TradSesReqID" to identify the request. Solicited snapshot Status messages echo back this field for identification purposes. This is simple enough.
Counterparties may also subscribe for unsolicited updates so Trading Session Status messages are sent whenever necessary. According to the FIX 4.4 spec, "TradSesReqID" is NOT required in unsolicited responses to a previous subscription.
However, when attempting to unsubscribe from unsolicited updates, the counterparty must specify the "TradSesReqID" from their original subscription attempt.
This implies that if a counterparty sends me N subscriptions to a particular "TradingSessionID" I should receive N unsubscriptions before I stop sending them unsolicited updates about "TradingSessionID". However there are some questions:
(i) When the status changes, should I send one unsolicited Trading Session Status or N copies of the same message? (ie, one per active subscription - seems rather pointless)
(ii) If the counterparty tries to unsubscribe, but supplies an unknown "TradSesReqID" should I issue a rejection or simply ignore the request?
I’m asking for reasons of implementation complexity.
In the simple case, I can just count the number of subscriptions and unsubscriptions I have received for a particular "TradingSessionID" and stop sending unsolicited updates when the count reaches zero.
In the complex case I must keep a record of all active "TradSesReqID"s I have received in subscriptions so I can issue rejects if the counterparty tries to unsubscribe using an unknown "TradSesReqID".
I’m not seeing what value the complex case adds. The key point is the ONLY thing a record of active "TradSesReqID"s would be used for is rejecting unsubscription attempts: they are NOT required in the actual unsolicited Trading Session Status messages. It would seem simpler to amend the spec to not require a “TradSesReqID” in an unsubscription message, and to clarify that subscriptions are simply counted.
Any feedback is appreciated.
[ original email was from Jim Northey - jnorthey@lasalletech.com ]
The TradSesReqID is conditionally required when Trading Session Status messages are being sent in response to a subscription or snapshot request made via a Trading Session Status Request.
The TradSesReqID is not required for the scenario where the publisher of Trading Session Status messages sends the trading session status over a FIX session without requiring a subscription from the user (where counterparties agree that as part of a FIX session - trading session status will be sent automatically as trading session state changes).
Although not explicitly documented, other users have chosen to implement the Trading Session Status Request subcription process in a way that only allows one subscription per FIX Session + TradingSessionID. This eliminates the need to have to manage multiple subscriptions for the same information - which is a real headache - as you have indicated.
Recommendation is to reject subsequent subscription requests for the same trading session id over the same FIX session.
Also recommend that you reject any Trading Session Status Request that does not contain a TradSesReqID - whether it be for subscription or snapshot.
> Hello all,
>
> I’ve been working with the Trading Session Status and Trading Session Status Request messages.
>
> Trading Session Request messages include a unique “TradSesReqID” to identify the request. Solicited snapshot Status messages echo back this field for identification purposes. This is simple enough.
>
> Counterparties may also subscribe for unsolicited updates so Trading Session Status messages are sent whenever necessary. According to the FIX 4.4 spec, “TradSesReqID” is NOT required in unsolicited responses to a previous subscription.
>
> However, when attempting to unsubscribe from unsolicited updates, the counterparty must specify the “TradSesReqID” from their original subscription attempt.
>
> This implies that if a counterparty sends me N subscriptions to a particular “TradingSessionID” I should receive N unsubscriptions before I stop sending them unsolicited updates about “TradingSessionID”. However there are some questions:
>
> (i) When the status changes, should I send one unsolicited Trading Session Status or N copies of the same message? (ie, one per active subscription - seems rather pointless)
>
> (ii) If the counterparty tries to unsubscribe, but supplies an unknown “TradSesReqID” should I issue a rejection or simply ignore the request?
>
> I’m asking for reasons of implementation complexity.
>
> In the simple case, I can just count the number of subscriptions and unsubscriptions I have received for a particular “TradingSessionID” and stop sending unsolicited updates when the count reaches zero.
>
> In the complex case I must keep a record of all active "TradSesReqID"s I have received in subscriptions so I can issue rejects if the counterparty tries to unsubscribe using an unknown “TradSesReqID”.
>
> I’m not seeing what value the complex case adds. The key point is the ONLY thing a record of active "TradSesReqID"s would be used for is rejecting unsubscription attempts: they are NOT required in the actual unsolicited Trading Session Status messages. It would seem simpler to amend the spec to not require a “TradSesReqID” in an unsubscription message, and to clarify that subscriptions are simply counted.
>
> Any feedback is appreciated.
>