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.

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.

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.

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.

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

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]

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.