QuickFIX C++ library - general question regarding ThreadedSocketInitiator

Question

I am new to QuickFIX and I have some basic question regarding QuickFix:

1) Considering that at one time, there will be only one fix session between an acceptor and an initiator. I do not quite understand the purpose of ThreadedSocketInitiator and ThreadedSocketAcceptor classes.

Or do these classes exist to facilitate multiple sessions, in which multiple "initiators" can talk to different acceptors and vice versa?

2) Does QuickFIX has some kinds of message persistence, for example, what happens if the message is lost in transit? Does the engine takes care of resending the message?

Dextrad

Answer 1

1) Quickfix uses 1 thread per session. Engine you can assume is the whole process.

ThreadedSocketInitiator is used when you want to use the engine as a client. You connect to another server and transmit messages. You initiate connections, hence the name initiator. You spawn a new thread for each session you set up with a server.

ThreadedSocketAcceptor is used when you want to use the engine as a server. You accept connections hence acceptor. When you set up a new session with a client a new thread is spawned for that specific session only.

Remember all sessions have a unique id to differentiate between multiple sessions. A server can have multiple sessions with the same client and vice versa.

2) Yes. But the receiver has to initiate a ResendRequest message to make the sender to send again. It will do it automatically by checking the latency flag in the config file, if it hasn't received a reply to an already sent message.

Defilade

Thanks. If I start two sessions from my side with two SocketInitiator objects, even then the Quickfix will start two sessions (and maybe, two threads internally). So, how is ThreadedSocketInitiator different from SocketInitiator? – Dextrad

@Dextrad - SocketInitiator is a single thread model, ThreadedSocketInitiator is a multithreaded model. – Defilade

There is actually a separate thread for toApp and fromApp messages. However there is extensive use of mutex locking, so the user application can use each session as a logic thread. – Delicate