5

Suppose that I'm running a web-based exchange and a new customer signs up. I give that customer a new CompID and now I want to add that CompID to my acceptor. Do I have to restart my acceptor or can that be done dynamically?

It doesn't seem very scalable to have to agree on the CompID ahead of time and then sticking it in a configuration somewhere.

I've seen some examples which supposedly do that, but they seem to simply change the configuration to pretty much ignore the Sender/Target CompID's by setting them to *. Any other ways to do that?

Kiril
  • 39,672
  • 31
  • 167
  • 226

2 Answers2

5

Take a look at the DynamicAcceptorSessionProvider and how it's used in the Executor example. The Executor example reads session "templates" from the settings file and associates these with the acceptor endpoint IP address. An acceptor template is identified by the "AcceptorTemplate=true" setting. Any of the session ID fields, including the FIX version, can be wildcarded, not just the SenderCompID.

See the executor_dynamic.cfg for an example of how session templates are defined. In this configuration, both the SenderCompID and TargetCompID are wildcarded and templates for various FIX versions are defined (to specify the appropriate data dictionary file).

When a message arrives for an unknown session ID, the DynamicAcceptorSessionProvider will try to match the session ID with a template's wildcarded sessionID. If it finds a match, the new session will be created automatically and added to the acceptor as if it had been explicitly defined in the settings. The new session will have the settings defined in the acceptor session template.

The DynamicAcceptorSessionProvider is an AcceptorSessionProvider implementation that uses the settings file to support dynamic session creation. However, you could also implement a custom AcceptorSessionProvider that could dynamically create sessions based on database information, for example.

Frank Smith
  • 978
  • 5
  • 11
2

I think you want to fix the TargetCompID and send a unique SenderCompID for each user to use. Then you set the SenderCompID in your acceptor config to *. This will allow the acceptance of all SenderCompIDs. However you will need to have somewhere in your code the facility to check each order against your database of users. If the user(SenderCompID) is not valid then you will send a reject message. Many implementations will also use tunnels and whitelisted IP addresses as well to make sure no unwanted connections are coming in.

MartyIX
  • 27,828
  • 29
  • 136
  • 207
robthewolf
  • 7,343
  • 3
  • 29
  • 29
  • 1
    In the examples of quickfixj the Executor's acceptor takes in settings in which the `SenerCompID` is `EXEC` and the `TargetCompID` is `BANZAI`. I infer this to mean that setting the `SenderCompID` of the acceptor to `*` will result in the messages, coming from the acceptor, not being identified with a sender. All the examples I've seen seem to indicate that the `SenderCompID` is the current sender's ID (in this case if it's an Acceptor then it's the CompID of the exchange). – Kiril Oct 29 '13 at 11:55
  • I don't follow your comment at all. – robthewolf Oct 30 '13 at 07:19
  • @robthewolf I think he's saying that in your answer, Sender and Target are essentially backwards, which I agree with (although I'm still pretty new to all this) – Joe Phillips Feb 01 '23 at 16:42