I've written an answer to the question "what's the difference between UDP and TCP" a few times now, so I figured I'd put it here.
With UDP, you send a packet (with a size) with sendto() from one side, and it'll be received using recvfrom() on the other side; each packet is distinct and has a length; it's not a stream like TCP is. UDP is "packet based". This is usually a plus.
With UDP, there is no GUARANTEE that the packet will make it, and you can't tell after calling sendto() whether it made it or not. However, 99% of all packets will make it. In practice, this is distributed such that usually, 100% of the packets make it, and 10% of the time, 90% of the packets make it. UDP is "unreliable". This is usually a minus.
With UDP there is no GUARANTEE that when sending packet A and then packet B to a client, the client will see first packet A and then packet B. It may see first B then A. Or not A at all. Or not B at all. Or neither. UDP is "unordered". This is usually a minus.
With UDP, there is no GURANTEE that you'll see the same packet only once. You may send A once, but you'll receive A twice, or three times (or zero times) on the other end. However, packet duplication is very uncommon. UDP is "not guaranteed unique". This is usually a minus.
With UDP, you can use the same socket/port to sendto() and recvfrom() any number of other machines, because the address to send to is specified each time you call sendto(). UDP is "connectionless". This is usually a plus.
With TCP, if you drop a packet, but the next packet makes it through, the kernel will withhold that packet until the earlier packet can be re-sent. This is because TCP is a guaranteed, in-order, stream protocol. This means that "fresh" data will sit in the kernel, becoming "stale," while you're waiting for the TCP time-out and re-transmit, which is a minimum of 3 seconds for a lost packet. This is why UDP is usually better for games, voice conferencing, and other low-latency applications. This is usually a (big) plus for UDP.