Archived

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

hello2k1

TCP vs UDP vs TCP & UDP?

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
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
That is most of what I was trying to say. It was morning so you have to read between my lines. :-)

You are right about the slow start. That can''t be turned off, but causes little problems on a good connection. The sliding window can be adjusted to allow more packets in flight. I dont'' know the exact way, but when jrlogic69 and I were developing VNL, he was able to up the in-flight packet cound. That basically disables it.

And just so you all understand, I''m not saying you should use TCP for your game. I''m just saying that you should not rely on UDP alone. It is NOT better in every case, and will fail you at some point. It is better, as it is in everything, to have multiple chioces.

Share this post


Link to post
Share on other sites
i would not call linux 2.0+ running on a 386 or higher particular "new" firewall/NAT nor expensive

while true some devices are crap, they are few enough to not impact your suscribtion rate too much (i believe anyway). you think it matters, release a test app. you will get the highest compatiblity using TCP, thats given and there is no arguing that. upto you to decide if you want that extra compatibility.

Share this post


Link to post
Share on other sites
quote:
Original post by smanches
I dont'' know the exact way, but when jrlogic69 and I were developing VNL, he was able to up the in-flight packet cound.


Well, now I know who your buddy in Texas is... That is the one library we use that does have TCP. I added reliable UDP to it, under some pretty tight restrictions. It wasn''t fun, and I daresay the result isn''t at all pretty


Share this post


Link to post
Share on other sites
fingh, did you use a positive or negative ack structure? Did you implement ordering as well? I''m in the middle of our network library doing the reliable UDP service right now. It would be interesting to hear other ideas.

Share this post


Link to post
Share on other sites
This particular go, I just integrated an existing reliable UDP layer into the library. Because a couple of projects were already using the library in production, we (we = my boss) felt that the existing interface shouldn''t change. This led to some very ugly code on my part, and if I could do it differently, I would, even to the point of drastically changing the "live" api. I''ve since moved on to other projects...

I''ve tried a lot of different stuff with UDP. I''ve tried what you call positive and negative ack structures, even in the same library. The way that''s worked best for me is to resend unacknowledged packets auctomatically rather than having the client request missed packets. Doing it the other way(client explicitly requests missed packets), the latency can get critical - what if the resend request get''s dropped? Using both methods at the same time didn''t work well for me. You start generating a lot of extra traffic if you run into congestion, which just makes it worse. It''s possible to make it work but I didn''t put that much thought into it at the time.

Generally when I develop reliable UDP, I will implement reliable delivery and ordering(optional on a per-packet basis).

Share this post


Link to post
Share on other sites
Honestly it sounds like smanches is suggesting that you basically build 2 transmission layers, one TCP, one UDP; each with the same functionality. First attempt a UDP transmission mode, no reply, failover to TCP. Sounds simple enough and would add what, 1 second to the login time? If you''re worried about server load, simply build a series of simple connection servers specifically to handle TCP only traffic.

I do agree with him though, there is a lot of difference between the router level transmission of UDP and TCP. Fortunately this is relatively irrelevant because very few backbone connections are very heavily loaded on any but the highest usage days, but it''s not uncommon to find that your cable or dial-up ISPs are overloaded half of the days of the week.

Share this post


Link to post
Share on other sites
quote:
Original post by solinear
Sounds simple enough and would add what, 1 second to the login time?


But it''d add what, 2 weeks to the developement time (including testing)? And that''s assuming you''re working full-time on this thing. The point is, will it be worth it? I don''t really believe there are many people out there who can''t play a UDP-only game. Almost all commesial games are UDP only, so why should we spend all that extra time implementing something that we don''t really need?

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:
But it''d add what, 2 weeks to the developement time (including testing)?


OK, agreed. You would have to change your communications module and that might take 2 extra weeks. So you change it in a patch after development is complete, like Origin did. I hope that your communications programmers aren''t overloaded on other projects at that point in time.

Share this post


Link to post
Share on other sites
quote:
OK, agreed. You would have to change your communications module and that might take 2 extra weeks. So you change it in a patch after development is complete, like Origin did. I hope that your communications programmers aren''t overloaded on other projects at that point in time.


They will be overloaded trying to defeat the various tools that were created by players on the first day of public beta in order to cheat at your game. They''ll be tweaking monitoring systems. They will wonder why release account keys don''t register properly with existing beta accounts. They''ll be debugging encryption algorithms that insert spaces and other typical delimiters into their string data. They''ll be trying to figure out how to compress some messages but not others (for performance), while not completely hosing the released client software. They''ll be wondering how the company will be able to afford the 10+ expansion servers needed to serve the current player (over)load. They''ll be hunting down hackers that syn flooded them 3 minutes after the servers went live. etc... Most game companies probably don''t have a "team" of dedicated network programmers. Like any other project, someone gets tasked with writing the networking layer. After they "finish" it, they get other tasks, because they still have 95% of the game to be finished. They''ll maintain the source, but there is too much going on to make huge modifications to it that suddenly nullify all of your beta testing and QA cycles by changing the bottom-line core system of a MMOG. Hurray for Origin (no sarcasm). How long after launch did they do this?

Obviously unfunded projects that don''t worry about a budget and a payroll can get away with having someone dedicated to programming just the network stuff. In this case, sure, why not add TCP (other than processing time).

Share this post


Link to post
Share on other sites
quote:

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.


Firt, design the game so that the networking protocol in use is irrelevant to everything outside the network code.

quote:

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".


TCP is no more or less secure than UDP.
Using TCP to deliver urgent data is dumb.
By urgent you seem to mean reliable. If the number of clients is small, then using a UDP/TCP combination should be acceptable (so long as you don''t go and create a thread for each and every socket).

quote:

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.


It depends on the number of clients you intend to deal with. If the numbers are relatively small (under 100), then one or two sockets per client should be doable given sufficent RAM. If you want to support *lots* of simutaneous users, you want to use one UDP socket and embed information to distinquish the client in the packets. This minimizes the per socket/client memory overhead on the server - you now have to keep track of additional information yourself, but the socket impl doesn''t need a seperate send & receive buffer for every client.

So long as you use an asyncronous method, and a small number of threads, there shouldn''t be any significant CPU differences.

Also bear in the mind, that supporting hundreds of client would require considerable bandwidth.

Magmai Kai Holmlor

"Oh, like you''ve never written buggy code" - Lee

[Look for information | GDNet Start Here | GDNet Search Tool | GDNet FAQ | MSDN RTF[L] | SGI STL Docs | STFW | Asking Smart Questions ]

[Free C++ Libraries | Boost | ACE | Loki | MTL | Blitz++ | wxWindows| Spirit(xBNF)]

Share this post


Link to post
Share on other sites
quote:
Original post by Tilch
Stick to TCP because it is more reliable and more universal.



More universal? What do you mean by that ?



[edited by - granat on August 9, 2002 3:45:29 AM]

Share this post


Link to post
Share on other sites
TCP is the "easy" way to do it and is generally a good way to get a game going since it eliminates most issues with network coding without you doing anything. e.g. Your project will work. If you want to make it work better THEN introduce the added complexity of UDP and even then you''re not guarenteed it will actually be better.

With UDP you could just end up reinventing TCP (and a slower less efficient version at that) and in the process waste a significant amount of time that could have been better spent developing game play and optimizing your messaging system.

For my MMO project, I''m using and sticking with TCP because UDP would be a giant waste of my time. I may learn it later but I have more important things to work on at this time.

Without specific details on your project there''s no telling which would be better. If you wrote a UDP wrapper and a TCP wrapper it would be a trivial task to swap them in and out of specific tasks to see which one works better.

Personally, I always go with TCP (or in DPlay''s case; Guarenteed messages) until I know my project works. Speed is irrelavent until you have it working. If you worry about UDP now, when something doesn''t work you''ve got a lot more variables to contend with.

Ben


IcarusIndie.com [ The Rabbit Hole | The Labyrinth | DevZone | Gang Wars | The Wall | Hosting | Dot Com | GameShot ]

Share this post


Link to post
Share on other sites
Ok, everyone seems to be saying the exact same thing.. I''m just going to finish this off. But, I do however have a question.

If I were to use UDP, would the users have to forward the game port(s) if they had a router? I don''t want the users to have to mess with anything like that, so any measures to counter having to make the users do such a thing would be useful.

Thanks for all your help.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Do you mean the port that they (clients) are sending their data through? If so, that info is returned in the sockaddr struct when you call recvfrom() (and if they are behind a NAT router, the port will be the port on the router, which will get relayed back to the client that originated the udp)

Share this post


Link to post
Share on other sites