Bypassing the TCP-IP stack

I realise this is a somewhat open ended question...

In the context of low latency applications I've heard references to by-passing the TCP-IP stack.

What does this really mean and assuming you have two processes开发者_JS百科 on a network that need to exchange messages what are the various options (and associated trade-offs) for doing so?

Typically the first steps are using a TCP offload engine, ToE, or a user-space TCP/IP stack such as OpenOnload.

Completely skipping TCP/IP means usually looking at InfiniBand and using RDMA verbs or even implementing custom protocols above raw Ethernet.

Generally you have latency due to using anything in the kernel and so user-space mechanisms are ideal, and then the TCP/IP stack is an overhead itself consider all of the layers and the complexity that in can be arranged: IP families, sub-networking, VLANs, IPSEC, etc.

This is not a direct answer to your question but i thought it might give you another view on this topic.

Before trying to bypass TCP-IP stack I would suggest researching proven real-time communication middleware.

One good solution for real-time communication is Data Distribution Service from OMG (Object Management Group)

DDS offers 12 or so quality attributes and has bindings for various languages.

It has LATENCY_BUDGET ,TRANSPORT_PRIORITY and many other quality of service attributes that makes data distribution very easy and fast.

Check out an implementation of DDS standard by PrismTech. It is called OpenSplice and works well at LAN scale.

Depends on the nature of your protocol really.

If by low-latency applications you mean electronic trading systems, than they normally use IP or UDP multi-cast for market data, such as Pragmatic General Multicast. Mostly because there is one sender and many receivers of the data, so that using TCP would require sending copies of the data to each recipient individually requiring more bandwidth and increasing the latency.

Trading connections traditionally use TCP with application-level heartbeats because the connection needs to be reliable and connection loss must be detected promptly.