What is UDP?

Unlike TCP/IP, UDP/IP provides very few error recovery services, offering instead a direct way to send and receive datagrams over an IP network. It's used primarily for broadcasting messages over a network.

UDP stands for User Datagram Protocol. It is described in STD-6/RFC-768 and provides a connectionless host-to-host communication path. UDP has minimal overhead:; each packet on the network is composed of a small header and user data. It is called a UDP datagram.

UDP preserves datagram boundaries between the sender and the receiver. It means that the receiver socket will receive an OnDataAvailable event for each datagram sent and the Receive method will return a complete datagram for each call. If the buffer is too small, the datagram will be truncated. If the buffer is too large, only one datagram is returned, the remaining buffer space is not touched.

UDP is connectionless. It means that a datagram can be sent at any moment without prior advertising, negotiation or preparation. Just send the datagram and hope the receiver is able to handle it.

UDP is an unreliable protocol. There is absolutely no guarantee that the datagram will be delivered to the destination host. But to be honest, the failure rate is very low on the Internet and nearly null on a LAN unless the bandwidth is full.

Not only the datagram can be undelivered, but it can be delivered in an incorrect order. It means you can receive a packet before another one, even if the second has been sent before the first you just received. You can also receive the same packet twice.

Your application must be prepared to handle all those situations: missing datagram, duplicate datagram or datagram in the incorrect order. You must program error detection and correction. For example, if you need to transfer some file, you'd better set up a kind of zmodem protocol.

The main advantages for UDP are that datagram boundaries are respected, you can broadcast, and it is fast.

The main disadvantage is unreliability and therefore complicated to program at the application level.

TCP and UDP use the same addressing scheme. An IP address (32 bits number, always written as four 8-bit number expressed as unsigned 3-digit decimal numbers separated by dots such as 193.174.25.26) and a port number (a 16-bit number expressed as a unsigned decimal number).

The IP address is used by the low-level protocol (IP) to route the datagram to the correct host on the specified network. Then the port number is used to route the datagram to the correct host process (a program on the host).

For a given protocol (TCP or UDP), a single host process can exist at a time to receive data sent to the given port. Usually one port is dedicated to one process.

· it doesn't restrict you to a connection based communication model, so startup latency in distributed applications is much lower, as is operating system overhead.

· all flow control, acking, transaction logging, etc is up to user programs; a broken os implementation is not going to get in your way. additionally, you only need to implement and use the features you need.

· the recipient of udp packets gets them unmangled, including block boundaries.

· broadcast and multicast transmission are available with udp.

· there are no guarantees with udp. a packet may not be delivered, or delivered twice, or delivered out of order; you get no indication of this unless the listening program at the other end decides to say something. tcp is really working in the same environment; you get roughly the same services from ip and udp. however, tcp makes up for it fairly well, and in a standardized manner.

· udp has no flow control. implementation is the duty of user programs.

· routers are quite careless with udp. they never retransmit it if it collides, and it seems to be the first thing dropped when a router is short on memory. udp suffers from worse packet loss than tcp.