能否在单个QuickFIX引擎实例中同时配置Initiator和Acceptor两种连接类型？

Absolutely! You can absolutely run both an Initiator and an Acceptor within the same QuickFIX engine instance—this is a well-supported, common use case that fits exactly your business need (acting as an Initiator for Bloomberg while hosting an Acceptor for another enterprise).

Here’s how to make it work:

1. Configure both sessions in a single settings file #

You’ll define two distinct [SESSION] blocks in your QuickFIX configuration file, one for each connection type:

# Bloomberg Initiator session
[SESSION]
BeginString=FIX.4.4
SenderCompID=YOUR_FIRM_ID
TargetCompID=BLP
ConnectionType=initiator
SocketConnectHost=bloomberg-fix-host.example.com
SocketConnectPort=8194
StartTime=08:00:00
EndTime=18:00:00

# Enterprise Acceptor session
[SESSION]
BeginString=FIX.4.4
SenderCompID=YOUR_FIRM_ID
TargetCompID=PARTNER_FIRM_ID
ConnectionType=acceptor
SocketAcceptPort=9876
StartTime=07:00:00
EndTime=19:00:00

Each session has its own identifiers, connection parameters, and schedule—make sure the ConnectionType is set correctly for each (initiator for outgoing, acceptor for incoming).

2. Initialize both Initiator and Acceptor in your code #

When setting up your QuickFIX engine, load the combined settings file, then instantiate both an Initiator and an Acceptor, linking them to your custom Application implementation (you can use the same Application for both sessions, or separate ones if your logic requires it).

For example, in Java:

SessionSettings settings = new SessionSettings("your-config-file.cfg");
MyFixApplication app = new MyFixApplication();
FileStoreFactory storeFactory = new FileStoreFactory(settings);
FileLogFactory logFactory = new FileLogFactory(settings);

// Initialize Initiator for Bloomberg
SocketInitiator initiator = new SocketInitiator(app, storeFactory, settings, logFactory);
// Initialize Acceptor for the enterprise partner
SocketAcceptor acceptor = new SocketAcceptor(app, storeFactory, settings, logFactory);

// Start both
initiator.start();
acceptor.start();

3. Handle session-specific logic in your Application #

In your Application callbacks (like fromApp, toApp, onCreate), use the SessionID parameter to distinguish between the two sessions. This lets you route messages correctly—e.g., process Bloomberg messages one way, and your partner’s messages another.

Example snippet (Java):

@Override
public void fromApp(Message message, SessionID sessionID) throws FieldNotFound, IncorrectDataFormat, IncorrectTagValue, UnsupportedMessageType {
    if (sessionID.getTargetCompID().equals("BLP")) {
        // Handle Bloomberg incoming message
        processBloombergMessage(message);
    } else if (sessionID.getTargetCompID().equals("PARTNER_FIRM_ID")) {
        // Handle partner enterprise incoming message
        processPartnerMessage(message);
    }
}

Key Notes #

• Thread Safety: QuickFIX runs sessions in separate threads, so your Application implementation must be thread-safe (avoid shared mutable state without proper synchronization).
• Session Isolation: Each session maintains its own sequence numbers, heartbeats, and state—you don’t have to worry about cross-session interference as long as your configuration is correct.
• Scalability: This setup works well for most use cases; if you’re dealing with extremely high message volumes, you might want to split into separate instances, but for typical enterprise/Bloomberg integrations, a single instance is more than sufficient.

内容的提问来源于stack exchange，提问作者Jarda