UDP implements a simple timeout retransmission

It is well known that ~UDP is a connectionless protocol, so it is unreliable to transmit it, even if the packet is lost. However, in the writing Linux socket program, but can use a simple method, in the application layer to implement timeout retransmission, so that UDP reliable. (The best way to do this is to communicate between two programs--maybe only for two machines.) First ~ I introduce the blocking mode of I/O operation under Linux:

In Linux, I/O operations have four modes, namely, blocking I/O, non-blocking I/O, multiplexing I/O, one-click Signal-driven I/O, this time I need to use blocking I/O. Blocking I/O is the simplest, most common but also the least efficient one. In the default mode, all sockets are blocking mode, that is, when the user calls these functions, the function blocks until an event occurs. The specific event depends on the function, for example: Call read function, because there is no data in the cache, and make read function read blocking; Similarly, it is possible to invoke write functions when write blocking, in addition to the accept function, because there is no client connection server, so that it blocked When the Connect function is invoked, the three handshake does not end, causing it to block and so on. That is, in the absence of a specific event, the function waits for the event to occur, and continues executing the program after the event occurs. Sometimes, for some reason, the function is always in blocking mode (for example: the data loss that the client transmits data to the server with UDP, making the server-side recvfrom function always in blocking mode) This requires calling some functions to stop these functions from blocking, as follows:

1, the use of signals: such as calling the alarm function

2, set the So_rcvtimeo and So_sndtimeo options on the socket, so that the blocking has a time limit

3, time selection through the Select function to achieve

All right, here we go. Blocking I/O I'll talk to you about the relatively reliable udp~

Already said, if using blocking mode, then, when a packet has not reached the destination, then the packet's destination program will be blocked, so can not call the SendTo function to the sender, and the sender at this time in the recvfrom blocked, waiting for the other side of the message.

As has been said before, this is only two communication between the programs, so the two procedures of the life and death of the event, future, fate ... is in the packet on the transmission, if the packet is not up to date (it may be routing problems, line problems, and so on), midway packets are lost, then both sides will always be in a blocking state: the sender block on the recvfrom, waiting for the receiving side to reply; The receiver is blocked on the recvfrom, Wait for the message from the sending end. But the news is not good, preach ... Did the two programs just hang up?

If there are only sendto,recvfrom functions and no time-out mechanism, then ... Just pray for these two programs ... About the two of them would have to hang such a shutdown or be sentenced to death (that is, kill ~) ... However ~ Listen to me below said ~ can solve this problem ~ at the same time, let the application layer above the UDP layer has the ability to repeat the retransmission ~ (Halo ~ I This is not advertising ah ...). ）

Actually see here, we have mostly thought how to deal with this problem: as long as one side exit blocking mode, send a packet, the two programs are liberated ~ How to let a program exit blocking mode ~ actually very simple ~ Yes ~ can use the Alarm function ~ Once to the time to pass a SIGALRM interrupt message to the program ~ Let the program deal with this message, and then stop SIGALRM News, how to deal with love how to deal with ~

/**************** function: Alarm function (you can know without looking) ****************/

#include <unistd.h>

unsigned int alarm (unsigned int seconds);

Function: Returns a SIGALRM message to the calling process after seconds seconds from the call to the function

Parameter: Seconds integer in seconds

/****************************************************************/