0

Here's my scenario: In my application i have several processes which communicate with each other using Quickfix which internally use tcp sockets.the flow is like:

Process1 sends quickfix messaage-> process 2 sends quickfix message after processing message from process 1 -> .....->process n

Similarly the acknowledgement messages flow like,

process n->....->process 1

Now, All of these processes except the last process( process n ) are on the same machine. I googled and found that tcp sockets are the slowest of ipc mechanisms.

So, is there a way to transmit and recieve quick fix messages( obviously using their apis) through other ipc mechanisms. If yes, i can then reduce the latency by using that ipc mechanism between all the processes which are on the same machine.

However if i do so, do those mechanisms guarentee the tranmission of complete message like tcp sockets do?

Rampal Chaudhary
  • 707
  • 1
  • 8
  • 18
  • TCP sockets do not guarantee the transmission of complete messages. They guarantee the transmission of byte streams. Your question is therefore meaningless. – user207421 Jan 29 '13 at 07:23
  • @EJP: the main reason is not "guarantee the transmission of complete messages" but speed – Rampal Chaudhary Jan 29 '13 at 11:00
  • So clarify your question. At the moment it is still meaningless. Apart from asking whether other IPC systems exist, to which the answer is obviously 'yes', you haven't asked any question at all except whether other IPC systems share a property with TCP that TCP doesn't even have. – user207421 Jan 29 '13 at 12:47
  • **tcp sockets are slowest of ipc mechanisms** who said that ?? Over a network you need sockets or a system which uses sockets underneath. You cannot escape it. – DumbCoder Jan 30 '13 at 21:41

2 Answers2

0

I think you are doing premature optimization, and I don't think that TCP will be your performance bottleneck. Your local LAN latency will be faster than that of your exterior FIX connection. From experience, I'd expect perf issues to originate in your app's message handling (perhaps due to accidental blocking in OnMessage() callbacks) rather than the IPC stuff going on afterward.

Advice: Write your communication component with an abstraction-layer interface so that later down the line you can swap out TCP for something else (e.g ActiveMQ, ZeroMQ, whatever else you may consider) if you decide you may need it.

Aside from that, just focus on making your system work correctly. Once you are sure teh behavior are correct (hopefully with tests to confirm them), then you can work on performance. Measure your performance before making any optimizations, and then measure again after you make "improvements". Don't trust your gut; get numbers.

Grant Birchmeier
  • 17,809
  • 11
  • 63
  • 98
0

Although it would be good to hear more details about the requirements associated with this question, I'd suggest looking at a shared memory solution. I'm assuming that you are running a server in a colocated facility with the trade matching engine and using high speed, kernel bypass communication for external communications. One of the issues with TCP is the user/kernel space transitions. I'd recommend considering user space shared memory for IPC and use a busy polling technique for synchronization rather than using synchronization mechanisms that might also involve kernel transitions.

Frank Smith
  • 978
  • 5
  • 11