From: Uzik <uz...@ze...> - 2003-05-05 04:00:25
|
> The fundamental issues of TCP vs. UDP are very simple, and are only > indirectly related to "reliability". > > TCP delivers all packets, and delivers them in order. This is good > for file transfers and such, because it allows you to stream > directly from a socket to memory to file system without worrying > about data integrity. However, this has it's built-in downside: It > will *only* deliver packets in order, if you are sending packets 1, > 2, 3, 4, and packet 2 doesn't make it, packets 3 and 4 will be held > until packet 2 *does* arrive. For a game system this loss of control and knowledge wouldn't be good. If you are doing raw udp and you don't get packets from the other system you will know you're in a lag situation. You might do something like send a packet every 100 millseconds on a timed basis. You could put whatever stuff needs to be sent into the packet. If you don't hear from the other system in 100 milliseconds you know they got lagged. Now, if you can just figure out something intelligent to DO about lag you will win the big prize! Dropped packets you can deal with, you can just get the status on the next regular update. upd is much better but harder to program. You have to do all the low level work You can also change a bit in the packet header indicating it's a HIGH priority packet. If the networking equipment between you and the other system supports 'quality of service' bit then that packet goes out before the other packets do. You can mark the packet saying "you're being attacked" as high priority and it will go out before the 'regular status update' packets. You can't do that with tcp either. > But in a game, a single dropped packet over a modem connection in a > TCP stream can mean 1-3 seconds of no updates. PL rates as low as > 2-3% can rend er a game based on TCP unplayable (most interstate and > almost all international IP connections have at least that level of > PL). > > UDP datagrams, on the other hand, don't care if the other packets > arrive at all. They won't be held up if the packet ahead of them > didn't arrive. However, because you need to use a small packet (to > avoid fragmentation), you tend to send very discrete datasets in one > packet. This packet has the XYZ, health, and vector for mob X, this > one has the HP levels for your group, and so on. These packets > still need to arrive, random chance could lead to the packets > informing you that you were about to die being dropped 10 times in a > row. > |