Fix8 is an open source C++ development toolkit and runtime engine designed to provide FIX connectivity to userland applications. Fix8 provides an API and framework that you can quickly develop a FIX interface on. Fix8 is flexible enough to work with any standard FIX version or custom variant. Fix8 is a member of the Fix Trading Community.

Fix8 Market Tech (Fix8MT) develops and maintains the Fix8 open source Framework, our commercial version Fix8Pro and has developers in Australia, China and the Russian Federation. Fix8MT is responsible for providing and managing professional support and consultancy services, and works closely with the Fix8 open source community to grow commercial support services through 3rd party ISVs.

Fix8Pro is our commercially supported version of Fix8. As well has providing support it has additional features and improvements suited to mission critical environments.
Fix8 is available in two editions - the open source community supported version and Fix8Pro, the commercially supported version. New features and enhancements are introduced to Fix8Pro. Some of these features may be released to the open source Fix8 project at a later stage depending on nature of those features and availability of Fix8 Market Tech resources. This does not affect the open source project and the community continues to enhance and improve the open source stream.
The FIX protocol allows market particpants and non-particpants to communicate with one another usually for the purposes of trading, reporting, regulation or surveillance. Typically this occurs between exchanges and brokers/institutions and regulators although many organisations also use FIX internally.
Fix8 is designed to be used by C++ developers for creating FIX protocol applications.

A lot of clever engineers have worked out that by using a more intelligent decoding algorithm, by skipping fields that are not of interest, and by decoding in place, performance can be greatly enhanced. We recognise and acknowledge that there are faster ways of decoding. The Fix8 message/field model is very flexible and powerful and will work with any FIX schema straight out of the box. We don't want to give this up. A faster decoder is certainly possible, along the lines mentioned above but focusing on specificity we lose on generality since Fix8 is a general purpose FIX engine. We want to retain our canonical approach and improve performance at the same time.

This is our challenge. We are currently planning our next phase of development which will include a super high performance version of Fix8 designed specifically for ULL environments.

These logos refer to organisations, companies and components that Fix8 uses, supports or is supported by.

Logo What Why
Github Github Hosts the Fix8 organisation source repository.
Consulting services are provided by Fix8 Market Technologies Pty Ltd Fix8 Market Tech Fix8 Market Technologies (Fix8MT) develops and maintains the Fix8 open source Framework, provides professional support and consultancy services, and works closely with the Fix8 open source community to grow commercial support services through 3rd party ISVs.
Fix8Pro Home Page Fix8Pro Our fully supported commercial version.
GNU Lesser General Public License GNU Lesser General Public License Our open source license.
Fix Protocol Fix Trading Community Fix8 is a member of FIX Trading Community (formerly FIX Protocol Limited or FPL). FTC is the non-profit industry association responsible for defining, managing and promoting increased usage of FIX as an enabler for electronic trading.
Atlassian Atlassian Provide us with community licenses for Jira, Confluence and Bamboo. Also host our Jira and Confluence instances.
Quantlabs.net Quantlabs We are collaborating to promote bespoke solutions for trading.
fastflow FastFlow Fix8 uses FastFlow for high performance concurrent queues.
fastflow Intel TBB Fix8 optionally uses Intel TBB for high performance concurrent queues.
Fix8 is open source and is released under the GNU LESSER GENERAL PUBLIC LICENSE Version 3, 29 June 2007.

This license does not require you to release your proprietary source code or Fix8 generated code when you release software that links dynamically against the Fix8 runtime library. If you wish to statically link you are required to release your application object files (not source code) with your software. See here for more information.

We chose the LGPL because we believe this license strikes the right balance between promoting FOSS and protecting free software while providing the most flexibility for 3rd party software developers. We decided against GPL because we felt it is too restrictive and against BSD style licenses because we felt these are too permissive. We recognise that many in the industry expect a library like Fix8 to be released with a BSD type license however we strongly believe that the LGPL will offer no impediment to commercial use either internally or by vendors.
Software that only links dynamically against the Fix8 library is not covered by the LGPL license. You are free to sell such software.
This only applies if you intend on publishing your software. If your software only uses the Fix8 library by dynamically linking against it, you are not required to release your code. If your software is based upon modifications to the Fix8 library, it is considered a derivative work and you are required to release the modified Fix8 source to the public. Software that inherits from Fix8 classes is not considered derivative.
Binary works that are the results of compilation of code that is generated by the Fix8 compiler can be published without releasing your source code as long as your binary links dynamically against an unmodified version of the Fix8 library. However you are required to leave the copyright text in the generated code.
Yes. Fix8 Market Tech offers Fix8Pro, our fully supported commercial version.
Fix8 is currently supported on Linux. Both 32 and 64 bit builds have been tested. Fix8 uses POSIX system calls and should work on other *NIX variants too. If you get Fix8 working on another *NIX please let us know.

Fix8 is also now supported on Windows.

Fix8 is also supported on OSX.

Fix8 requires the standard set of GNU/Linux dev tools, including gcc, libtool. Also required is the Poco library. Additional libraries are needed for building on Windows, see here.

Lock free containers and atomics are required for Fix8. Fix8 contains the FastFlow distribution which is used by default.
Alternatively you can use Intel TBB (if you are building for a 32 bit environment it is recommended that you use TBB). Also, for Windows, only TBB is currently supported.
Optionally you can use Oracle Berkeley DB. If you want to generate the API documentation you will also need doxygen.
If you want to run the built-in unit tests, you will also need Google gtest.
Fix8 will run on Intel IA32, x86-64, Itanium and compatible hardware (including AMD) using TBB or FastFlow. Fix8 will also run on PowerPC and ARMv7 using FastFlow.
Fix8 requires an XML schema document which describes the exact specifications of the messages and fields that will be supported by your application. You can use any of the standard schemas supplied with the package or supply your own.
What you need to to do is override Session::generate_logon() in your session class. In that method, the first thing you need to do is call the base class method. Then add your extra fields...
Message *my_sess::generate_logon(const unsigned heartbeat_interval, const f8String davi)
{
	Message *msg(Session::generate_logon(heartbeat_interval, davi));
	// now add your fields
	string rawstuff("blah");
	*msg << new TEX::RawDataLength(rawstuff.size());
	*msg << new TEX::RawData(rawstuff);
	return msg;
}
The same approach applies to all session level messages.
If you are using the session wrapper classes ClientSession, ReliableClientSession or ServerSession, you can call get_session_element(). This returns a pointer to the XmlElement for the active session. With this object you can search for additional attributes parsed from your xml config file, using XmlElement::FindAttr() or XmlElement::GetAttr()
When you override Session::handle_application and call msg->process(your_router) you must define this method in a compilation unit (*.cpp file) and not inlined in a header.
Nested repeating groups are easy to use. The following example creates multiple nested groups. Using find_group and then create_group you can locate the group you wish to add, create an instance, populate the fields and then add it to the message.
*nos << new TEX::NoUnderlyings(3);
GroupBase *noul(nos->find_group());

// repeating groups
MessageBase *gr1(noul->create_group());
*gr1 << new TEX::UnderlyingSymbol("BLAH");
*gr1 << new TEX::UnderlyingQty(1 + RandDev::getrandom(999));
*noul << gr1;

MessageBase *gr2(noul->create_group());
*gr2 << new TEX::UnderlyingSymbol("FOO");
// nested repeating groups
*gr2 << new TEX::NoUnderlyingSecurityAltID(2);
*noul << gr2;
GroupBase *nosai(gr2->find_group());
MessageBase *gr3(nosai->create_group());
*gr3 << new TEX::UnderlyingSecurityAltID("UnderBlah");
*nosai << gr3;
MessageBase *gr4(nosai->create_group());
*gr4 << new TEX::UnderlyingSecurityAltID("OverFoo");
*nosai << gr4;

MessageBase *gr5(noul->create_group());
*gr5 << new TEX::UnderlyingSymbol("BOOM");
// nested repeating groups
GroupBase *nus(gr5->find_group());
static const char *secIDs[] = { "Reverera", "Orlanda", "Withroon", "Longweed", "Blechnod" };
*gr5 << new TEX::NoUnderlyingStips(sizeof(secIDs)/sizeof(char *));
for (size_t ii(0); ii < sizeof(secIDs)/sizeof(char *); ++ii)
{
	MessageBase *gr(nus->create_group());
	*gr << new TEX::UnderlyingStipType(secIDs[ii]);
	*nus << gr;
}
*noul << gr5;

// multiply nested repeating groups
*nos << new TEX::NoAllocs(1);
GroupBase *noall(nos->find_group());
MessageBase *gr9(noall->create_group());
*gr9 << new TEX::AllocAccount("Account1");
*gr9 << new TEX::NoNestedPartyIDs(1);
*noall << gr9;
GroupBase *nonp(gr9->find_group());
MessageBase *gr10(nonp->create_group());
*gr10 << new TEX::NestedPartyID("nestedpartyID1");
*gr10 << new TEX::NoNestedPartySubIDs(1);
*nonp << gr10;
GroupBase *nonpsid(gr10->find_group());
MessageBase *gr11(nonpsid->create_group());
*gr11 << new TEX::NestedPartySubID("subnestedpartyID1");
*nonpsid << gr11; 
Yes. Since you have complete control over the shape and nature of all FIX messages in your application by supplying the schema to the compiler, you can fine tune the FIX spoken to include any field you wish.
From the fix8 directory, do the following...
% make clean
% ./configure [with your options here]
% make; make install
To enable profiling with gprof, add --enable-gprof to your configure command line. When you run your application the file gmon.out will be generated. Run gprof to examine the profile.
Yes. To enable CODEC profiling, add --enable-codectiming to your configure command line. Fix8 will out message encode and decode timings to the global logger.
You may want to specify a local build for TBB, Poco or Berkeley DB instead of the default locations - if for example you don't have permission on your system to install the libraries or you want to test a new library build. To specify an alternate location, simply pass the alternate directory to configure, for example:
% ./configure --with-poco=/home/davo --with-tbb=home/davo --with-bdb=/home/davo
This assumes that the local install lib, include, bin, and so forth are immediately below the directory specified. You will also need to update your LD_LIBRARY_PATH before running your application. In our above example:
% export LD_LIBRARY_PATH=/home/davo/lib:$LD_LIBRARY_PATH
Try running the following:
% ./bootstrap
If this fails, install libtool. If you are using debian or ubuntu:
% apt-get install libtool
On centos/RH:
% yum install libtool
You might also need autoconf and automake. Install these the same way.
This problem is usually because you have built the poco library yourself. PocoXML is built in by default which leads to some cross-dependencies. The fix is to modify compiler/Makefile.am and replace:
POCO_LIBS = -lPocoFoundation -lPocoNet -lPocoUtil
with the following:
POCO_LIBS = -lPocoFoundation -lPocoNet -lPocoUtil -lPocoXML
The Fix8 compiler requires that your schema declare each FIX msgtype referred to in your Message section in the field type 35 (Msgtype) in the fields element. The compiler needs these to verify your message definitions. You should have something like the following...
<fields>
.
.
.
	<field number='35' name='MsgType' type='STRING'>
		<value enum='0' description='HEARTBEAT' />
		<value enum='1' description='TEST_REQUEST' />
		<value enum='2' description='RESEND_REQUEST' />
		<value enum='3' description='REJECT' />
		<value enum='4' description='SEQUENCE_RESET' />
		<value enum='5' description='LOGOUT' />
		<value enum='6' description='INDICATION_OF_INTEREST' />
		<value enum='7' description='ADVERTISEMENT' />
		<value enum='8' description='EXECUTION_REPORT' />
.
.
.
By default, gcc is chosen by configure to build Fix8. You can override this by passing an environment variable to configure, as follows:
CXX=clang ./configure [with your options here]
make; make install
If you are receiving something like the following when you try and build...
/bin/sh ../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -rdynamic -lrt -lfix8 -lPocoFoundation -lPocoNet -lPocoUtil -ltbb -ldb_cxx -L../runtime -lmyfix -lz -o f8test myfix.o -ldb
libtool: link: g++ -g -O2 -Wall -rdynamic -o .libs/f8test myfix.o -lrt ./fix8-0.6.6/runtime/.libs/libfix8.so -lcrypt -lPocoFoundation -lPocoNet -lPocoUtil -ltbb -ldb_cxx -L../runtime ./fix8-0.6.6/test/.libs/libmyfix.so -lz -ldb -Wl,-rpath -Wl,/usr/local/lib
/usr/bin/ld: myfix.o: undefined reference to symbol 'pthread_kill@@GLIBC_2.2.5'
/usr/bin/ld: note: 'pthread_kill@@GLIBC_2.2.5' is defined in DSO /usr/lib64/libpthread.so.0 so try adding it to the linker command line
/usr/lib64/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[1]: *** [f8test] Error 1
make[1]: Leaving directory `./fix8-0.6.6/test'
make: *** [all-recursive] Error 1
the cause appears to be some conflict between 32 and 64 bit libraries. To fix, prefix your configure command as follows and then rebuild:
LDFLAGS='-L/lib64 -lpthread' ./configure [your usual options here]

e.g.

LDFLAGS='-L/lib64 -lpthread' ./configure --enable-codectiming --enable-doxygen=no
Configure will by default attempt to locate your gtest installation. gtest recommends that you install this yourself so it is likely you will need to tell confgure where you have gtest installed. Use something like the following switch:
% ./configure --with-gtest=/usr/src/gtest-1.6.0 [your usual options here]
When gtest is found, the test cases will be built.
Depending on your build system, the large generated files used in the fix8 test application f8test can take up to 10 or 15 minutes to compile. If your memory consumption is high but stable, just be patient. There have been a few versions of gcc that did actually lockup when compiling these files. With these cases, gcc eventually consumed all available memory. If memory consumption is running away then we suggest upgrading your compiler. Gcc versions of 4.7 or higher are known to work fine. See item m) below.
Please see this document for details on building on Windows.
By default, the f8test executable and library are built. These are based on the FIX5.0SP2 schema which is very large. On some systems with either low memory and/or older compilers, the build may hang, lock up or even prematurely exit, for example:
mv -f .deps/libmyfix_la-Myfix_types.Tpo .deps/libmyfix_la-Myfix_types.Plo
/bin/sh ../libtool  --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I. -I../include     -g -O2 -Wall -MT libmyfix_la-Myfix_traits.lo -MD -MP -
MF .deps/libmyfix_la-Myfix_traits.Tpo -c -o libmyfix_la-Myfix_traits.lo `test -f 'Myfix_traits.cpp' || echo './'`Myfix_traits.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../include -g -O2 -Wall -MT libmyfix_la-Myfix_traits.lo -MD -MP -MF .deps/libmyfix_la-Myfix_trait
s.Tpo -c Myfix_traits.cpp  -fPIC -DPIC -o .libs/libmyfix_la-Myfix_traits.o
g++: Internal error: Killed (program cc1plus)
Please submit a full bug report.
See <http://bugzilla.redhat.com/bugzilla> for instructions.
make[1]: *** [libmyfix_la-Myfix_traits.lo] Error 1
make[1]: Leaving directory `/home/davidd/fix8-0.9.5/test'
make: *** [all-recursive] Error 1
You can use a workaround to sidestep this issue:
% ./configure --enable-f8test=no [with your options here]
This switch will prevent f8test from being built.
Please review the topics in our Support and Developer and groups. If you can't find any help there post a question. Someone will help you out. If you believe you have found an issue please raise a ticket on our issue tracking site.
If you choose to use FastFlow (the default) and configure your session to use pipelining then you will notice that the pipelined threads will consume a lot of CPU. This is because the concurrent queues provided by FastFlow do not support signalling and do not provide a blocking pop. Fix8 will continually poll queues for input. If no input is available, sched_yield() is called. See Producer-consumer problem for more details. For applications where edge latency is not critical, you can configure Fix8 to insert a small nanosleep to avoid burning CPU. This may lead to slightly slower response times to message events. To use nanosleep here, pass the --with-sleep= with the number of nanoseconds desired. A value of 100-250 is reasonable, e.g.
./configure --with-sleep=100 [your usual options]
If you are using TBB you will not see this problem.
Thread caching malloc (tcmalloc) is an alternative heap allocator that you can use instead of the default allocator. It offers dramatically improved performance. The Fix8 performance tests use tcmalloc. To use, download and install google gperftools. When installed, the Fix8 build will use it if found (must be on your LD_LIBRARY_PATH). You can either link your application directly to tcmalloc, as follows:
% g++ -g -O2 -Wall -rdynamic -lrt -lfix8 -lpthread  -lPocoFoundation -lPocoNet -lPocoUtil -ltcmalloc_minimal -L../runtime -lmyfix -lz  -o hftest hftest.o
Alternatively, you can set the following environment variable before you run your application:
% export LD_PRELOAD=/usr/local/lib/tcmalloc_minimal.so
Assuming you have successfully built the unit test applications (see above), simply run the following command. The test framework will report all failures. If you receive test failures please contact us (either through the support group or via Jira, see Support).
% make check
See the troubleshooting section in the wiki Solving connection synchronisation problems for help with this problem.