other FIX version

[danice]

An extremely interesting project! Do you plan to also develop other
versions of FIX?

I found a similar project, but hffix looks much better designed.

http://www.codeproject.com/KB/cs/fixprotocol.aspx

It would also be very good add to the documentation some full example
of code with tcp_socket.. to show how to build a simple but fast fix
engine.

Best regards,
daniel

[JDB]

Hi Daniel, thanks! :)

No, I have no plans to develop for other versions of FIX, though such
a thing should be very easy to do. I think the only real requirement
for compatibility with versions 4.3 and 4.4 would be to change the
message_reader and message_writer header to "8=FIX.4.3" or "8=FIX.
4.4". HFFIX is a very minimal parser, and it makes no assumptions
about anything else which I can think of that would break forward
compatibility with versions 4.3 or 4.4.

It would also be nice to add named integer constants for the version
4.3 and 4.4 FIX tags and to add the new FIX tag names to the
tag_name_dictionary, but that's not necessary, it's just for easier
reading of application code. For example, these two expressions are
identical, but the first is easier to read:

writer.push_back_string(hffix::tag::Account, "accountname");
writer.push_back_string(1, "accountname");

The main reason why HFFIX only supports version 4.2 is that all of the
FIX peers we've connected to have been 4.2, so if I supported versions
4.3 and 4.4, I'd have to make a special effort to test versions 4.3
and 4.4.

I'd like to publish a complete TCP socket-based FIX session manager,
but our session manager is too entagled by dependencies on other parts
of our software for me to publish it independently. Our session
manager is built with Boost ASIO, and I strongly recommend Boost ASIO
for doing any socket I/O programming.

[JDB]

> Hello, guys!
>
> Thank you so much for your work!
>
> I have a little question regarding your TCP Example. For me, it's
> seems like this example wont work in case, when i recieve a very long
> FIX message that is longer than IO buffer.
> Can you give me an insight what should I do in this case? Easiest
> solution could be not just moving partial message to the beginning of
> the buffer, but to have some other buffer (std::string maybe, is it
> fast enough?) to store icomptele message and then concatenating this
> buffer with incoming IO buffer and then initializing reader over
> theese two.
>
> What do you think about it? I'm going to use this parser for our HFT
> Arbitrage, so latency is very important for us.

Hi!

Yes, the TCP example, which has a 512 byte buffer, will only work if
all FIX messages are shorter than 512 bytes. In general, the receive
buffer must be longer than the longest possible FIX 4.2 message.

I find that the best solution in production systems is to make the
receive buffer very large. Try using a 64 Kb receive buffer.

char buffer[64 << 10];

Since a typical FIX message is a few hundred bytes and a typical
server has tens of Gbs, 64Kb should be much larger than your largest
possible FIX message, and much smaller than the available memory in
your server. There is no performance penalty for making a large buffer
and then only using a small part of the buffer.

The TCP example uses blocking receive calls in a loop, because it's
simpler. If you're doing asynchronous receives, make sure that your
receive buffer persists for the lifetime of your socket, so that
fragments of TCP packets are stored in between asynchronous receive
calls.

Regards,

James Brock