Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

hello2k1

TCP vs UDP vs TCP & UDP?

This topic is 5790 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Our team is now working on implementing the network code (or planning it out at least), and we can''t seem to agree on which protocol to use. The game is client/server, and requires a large amount of packets to be sent. Now, my partener wants to use UDP and TCP for gameplay, using TCP for urgent packets. But, I would like to use UDP, but make it secure enough to handle urgent packets, and constructing it to conform to a "custom protocol". My partener argues that using UDP and TCP would be better because the TCP is handled at the OS level. I, on the other hand believe that having to handle 2 different sockets/user would kill cycles. What do you guys suggest? Thanks for the input.

Share this post


Link to post
Share on other sites
Advertisement
TCP does a lot more than just gaurantee delivery. If that''s all you need (and even if you also need correct ordering) then just write that over UDP.

Since TCP does a lot more than just packet ordering and gauranteed delivery, writing that stuff on top of UDP could well be faster (if done right, of course).


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
Putting it all under UDP is good solution. You''ll need to implement some reliability, as you seem to know already. You could use TCP for the guaranteed delivery, but it''s not necessary.

Good luck.

Share this post


Link to post
Share on other sites
Your buddies way is the better way since both protocols have thier advantages. It will take a little more time to program, but in the long run it will be better. UDP only network layers usually miss some key advantages of TCP. Any they advantages handled at the network layer on routers so you can't just program them in.

Use both, it's best. Somtimes you can only use TCP due to firewalls. Sometimes the connection is bad so UDp is best. They both have advantages that the other can not make up for.

Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

[edited by - smanches on July 30, 2002 6:16:17 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by smanches
They both have advantages that the other can not make up for.



This is true, but the advantages of one are in a different realm to where the other is applied. TCP is good for streamed data where the speed of the connection can vary quite a bit, and immediate response time is not as important as overall throughput. It''s no good for packets of data where you''re only sending sporadic things (because the various algorithms it uses don''t have enough data to work properly), and when immediate response time is the most important factor.

UDP is good in the situation where you have small packets of data, sent fairly sporadically, and only a few actully have to make it to the other end. For those few, it''s very easy to write your own gauranteed algorithm. It''s also quite easy to write your own packet ordering agorithm. I''ve never seen a game-situation where you needed more than those two things. A TCP connection does a lot more than that, which is why it''s usually slower.

And the firewall argument is usally moot because it''s quite simple to use the SOCKS protocol to get the firewall to automatically open up a port for your UDP game anyway.

If I had my way, I''d have all of you shot!


codeka.com - Just click it.

Share this post


Link to post
Share on other sites
quote:
Original post by smanches
UDP only network layers usually miss some key advantages of TCP. Any they advantages handled at the network layer on routers so you can''t just program them in.


Hey smanches, could you elaborate on this? If there''s a huge gaping hole in my networking skills, it is in the area of high-end hardware - maybe I''m missing something. I know some load balancing switches work only with TCP, but I''m not sure that all of them are that restrictive. The firewall/NAT argument over UDP isn''t really as big a deal as people make of it. Most firewalls will forward ports that are opened from the inside (or can be set up to do so).

Unless you are doing bulk transfers (i.e. sending files), I would still say you don''t need TCP. If you want to manage the per-connection sockets, go ahead. It won''t kill you if it''s there, but you can get along without it just fine. Like anything else, do a cost-benefit analysis and determine which method is best for your specific project.

Share this post


Link to post
Share on other sites
i never had trouble with UDP through a NAT (linux) when the app is written correctly. you dont even need any special configuration of the NAT assuming that the ports are open (no need for static port forwarding). i have even had multiple UDP quake games running behind a NAT connected to the same server.

you can view the quake or quake2 source code to see if they do anything special (i doubt it since they dont really know about the firewall, nor is their a config to tell them).

Share this post


Link to post
Share on other sites
If you need the features of UDP then its best to just use UDP for everything. You only need 1 UDP socket on the server to handle all the clients.

However, if you use TCP then there will be 1 socket per client plus the single UDP socket.

Using only UDP will mean lower server overhead and better bandwidth utilisation, if implemented correctly.

[edited by - Ixpah on July 31, 2002 6:59:33 AM]

Share this post


Link to post
Share on other sites
You have to realize too that the USA, on average, has better and newer equipment than some other contries, especially in Asia. Some of their stuff can get quite old and the older firewalls/proxies/NAT devices just don't let UDP through right. It is a small argument, but if you want the most customers possible, then it's valid. UO found that having TCP in the network layer was able to increase thier subscription rate, if slightly. Some people just don't have the technology we do. All those algorithms that can slow down response in TCP can be turned off, so thats not a valid argument either. TCP is no slower than UDP when written properly, period. Don't argue that any more.

The newer routers and software are looking higher up on the protocol layer chart. Some are now at the application level so they can guarantee http requests while holding email for a lower QOS. They have been doing this at the netowrk layer for some time now. When you ask for QOS, you ask for a partiular connection. Since UDP is connectionless, it's much harder to give QOS to it, TCP is the main protocol useed on the network layer. QOS will be one of the next big features of a game network layer in the future. Just imagine your premium customers having a dedicated 2k per seccond QOS pipe directly to them. Yep, no more lag or dropped packets. :-)

You should, and most people do, use UDP for everything. I'm saying use both so you can catch that one person that can't route UDP packets. TCP will become more valuable in the very near future with the implementation of QOS accross the internet. Don't sell yourself short because you are only looking at a few differences.

Stephen Manchester
Senior Technical Lead
Virtual Media Vision, Inc.
stephen@virtualmediavision.com
(310) 930-7349

[edited by - smanches on July 31, 2002 1:43:21 PM]

Share this post


Link to post
Share on other sites
quote:
Original post by smanches
You have to realize too that the USA, on average, has better and newer equipment than some other contries, especially in Asia. Some of their stuff can get quite old and the older firewalls/proxies/NAT devices just don''t let UDP through right.


To my knowledge, most gamers in Korea (for example) play from cyber cafes. These places are typically fairly new, with newer equipment(although not necessarily high-end stuff), and new infrastructure (wiring, switches etc). Everquest is in beta in Korea, and to my knowledge hasn''t had issues with routing UDP. China is an up-and-coming market, and it''s fully possible that they could have older equipment, but I don''t have any experience in that particular marketplace.

quote:
from smanches
All those algorithms that can slow down response in TCP can be turned off, so thats not a valid argument either. TCP is no slower than UDP when written properly, period. Don''t argue that any more.


I won''t argue, but I''d sure like to discuss it some more I''d first assume that you mean UDP with some kind of application level reliability built in. Straight UDP packets will typically arrive at the destination much faster than TCP (assuming they arrive at all). And if some packets are dropped in between, it''s assumed that it''s okay, otherwise you wouldn''t have chosen UDP for the job in the first place (or you would include some reliability on your UDP).

Also, not everything in TCP can be turned off. Delayed acks (accounting for up to 50-200 ms additional latency(per Stevens, UNP vol.1)) being one that doesn''t turn off. Slow start doesn''t have an option to turn off either (but if it is being invoked by the stack, you don''t want it off anyways - RFC 2001). I''m of the philosophy that TCP has a purpose, and performs it''s job very well. Turning off core features such as nagling (unless you are doing character-based transmissions!) is defeating the strengths of TCP. Bulk transfers (http, ftp) are what TCP is meant for, and it does it very efficiently (due to built-in congestion avoidance etc...).

quote:
from smanches
TCP will become more valuable in the very near future with the implementation of QOS accross the internet. Don''t sell yourself short because you are only looking at a few differences.


Sometime in the future multicast will (hopefully) also be a viable option, but it is UDP only.

I think I understand your point of view though. Having both TCP and UDP available in a networking library is beneficial, primarily when it is a library that you will use for a variety of apps. One app (hmmm, maybe a patcher?) may choose to invoke the TCP interface, while another may use reliable UDP (maybe server to client game comms). It''s beneficial in this case because you devote one person to writing a solid library, then anyone in the company can use it for any variety of apps. If you are writing a network protocol specific for your own game, you might more carefully consider one way or the other.

It was a lot of typing, but still only $.02 worth.

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!