🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
TCP/IP vs UDP
Author
just how much slower is TCP/IP than UDP?
for an online RPG, is it enough of a difference to matter (if there is not real-time stuff, it is turn-based)?
i can understand wanting the fastest possible data transfer if you are runing around shooting at each other, but when the players just walk around, chat, and use a turn-based menu to chop each other up, is TCP/IP good enough?
--- krez (krezisback@aol.com)
Yes, it''s fine. If you don''t use TCP/IP.. you will have to write some error checking code anyways, so you might as well use what''s given to you if it''s not even "real-time". As long as you aren''t passing over TONS of info, TCP/IP is fine. Also, make sure you find the easiest way to send the information over... so you don''t end up sending more than you need (aka, wasting bandwidth and making the game slower). Like if I do a magic spell on someone, all I have to send them is that I did that spell on them... and (unless you''re using random) their computer can/will generate the same results (if you do use random, you may have to pass some sort of "random seed" over, but nothing more than what is necessary) along with your new coordinates (if you moved), and anything else that has/needs to be updated.
Billy
Billy
TCP/IP is a protocol suite, which includes TCP, UDP, & ICMP among a few others.
The issue with TCP is that every packet is garuanteed delivery and garuanteed order. So if one packet is dropped you have wait for that packet to be received before you receive _any more data.
TCP is designed to drop packets. It increases the rate of transmission until a packet is dropped, then backs off, etc... That way it uses as much bandwidth as it can.
For a game with few events that need to be sent over the wire (i.e. nnon-realtime) tcp would work fine.
Magmai Kai Holmlor
- Not For Rent
The issue with TCP is that every packet is garuanteed delivery and garuanteed order. So if one packet is dropped you have wait for that packet to be received before you receive _any more data.
TCP is designed to drop packets. It increases the rate of transmission until a packet is dropped, then backs off, etc... That way it uses as much bandwidth as it can.
For a game with few events that need to be sent over the wire (i.e. nnon-realtime) tcp would work fine.
Magmai Kai Holmlor
- Not For Rent
I''m reading a book for an exam on computer networks (Larry L. Peterson & Bruce S. Davie: Computer Networks A System Approach).
I caught an interesting table there.
The test was done sending messages back and froth between two machines 10000 times. result is (endtime - starttime)/10000.
What do we learn?
Use as small message sizes as possible. Instead of one big message send multiple smaller. You get smaller latencies and higher throughput.
Using UDP over TCP gives smaller latencies.
Correct me if I misunderstand it :-D
I caught an interesting table there.
Measuren round-trip latencies (micro-seconds) for various message sizes and protocols:Bytes UDP TCP 1 279 365 100 413 519 200 572 691 500 1067 11851000 1878 2015 The test was done sending messages back and froth between two machines 10000 times. result is (endtime - starttime)/10000.
Another diagram shows throughput usin ugp.KBytes Throughtput (Mbps) 1 8.6 2 8.8 4 9.2 8 9.4 What do we learn?
Use as small message sizes as possible. Instead of one big message send multiple smaller. You get smaller latencies and higher throughput.
Using UDP over TCP gives smaller latencies.
Correct me if I misunderstand it :-D
Much like a real audio broadcast a MMORPG server is constantly streaming information to its clients. People trying to stream audio and video across the internet discovered very quickly that The enforcing gaurenteed in order delivery would very rapidly break up an audio feed.
If one packet in the tcp stream was to be lost all would have to be re-transmitted again to ensure in order delivery. This could cause large pauses in the stream and then everything would have to play very quickly to get caught up.
With UDP they found that if they sent small packets, then when a packet was lost only a small amout of aduio was lost and it was hardly noticible to the listeners. This was much prefered to large pauses and then rapid catching up.
That said, if you choose to use UDP you will want to implement some sort of class that will resend udp packets until it get''s an ack from the clients. This is because ( unless your really clever like carmack ) you''ll want to be able to send some packets and know they''ll get there.
If one packet in the tcp stream was to be lost all would have to be re-transmitted again to ensure in order delivery. This could cause large pauses in the stream and then everything would have to play very quickly to get caught up.
With UDP they found that if they sent small packets, then when a packet was lost only a small amout of aduio was lost and it was hardly noticible to the listeners. This was much prefered to large pauses and then rapid catching up.
That said, if you choose to use UDP you will want to implement some sort of class that will resend udp packets until it get''s an ack from the clients. This is because ( unless your really clever like carmack ) you''ll want to be able to send some packets and know they''ll get there.
and what did carmack do?
also you can use UDP in a connected fashion like TCP, its in the API somewhere
also you can use UDP in a connected fashion like TCP, its in the API somewhere
quote: Original post by Magmai Kai Holmlor
TCP/IP is a protocol suite, which includes TCP, UDP, & ICMP among a few others.
No, TCP/IP is the implementation of the TCP protocol over the IP protocol. UDP is usually UDP/IP, and is UDP over IP.
We explicitly say TCP/IP because you can (and some have) implement TCP other a protocol other than IP.
If a system supports TCP/IP, it does _not_ follow that it also supports UDP or ICMP.
Magmai is actually right here. The protocol suite for the internet is collectively known as TCP\IP, even though it also includes UDP and ICMP (reference: Computer Networking - A Top-Down Approach Featuring the Internet).
One could of course use the word to differentiate between different internet protocols, it all depends on the context.
Henry
One could of course use the word to differentiate between different internet protocols, it all depends on the context.
Henry
Hang on though, it might be a suite but TCP resides at a different layer than IP. TCP sits at the transport level and manages connections, error checking, retransmissions etc. IP sits at the network level and doesn't manage any of that. It just defines the addressing scheme, routing etc. UDP is also at the transport level but doesn't define any method for maintaining connections, error checking or retransmission.
A few common reasons UDP is typically faster than TCP because:
1. TCP retransmits packets when it doesn't receive an ACK (gross generalization) or if there is an error in the transmission.
2. TCP has a much larger header.
3. Some ISPs tend to optimize there routers for UDP traffic (go figure.)
I think Magmai is right about saying the "TCP/IP protocol suite " but it is misleading...
Dire Wolf
www.digitalfiends.com
Edited by - Dire.Wolf on November 7, 2001 3:07:47 PM
Edited by - Dire.Wolf on November 7, 2001 3:08:24 PM
A few common reasons UDP is typically faster than TCP because:
1. TCP retransmits packets when it doesn't receive an ACK (gross generalization) or if there is an error in the transmission.
2. TCP has a much larger header.
3. Some ISPs tend to optimize there routers for UDP traffic (go figure.)
I think Magmai is right about saying the "TCP/IP protocol suite " but it is misleading...
Dire Wolf
www.digitalfiends.com
Edited by - Dire.Wolf on November 7, 2001 3:07:47 PM
Edited by - Dire.Wolf on November 7, 2001 3:08:24 PM
Dire.Wolf: You forgot the most important reason UDP is faster (although, did touch on it). The client has to sent acknowledgements. With UDP, it does *have* to send an Ack (although, you can write it so it does this).
stefu: The reason it takes longer for larger packets is.. well, because the package that is being sent is larger. If i''m reading your first graph properly... if you sent 1 byte 100 times, it''d take longer than sending 1 100 byte package, simply because the 100 byte pacakge needs 1 header, while the 1 byte package needs 100 headers (which is A LOT of overhead). The less packet losses you have, the more efficient larger packets become (ever notice how all the "cable modem optomizers" increase your packet sizes). The more packet losses, the less efficient larger packets become. (IF I read what you were saying wrong, sorry :D)
Billy
stefu: The reason it takes longer for larger packets is.. well, because the package that is being sent is larger. If i''m reading your first graph properly... if you sent 1 byte 100 times, it''d take longer than sending 1 100 byte package, simply because the 100 byte pacakge needs 1 header, while the 1 byte package needs 100 headers (which is A LOT of overhead). The less packet losses you have, the more efficient larger packets become (ever notice how all the "cable modem optomizers" increase your packet sizes). The more packet losses, the less efficient larger packets become. (IF I read what you were saying wrong, sorry :D)
Billy
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
