Reusing the SessionID or UUID

[adkapur]

3.5.1 Session Identification Each session must be identified by a unique Session ID encoded as a UUID version 4 (RFC 4122) assigned by the client. The benefit of using an UUID is that it is effortless to allocate in a distributed system. It is also simple and efficient to hash and therefore easy to look up at the endpoints. The downside is a larger size overhead. The identifier however does not appear in the stream except once at the start of each datagram, when using UDP, or when sessions are multiplexed, regardless of the underlying transport that is used. For a non-multiplexed TCP session, the identifier therefore appears only once during the lifetime of the TCP session. A session identifier must be unique, not only amongst currently active sessions, but for all time. Reusing a session ID is a protocol violation.

It may not be appropriate to classify reusing session ID as a protocol violation since we don't want the exchange to shoulder the burden of having to validate this. If the customer does not ensure uniqueness then their FIXP sessions and sequence streams will converge and collapse into a single stream and retransmission of messages will not be reliable anymore.

[afuruhed]

The specification needs to be clear that a client reusing the session id to setup a new session violates the protocol, even if you do not validate this on the server side. In practice, reuse of a session uuid is only a problem if done in the same trading day/week. If the session id is reused, everyone should interpret this as an attempt to reuse the session. I do not understand your second sentence. I think you should validate this client behaviour in you certification procedures, by forcing the client to negotiate a few sessions during the procedure and that the uuid does not reappear.

[adkapur]

For the second sentence I meant to say if a firm establishes two FIXP sessions such that:

Session + Firm	UUID	NextSeqNo from Exchange	Transact Time of Last Msg	Market Segment
ABC100	123	100	T=0	50
ABC100	123	200	T+1	52

If ABC100 issues a RetransmisisonRequest for UUID 123 from 1-99 then messages from market segment 52 will be returned and messages from market segment 50 will not be recoverable due to usage of duplicate UUID's. This same principle applies to different FIXP connections on the same market segment as well.

[kleihan]

I do not understand the relationship of your FIXP sessions with the market segment. FIXP and its recovery options should have no idea to which market segment a message belongs to. In order to include market segment as functional attribute, one would rather use Application Sequencing (and not session level recovery) and define ApplID(1180) values based on market segments. That allows you to support retransmission of application messages regardless of any FIXP session. Of course this requires the application to keep track of messages it wants to offer recovery for. The problem of re-use UUIDs on the session layer is somewhat comparable to the re-use of ClOrdID values (e.g. from deleted orders) on the application layer. Although technically possible, it is not a good idea as it will complicate things such as an audit trail. From an exchange perspective it is a good idea to enforce ClOrdID uniqueness for active orders. In the case of the session layer and UUID this is automatic as you cannot have two active FIXP sessions with the same UUID. I see it as an unnecessary burden to the recipient of connection requests to keep track of all UUIDs ever received and reject requests with a known UUID. For me this is more an issue of education and best practices when using FIXP.

[adkapur]

I do not understand the relationship of your FIXP sessions with the market segment. FIXP and its recovery options should have no idea to which market segment a message belongs to. In order to include market segment as functional attribute, one would rather use Application Sequencing (and not session level recovery) and define ApplID(1180) values based on market segments. That allows you to support retransmission of application messages regardless of any FIXP session. Of course this requires the application to keep track of messages it wants to offer recovery for.

Our gateways are specific to a market segment but you could think of it as separate FIXP connections instead.

In the case of the session layer and UUID this is automatic as you cannot have two active FIXP sessions with the same UUID

This statement is not accurate because UUID assignment is done by customers and we cannot enforce this across gateways

I see it as an unnecessary burden to the recipient of connection requests to keep track of all UUIDs ever received and reject requests with a known UUID. For me this is more an issue of education and best practices when using FIXP.

Yes agreed, but forget about UUID's used previously, I don't want to keep track of uniqueness for UUID's being currently used across hundreds of FIXP sessions for the same executing firm across multiple gateways and that is why we are going to call out the danger of not choosing a globally unique UUID but I am trying to call this out explicitly in the FIXP specification since it is listed as a protocol violation there which means not being able to establish a FIXP session at all

NegotiationRejectCode = Credentials | Unspecified | FlowTypeNotSupported | DuplicateId

[kleihan]

Ok, understand. But on a single gateway, it is easy to check if a session with the same UUID is already active. Negotiation can then be rejected with the "DuplicateID" code. Is the scope of uniqueness defined anywhere in FIXP? Possibly a point for clarification in RC4.

[donmendelson]

The intended scope of uniqueness of UUID is forever. It is a 128 bit number, which can encompass the number of grains of sand on earth. This concept is used successfully throughout the computing industry.

At issue is how to enforce this. As @kleihan said, this can easily be enforced among active sessions on a given gateway since it needs to track sessions anyway. It would be more difficult to track old sessions or across multiple nodes. However, that should not prevent us from stating a rule for clients to abide by: never reuse a session ID. They are cheap to generate., The only potential problem is an operational error or bug in the client. The possibility of a bug can be tested in certification.

[kleihan]

Thanks @donmendelson, agree. I did not mean scope only in terms of time but more related to an enforcement (e.g. unique per session manager, unique across active sessions from the same IP address,...). But you basically answered that by saying that each client should have a concept in place which allows him to avoid re-use in general, full-stop. Violation of a stated rule is one thing, negotiating bilaterally who needs to "fix" it in case of operational problems , is another. The rule states that the client re-using UUIDs is in violation of the spec. It does not state that the recipient of duplicate UUIDs is in violation if he fails to detect it. He can offer this as a convenience with the scope (e.g. single gateway) of his own choice. That is my view.

[adkapur]

It does not state that the recipient of duplicate UUIDs is in violation if he fails to detect it.

This is a loaded statement because the specification says that Negotiation should be rejected and should not be allowed with a duplicateID

He can offer this as a convenience with the scope (e.g. single gateway) of his own choice. That is my view.

Agreed most likely we will not be enforcing it at all for the sake of consistency but I think it may not be appropriate to have a blanket statement in the specification saying that it is a protocol violation and it will not be tolerated at all period sinc eit will lead to a negotiation reject

The intended scope of uniqueness of UUID is forever. It is a 128 bit number, which can encompass the number of grains of sand on earth. This concept is used successfully throughout the computing industry.

I don't disagree with this but am only trying to do a CYA in the worst case scenario

The only potential problem is an operational error or bug in the client. The possibility of a bug can be tested in certification.

With all due respect certification does not tantamount to anything, once firms have certified then they make code changes all of the time and straight away deploy to production, we have seen this first hand

However, that should not prevent us from stating a rule for clients to abide by: never reuse a session ID. They are cheap to generate.

Agreed but this rule should not be actionable because then the specification states that the crime leads to punishment whereas that may not be true. It should be a best practice and the recommended way to go but the crime will not lead to punishment

[donmendelson]

@adkapur , protocols are specified to support interoperation of implementations, and violations are specified to list behaviors that may cause harm or risk to operations. Just as one implementation may be more accurate than another in compliance with the protocol, so too with violation detection. Because one implementation is not as good as another in detecting violations, does not invalidate the protocol or eliminate the possible or harm or risk that may ensue. To draw an analogy, just because a cop isn't around doesn't mean that speeding at 120 mph isn't a violation of rules of the road or that it doesn't put other drivers in jeopardy.

[adkapur]

Yes agreed, but the important difference here is that not assigning a unique UUID will cause harm to that customer only and not to others. We will still backstop the usage of UUID within the context of that entity since UUID becomes paramount for message recovery and we will ensure that if two customers are using the same UUID then they will not be able to recover each other's messages.

I don't think it is practical to expect validation of UUID across all FIXP sessions across all gateways and saying that UUID's will be validated only for FIXP sessions on a single gateway. This could be an issue for any exchange or large scale venue that adopts FIXP and it might be better to call this out in the FIXP specification.

[kleihan]

FIXP is not for the casual, fairly inexperienced developer of FIX interfaces. High performance is about having experts that are hence well aware of design pitfalls such as the re-use of identifiers across seemingly independent points of input. Feel free to add guidelines to your Rules of Engagement (which is a good practice anyway) to help your clients to avoid design mistakes at their end.

[adkapur]

Yes agreed, but could we not make this explicit in the specification as well? Could we not say the same thing i.e. it is incumbent on the customer to ensure this and not on the venue?

[kleihan]

We could but I suggest not to. Your use case (customer/execution venue) is only one of many for FIXP. That is my view on this topic.

[adkapur]

Yes we are one of many but we are also one of the early adopters and we would prefer not to be out of sync (right off the bat) with the protocol in which we have invested a lot of time in and are just trying to do the right thing here.

This is probably why the Moscow Exchange has dropped support for this ID altogether --> ftp://ftp.moex.com/pub/FORTS/TWIME/doc/spectra_wiregate_en.pdf

[afuruhed]

The spec should say that the client violates the protocol by reusing the uuid, not that the server violates the protocol by not detecting that the client violates the protocol. The original intention was not to make this a burden on the server to validate, but to state clearly how the client should and should not select the uuid. If it helps, the spec could clarify this.

There could be other places that are silent on what the counterparty is expected to do on a violation.

[kleihan]

@afuruhed +1

[adkapur]

The spec should say that the client violates the protocol by reusing the uuid, not that the server violates the protocol by not detecting that the client violates the protocol. The original intention was not to make this a burden on the server to validate, but to state clearly how the client should and should not select the uuid. If it helps, the spec could clarify this.

Amen to that