Can someone explain to me how UDP works with games? Like starcraft? if one packet is lost.. coordinates will dissapear?

The game that uses UDP has to deal with packet loss; detect lost packets and re-send whatever data is necessary.

Mupp:

UDP is appropriate for certain types of data. For example, in a first person shooter where there are typically dozens of people connected to a game server, each playere needs to know the positions and movements of all the other players that are currently visible from their perspective viewpoint. The positions of these characters are transmitted several times per second, so that you can determine the positions of the characters as they move around. UDP is an acceptable transport protocol for this purpose because:
a)UDP has lower latency then than TCP/IP
b)You dont care if you drop a few packets, because you are getting so many per second that a few lost packets shouldnt affect the performance of the simulation drastically.


Here is a brief comparison between the properties of TCP/IP and UDP

TCP/IP
-------
*guaranteed delivery of your data. All of your packets are guaranteed to arrive, assuming you dont unplug a network cable or experience a network outage.

*messages are delivered in order. Since TCP/IP use a connection stream and has a single path that data travels down your messages will arrive in order (the 1st packet you send will be the first packet recieved, 2nd packet sent will be 2nd packet received, etc)


UDP
-------
*no guarantee of data delivery. Some of your data can (and will) get lost in being routed through the internet.

*data arrives out of order. UDP is known as a connectionless protocol, meaning each message you send is independent. Since each message is independant there is no established route for sending messages from one location toanother. Consequently, your messages will not arrive in the same order you send them, because some packets will travel down faster routes than other ones. If you intend to use this protocol for data transfer that depends on ordering, you need to build control on top of this protocol at the application level to ensure you discard stale messages (for example if you receive packet 6, then later you receive packet 2, you need to write your application such that it is smart enough to look at the data and recognize that packet 2 is older than packet 6, so discard it)


So in summary the difference is if you need low latency transport without much overhead go with UDP for sending information you dont care about losing. (dont bother trying to implement a mechanism to resend UDP data if it doesnt get received; a lot of people do this and there implementation is less efficient than if they just used tcp to begin with)

If you need guaranteed delivery of information, use tcp (typically when you log on to a server, perform authentication, etc this is done via tcp/ip)

hope this helps,

neko

Greets! I would like to learn more about network programming because I am a total n00b. Would someone be so kind as to post the location some good online tuts on the subject (for c/c++)? Thank you kindly.

Google for Beej.

Good overview nekoflux... Just a few things that I feel like clearing up and/or being picky about

1st...
The reason that UDP will usually have a lower latency than TCP is that with UDP, there is no ARQ (Automatic Repeat reQuest). ARQ is TCP''s method of assuring that all data transmitted gets to the network endpoint (the other computer). If data is missing, it times out, and resends the missing data.

Under normal conditions on a lossless network (NOT the Internet!), TCP and UDP will have extremely similar latencies. TCP''s packets are a bit larger, so that might affect things a little...

TCP is a problem for realtime games for 2 reasons...
- It has to time out before requesting a resend
- TCP is rate controlled (it does not send as fast as possible, but as fast is as "good" for the network). When a packet is lost, TCP will cut the sending rate in 1/2. It will then build back up if network conditions improve.

UDP on the other hand does not guarantee packet delivery nor is it rate controlled.

2nd...
The full name of TCP is "TCP" - not "TCP/IP". TCP/IP is actually 2 protocols (a transport layer protocol (TCP) and a network layer protocol (IP)). So, if you''re going to say TCP/IP, you might as well say UDP/IP too... Except nobody says that, so just say TCP

(If you''re not running your own network, you could theoretically run TCP over a different network-layer-protocol. But over the Internet, you''re stuck with IP since it is the Internet Protocol

Sorry about being overly picky
Mark

You want picky?

"The reason that UDP will usually have a lower latency than TCP is that with UDP, there is no ARQ"

That''s not entirely correct. You can have automatic resends and correction in a protocol, without incurring additional latency. The reason TCP _MUST_ induce latency when packet loss happens, is that it guarantees to deliver the data stream IN ORDER. Thus, no packets arriving can be delivered before the lost packet is re-transmitted, which will often take at least a 3 second time-out.

If you remove the "in order" requirement, but keep all the other requirements intact (deliver each message exactly once), you can build a high-performance, low-latency network protocol, that uses automatic re-transmission.