在物理断开连接的情况下UDP与TCP

Question

I am currently working on my bachelor thesis in computer science on a project where i need a reliable communication for data transfer from several micro-computers that read sensor-values to another computer that stores the values in a database. The thing is that it will be deployed in a quite rough environment and the possibility of physical loss of connection is substantial.

I have searched for a while about the differences in UDP and TCP but most of the articles and forums talks about the actual reliability in terms of packet-loss and other things but not about the re-connection that could come in this case.

Mostly it looks like TCP would be the correct way for this project since it is a question about reliable communication but I have been thinking about the steps to bind the connection in TCP and UDP and there I would prefer UDP but then having a protocol like DCCP using acknowledgement to make sure that no packets are lost.

I would really appreciate some inputs and also reliable references if possible.

Answer 1

It really depends on how important the data is. If you don't care about the loss of all packets of information during the outage, go UDP. Your life will be easier because you can create a connection (for UDP, this really just means remembering the destination rather than specifying it each time) and blast away without a care in the world.

However, if it is important that all data reach the database, then go TCP and adjust the system's retry timers on the sending machine such that it is longer than any practical network outage. The system will happily keep doing retries until the physical connection returns at which point it will deliver all back-data in a flurry.

From https://drupal.star.bnl.gov/STAR/blog-entry/jeromel/2009/feb/18/tcp-parameters-linux-kernel ...

tcp_retries1 - INTEGER How many times to retry before deciding that something is wrong and it is necessary to report this suspection to network layer. Minimal RFC value is 3, it is default, which corresponds to ~3sec-8min depending on RTO.

tcp_retries2 - INTEGER How may times to retry before killing alive TCP connection. RFC1122 says that the limit should be longer than 100 sec. It is too small number. Default value 15 corresponds to ~13-30min depending on RTO.

Setting these into the hundreds or thousands would effectively retry forever. I didn't see a "maximum retry interval" but it's not as important.

You can do the same on Windows but you don't actually have to if the data is flowing all one way. Why? Because if there is no data to send then there is no data to be lost and retried and thus there is no way to detect that the connection has been interrupted and thus it'll never be considered "broken". As long as keep-alive is is disabled, anyway, and you certainly don't want to go about enabling it for this use-case.

If for some reason you are unable to do this (limited machine control, for example, then you'll have to implement your own protocol over UDP that sends acknowledgements and does retries without ever giving up. There is code for " pseudo tcp " that can do this but it won't be as good as real TCP if you can get that solution to work.

Answer 2

If the data is to important I would definatly use TCP! But on top of that I would also build in a function for the application to determine the connectivity to the server and only send information when the server is reachable. This would also mean making sure to buffer the data which is collected while there is no connectivity.

This would make sure you don't loose data no matter if it's a physical och logical connection issue.

Answer 3

My suggestion is do not use raw TCP or UDP (TCP/IP socket programming) directly. Choose a reliable communication framework and it will handle all the unreliable connection loss issue underneath. For example, if it's on Windows platform, you can choose WCF. HTH.