Out of order data in TCP

Question

I've an application that's using Apache mina library for communicating based on TCP. The apache mina library provides a callback with IOBuffer that contains data coming over the network, however often times the data is received out of order or redundantly. I skimmed through the TCP protocol and it says that the protocol always ensures delivery of the data in correct order. The company that provided the APIs for their server claim that they are using TCP/IP for sending the response back however before sending the response back their server doesn't care about confirming if the client (in this case my application/apache mina library) is connected to the server. So the server just fires off the message and moves on.

If I'm not mistaken, that's the UDP protocol's behavior. My question is, if the server is using TCP for sending the response back:

1. Why do I get out of order data (it's rare but happens one in a while)?
2. How can a machine that's using TCP protocol just fire and forget about the data without making sure the receiver device is connected to it before sending the data?
3. Is this really TCP or UDP or some variation of TCP protocol?

Answer 1

Apache Mina does asynchronous messaging over the top of various transports including TCP.

Since Mina is asynchronous, out-of-order delivery should be expected.

Why do I get out of order data (it's rare but happens one in a while)?

One possible explanation is that multiple TCP streams are being used. Data delivered using one TCP stream will be delivered in order, but if multiple streams are used, data in one stream could "overtake" data on another stream, in the TCP stacks on the sending or receiving end, on the network, or in the client side library.

How can a machine that's using TCP protocol just fire and forget about the data without making sure the receiver device is connected to it before sending the data?

Because ... reliable delivery is not a basic attribute of Mina.

If you are using Mina to talk to a service with a particular application protocol, then that protocol will determine will determine whether "sending the data before checking the receiver is connected" is allowed / will work or not. For example, it won't for an HTTP response, because an HTTP response is sent on a connection that was previously established to send the request.

Actually, it seems that there are a variety of ways to use Mina. Some involve an application protocol; eg see HttpClientCodec and HttpServerCodec . Others don't.

Is this really TCP or UDP or some variation of TCP protocol?

If they say that TCP is being used as transport, then it is. However, Mina is neither TCP or UDP. It is Mina. It hides the details of the transport.

---

Bottom line, if you want the reliability / in-order delivery properties of TCP/IP, you should probably use them directly. Mina is providing higher performance than conventional TCP/IP over a synchronous socket by relaxing the normal properties of a (single) stream-based transport.