TCP Reliablility

[mmiers]

My sincere apologies if this is a repeat post but the search limitations on < 4 char words makes it difficult. Also, forgive the length, I want to make sure I ask the question correctly the first time.

Anyway, my questions is this. I know a lot about networking as Ive taken many cisco classes and have made several net apps. I know it is designed to be very reliable and efficient. It uses windows and confirmations to make sure every thing has been received.

However, Ive heard many times from many resources that TCP isnt 100% guaranteed. Packets are not always received in order, are often strung together or are not received at all. Now thats only what Ive heard. Ive made a few networking apps back in VB6 using winsock and never had these problems, however, that was on a very stable connection and sending very small packages.

Now I want to move onto something a bit better. Im trying to develop a low-level socket class that offers very efficient and near perfect transfers of data, no matter the size. I want to be sure that all packets are received if its a file of several gigabytes, but also act very fast if there are many small packets coming from different connections.

To sum up all of that into a simple question. Should I take the time to implement a more guaranteed transfer using packet ids, lengths, crc, all of that (basically thats a whole different protocol!), or should I trust that tcp will get me all of the information? If the former is the case and to be sure id have to make my own custom protocol, couldnt i just use UDP and put that protocol over top of it?

I know there is probably no way to guarantee 100% of the time all data will make it perfectly, but > 95% is good to me.


Thanks
- Mark

 

[a_jam_sandwich]

The hole idea of TCP is there is a constant conection between the server and the client so packet loss cannot happen

e.g.

Start
1. Server sends data
2. Client recieves data
3. Client sends reponse
4. Server reads response
5. Server send next chunk of data
End (Repeat until all data sent)

As long as the connect between the server and the client using TCP exists 99.99% will be sucessfull.

NOTE : If there is an error within the data sent your client will re request the packet same happens if packet is never received.


UTP is the unreliable one (Like your example) no guarantee the data will get to the client and the client doent bother checking.

Andy

 

[Divil]

I wouldnt bother writing that class. .NET already provides a (optionally) very low level socket class that should be ample for your needs.

TCP/IP _does_ guarantee that your packets will arrive, and in the right order too. The only thing it doesnt guarantee is that they wont be broken up or stuck together, but the data will arrive correctly. Of course, its up to the programmer to use delimiters if its necessary to distinguish from one packet to the next.

 

[mmiers]

Thank you for your replies.

Im well aware of the TcpClient class. But working directly with the sockets offers me more control in thinks such as encryption, security and all that. Its nice to know exactly how my data is being handled.

Again thanks a lot.

- Mark