How reliable is .NET TCP protocol?

Question

I'm quite new to C# so please bear with me. I'm writing a relatively simple client server application in C# .NET 4.0. I am using TCP protocol, TCPListener and TCPClient to be more specific. I know how does TCP protocol work in theory. But I must be 100% sure that there will be no (unhandled) errors during data transfers.

After I send data how do I know whether data was successfully received. Can I totally rely on the underlying implementation of TCP protocol? So there is no need that I confirm from the other side that data was received?

It is crucial that I truly know which data was sent&successfully received. I know it is a dumb question, but I really want to be sure. Thank you for your time and answers.

Answer 1

With TCP/IP alone, you cannot determine whether any data is received - you would have to layer another protocol on top.

If you can find out if some particular data was received, then TCP/IP guarantees all data before that was also received.

Answer 2

An option would be to use WCF Reliable Sessions over TCP. WCF reliable sessions will mask transport failures.

Answer 3

There is no such thing as the '.NET TCP protocol'. There is just the TCP protocol, which has been running on the Internet for about 30 years. It's reliable. That was a design goal.

Answer 4

If you really need reliability AND network transport, why not use Message Queues? They have transactional guarantee (about as strong as the discipline of the developers working with it, but not stronger than that!)

It's like all your traffic with database-server-type safety (and ditto performance). I think you can easily configure .NET Remoting to use an MSMQ channel.

I've personally never done that, but I've used message queuing in general.

Answer 5

TCP guarantees that:

• Data you send will arrive in the order you send it
• Data you send will be received exactly as you sent it (unmodified)
• No other (spurious) data will be received

It does not guarantee that rodents will not eat your cables, the power to the building will stay on, or even that the process on the other machine you are talking to will bother to do anything when the OS tells it that some data for it has arrived.

If you need a positive acknowledgement that data was received and acted upon, you need to send the acknowledgement back manually (since TCP connections are duplex, you already have a channel to do that).

Of course all of this does is not in any way specific to .NET, Windows, or any other implementation of a network stack.

Update: I 'd like to point out specifically that, after the OS network stack accepts data for transmission, there is no way for you to know that the process at the other end has received that data. The network stack knows in most cases that the data has reached the target (through TCP ACK messages), but it does not know if the OS on the target has fed them to the process they are destined for. So sending back your own "data received and acted upon" message is the only option.