Introduction

I needed some C# fix protocol engine code and was disappointed that there is almost nothing on the internet, so here is a small project in VS 2005. It actually connects to EBS AI v4 fix which is a major foreign exchange trading platform. Fix servers are usually huge projects but there is a simple way to cut them down to nothing - do not support message retransmission. In fact EBS, along with many others, does not support message retransmission either because it is pointless for today's 100% reliable socket communication. Using this technique, you can avoid paying for a fix engine or fighting with QuickFix and it will be much faster as well. This code is for connecting to a big reliable platform, not for connecting to customers who might send you junk.

Points of Interest

Some people process fix messages by splitting the received bytes into a vector of string pairs or even a vector of maps - but this is pointlessly slow! Instead I pass simply the start and end location of the fix message in the buffer and provide a few functions such as ReadKey(), ReadStringValue(), ReadIntegerValue(), SkipValue(), etc. The ProcessMessage code can then more quickly process the fields as desired. Usually the order of the data is constant, but if it is not use a loop and case. Repeating blocks will always have some field marking the start of a new block. When I am reading the integer key, I use a loop that subtracts 48 from the char value and multiples by 10 etc. rather than just calling convert to string and Convert.Int32(..). In other words, I have taken care to keep it all mostly as fast as possible.

Normally a class like this would have an interface with various events but again this is just sample code so I am not including this stuff. I am using a synchronous or blocking socket read instead of asynchronous events. This is slightly faster for a single connection example like this which only consumes one thread. With debug on, I log to a simple StreamWriter. Of course any logging should actually take place in a proper logging class with a queue and intermittent writing thread (always to the local drive, keep network traffic to a minimum), but I have not bothered including code for that in here. Note you don't need to waste time logging fix except in debug mode - in the event of a problem you can always get the monster log file from your vendor anyway.

Processing the fix messages in this code takes just a few microseconds but how fast are sockets in .NET? I wrote some test code that sends messages between a server and a client server running on the same machine in C#, C++ and Linux C++. I used RTDSC to time the server send to client receive interval. For messages up to about 1.5k bytes in size, I got a pretty steady time of 70 microseconds in C#. In Windows C++, this came down to 45 microseconds. Rewriting all this in Linux C++ gave 25 microseconds. This performance hit compared to Linux C++ is probably OK for most people.

I am thinking that this codes is very unelegent and is looking very slowly. Can you tell me please what the slowness figures you have recieved from testing this codes. I am sure that my company would not use such slow codes as this. Did you yourself consider the options of using codes such as quickfix?

Thank you very kindly for your rich compliments, I am glad that you are agreeing with me. If you are needing any help with your codes to improve the slowness issues, this is something I can give you much help with. I hope that you would not use some codes such as these in a live running situation because codes such as these would be doomed to failure.

Retard I am not "agreeing with you". Nor am I going to give you a job so you can "help with my codes". Nor will anyone else who reads this thread, you are making a complete fool of yourself, why don't you bugger off you stupid half wit!

I am thinking that you yourself have very greater problems than your poor ability to program. You yourself also have very great phsycological problems. My advice to you yourself is to find a proper programmer who can help with your slowly and unelegent codes, and to find a phsycologist to help you with your slowly and unelegent mind.

I will no longer offer to help you with your codes because I do not work with mentally disturbed like you yourself.

I agree with Hooper. At least appreciate the fact he has taken some pain to develop and post it. If you reckon this is not good enough please post your version of the refactored code so we can all get enlightened. If you can't, appreciate and move on with life.

Yes that's true. but tcpip messages are not erroneus/corrupted. the point of this code is to be fast - eg i do not verify the checksum. in fact i don't even bother to check the incoming message sequence number. i just have two safety checks in the code which check the message starts 8= and then 35=.