UDP Errors UDP errors are a little unusual because they can occur asynchronously. Consider what happens when you use send() to transmit a UDP datagram to aremote host that has no program listening on the specified port. With TCP, you would get a "connection refused " ( ECONNREFUSED ) error on the call to connect() . Similarly, a problem at the remote end, such as the server going down, will be reported synchronously the next time you read or write to the socket. UDP is different. The return value from send() tells you nothing about whether the message was delivered at the remote end, because send() simply returns true if the message is successfully queued by the operating system. In the event that no server is listening at the other end and you go on to call recv() , the call blocks forever, because no reply from the host is forthcoming. [1] [1] Of course, this could also happen if either your request or the server's response is lost in transit. Asynchronous Errors There is, however, a way to recover some information on UDP communications errors. If a UDP socket has been connected, it is possible to receive asynchronous errors . These are errors that occur at some point after sending a datagram, and include ECONNREFUSED errors, host unreachable messages from routers, and other problems. Asynchronous errors are not detected by send() , because this always reports success if the datagram was successfully queued. Instead, after an asynchronous error occurs, the next call to recv() returns an undef value and sets $! to the appropriate error message. It is also possible to recover and clear the asynchronous error by calling getsockopt() with the SO_ERROR command. You may also use select() on a UDP socket to determine whether an asynchronous error is available. The socket will appear to be readable, and recv() will not block. The implementation of UDP on Linux systems differs somewhat from this description. On such systems, asynchronous errors are always returned regardless of whether or not a socket is connected. In addition, if the network is sufficiently fast, it is sometimes possible for send() to detect and report datagram delivery errors as well. Dropped Packets and Fragmentation The most common UDP errors are not easily detected. As described in Chapter 3, UDP messages can be lost in transit or arrive in a different order from that in which they were sent. Because there is no flow control in the UDP protocol and each host has only finite buffer space for received datagrams, if a host receives datagrams faster than the application can read them, then excess datagrams will be dropped silently. Although datagrams can, in theory, be as large as 65,535 bytes, in practice the size is limited by the maximum transmission unit (MTU) of the network media. Beyond this size , the datagram will be fragmented into multiple pieces, and the receiving operating system will try to reassemble it. If any of the pieces were lost in transmission, then the whole datagram is discarded. On Ethernet networks, the MTU is 1,500 bytes. However, some of the links that a datagram may traverse across the Internet may use an MTU as small as 576 bytes. For this reason, it's best to keep UDP messages smaller than this limit. Provided that a datagram is received at all, its contents are guaranteed by a checksum that the TCP/IP protocol places on each packet ”that is, if the application hasn't deliberately turned off the UDP checksum. | 
