Im planning to write entire game (both server and client) in C#, so I'll be using System.Net.Sockets bundled with .NET.
I've managed to sucessfully write MUD game using TCP/IP so I have a little experience with it, and I don't know what are advantages of UDP over TCP.
I have read that UDP is usually used to send entire game state to the client. But when I think about sending whole game state - only thing that comes to my mind is - send the whole screen to client.
Simple calculations make things clear - this is not the way to do it:
1 char per tile and two colours (background and foreground) - 7 bytes per tile. Having gamescreen like 80x40 its 22400 bytes = 21,875 KB.
If I would refresh screen only once per second it's still way too much.
Obvious solution is sending only the things that can change (monsters and items), and that is not necessairly the best way - almost amount of data, X,Y,CHAR,R,G,B = 6 bytes.
When entering shop that is full of items, or big town - player gets the same amount of data.
Okay, we don't send things that aren't in FOV: depending on radius its more or less acceptable: R=10, we get around 314 tiles. Each tile is minimum 7 bytes, since we have both BG and FG colors + character byte and that's 2198 bytes max.
From what I understand - sending this constantly is a must in UDP, since you are not sure if datagram reached it's destination.
From my understanding what is written in Wikipedia (http://en.wikipedia.org/wiki/Transmission_Control_Protocol
UDP adds 32 bytes overhead per packet.
TCP adds 128 bytes overhead (minimum) per packed, and it has 3-way handshake, so it is actually 384 bytes per packet (or did i messed sth up?)
Even if it is 384 bytes. Sending packet with 384 bytes overhead each time when something moves is better than constant sending 2KB+.
Am I right?