The PingPong example shipped with QWFIX SDK is simple. PingPong example consists of two processes, a client and a server. There are three FIX sessions defined in both engines, one FIX 4.2 session, one FIX 4.4 session and one FIX 5.0 session.
The FIX 4.2 and 4.4 sessions use the traditional FIX session transport protocol for FIX 4.2 and 4.4.
The FIX 5.0 session uses the new FIX session transport protocol "FIXXT1.1". The FIX 5.0 session supports 5 different versions of FIX protocol, from FIX 4.1 to FIX 5.0SP1.
Everytime the enter key is pressed in the console of the client process, it sends a batch of "New Order Single" FIX message to the server. The server will send back an "Execution Report" FIX message in response to every order message it receives.
The client uses round-robin algorithm to choose the sessions and the FIX version used in the session (only available for FIX 5.0+).
Note there's no further order handling logic implemented in PingPong example, it only demonstrates simple message exchange in QWFIX. For information about the set up of the demo system, please read "Quick Start Guide - Setting Up and Running Samples".
User can manually kill either the client or the server process (or both) and restart them to test the recovery and robustness of QWFIX system.
Note: Because the processes are burtally killed, the process may not be able to perform the task to send the last FIX message. As a result everytime one process is killed, the count of incoming and outgoing FIX messages of both processes may not exactly match. It is not the problem of QWFIX. In "real" applications it's easy for the business logic code to figure out the gap during the recovery process and "catch up" after the recovery. In the PingPong example for simplicity we just choose not to do that.