TCP and UDP
The two most popular socket protocols are TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Whether you are using TCP or UDP, if you tell it to send data, it will send it. This is something that does not change between protocols. What does change, though, is how it is sent.
Both TCP and UDP use IP (internet protocol). Currently, it is typically IPv4, but in a few years, it will be IPv6, which is basically the same function, but allows for much larger and more flexible header information. IPv4 is the only protocol (apart from IPv6) used on the internet, and allows you computers to distinguish one from another. All you need to know is that the IPv4 header is 20 bytes, so each packet header is 20 + the size of the protocol's (UDP or TCP) header. More on this is covered in the next section.
TCP
TCP can be thought of the "reliable" but "bulkier" method. When you send a series of packets with TCP, they are guaranteed to get there (as long as the connection between the computers is kept), and along with that, get there in that order. The header for TCP is (at minimum) 20 bytes, which means every TCP packet is 20 + length of data bytes. Designing with TCP is easy since everything happens in the order you tell it to. But because of this, it is also often slower to get the data to its destination. For every packet sent, an ACK, or acknowledgement, must be sent back. For example, if the server sends a packet to the client, the client will send an ACK to the server, telling it that it got the packet successfully. If no ACK is received after 200ms, the packet is sent again.
TCP also handles duplicate packets and ACKs. You don't have to worry about receiving the same packet more than once, or not getting a packet at all. If you tell the socket to send data, it will send the data, and it will get there as you told it to, even if it takes a little longer.
UDP
UDP can be thought of the "unreliable" but "fast" method. If TCP is the postal system, UDP is the "shoot your packet out of a cannon and hope it hits the target". If you send data, it will get there... probably. Theres no ACKs in UDP by default, which means you may not get data, and you may get data out of order. The advantage, though, is just that - theres no ACK. The socket will not wait for an ACK before sending more data - it will just keep dishing it out.
When designing a UDP-based server, you are going to have to go off the assumption that packets will get lost or not come in order. Lets assume your server sends the following data:
1. Create NPC 2. Move NPC to X,Y 3. Make NPC attack in direction D
In TCP, this is no problem, but for UDP, there is a chance that you will not get packet 1 before packet 2 or 3, or even at all. Many times, problems like this are solved by queuing the actions (or dropping them completely), then sending a request to the server for packet 1 again. This obviously becomes quite a hassle to deal with, and a lot of data will be thrown back and forth. But this is the cost of getting the data a lot faster! UDP also only has a header of 8 bytes, and has no ACK packets.
There are many variations of UDP protocols out there, using UDP as a base, but adding features like ACKs, but we will leave them out in this comparison.
TCP vs UDP
So now that we know what each protocol is and how they differ, how do we decide which one is better? First off, there is no best - each protocol is optimal in their own situation. We'll start by breaking down into categories and comparing the two:
Speed: UDP beats TCP hands-down in this. While TCP sits there sending and waiting for ACKs, UDP is just dishing out packets as fast as it can.
Reliabitiy: UDP is no match to TCP in this category. TCP will get every packet, in the order they were sent. UDP doesn't always get packets in the order they were sent, and can loose packets all-together.
Bandwidth: This is a very hard one to judge, especially since UDP packets are often structured different then TCP packets. On a movement packet, in TCP, you would probably send "Character I moves to tile X,Y", while with UDP, it'd be more like "Character I is at X1, Y1 and moves to X2, Y2" because you can not be sure that Character I is at the correct tile to start with. But because of TCP's 20 byte headers in comparison ot UDP's 8 byte headers, and TCP's usage of ACKs in every packet sent, I would put UDP at using less bandwidth. UDP can also request specific parts of a packet that it needs, when it needs it, instead of TCP, which request the whole packet again if it was lost.
Ease of Use: TCP wins, no question about it. This goes hand-in-hand with reliability for the most part. UDP is going to require you assuming any packet can be lost at any time, making you have to design the game to function correctly with some vital data missing.
UDP is commonly associated with FPSes (first person shooters) and sometimes with heavily action-based 3d MMORPGs. The speed is a necessity. Counter-strike would be impossible to play if your information was a half a second delayed. On your screen, it would look like a perfect headshot, but in reality, you could be a good 10 feet off from the target. If you are designing a tile-based 2d ORPG, TCP is almost definitely the way to go. The area of 3d MMORPGs gets very hazy, though, and a lot of it boils down to personal preference. RPGs often require a lot of accuracy in information, even if the information getting there is a bit slower. The big question is, "Are you willing to give up reliability for speed?" Speed is always nice, we all want more of it, but is it worth it for your game?
TCP / UDP hybrids
And just when things were starting to look a bit more "black and white"... TCP/UDP hybrids are just as the name suggests - using both TCP and UDP for information. These are often the best systems, if used correctly. The UDP protocol is used for time-critical packets (movement, attacking, actions, etc) while TCP is used for the packets you want to rely on getting there (chatting, character creating, logging in, buying items, etc). This isn't as easy as it sounds, though. You still have to take into account that the UDP packets can get there before the TCP packets. Your design will still have to be able to support unordered packets, such as moving a character before they are even created. The advantage is, though, if you create a character with TCP and move with UDP, you can guarantee that, even though they may not be created before they move, they will be created and the packet isn't gone for good. These systems require a lot of planning and knowledge on the development. Not only do you have to design the packets, and support for the packets, but you have to decide which packet is handled by which protocol.