RE: [Algorithms] RE: Zen of Networked Physics
Brought to you by:
vexxed72
From: Ben K. <Ben...@ay...> - 2005-01-10 02:50:30
|
>=20 >=20 > > > If you're thinking about Van Jacobsen, that only happens on modems, > > > but I agree that it can matter on those very narrowband channels. >=20 > > Don't really care about whether a header is 40 bytes or 24 bytes on a T1 > > :-) >=20 > No, but you DO care on a typical DSL or Cable connection upstream > connection, which is what most user-hosted servers use. I think its about 50% of the US market and less in regional areas and other parts of the world . If you only want customers in large UD cities you really lock yourself in .=20 ADSL benefits from VJ compression so tcp packets are probably smaller . W >=20 > > Many games run have a high percentage of users on modems , and I find > > retransmit of packets happens rarely with tcp . >=20 > The specifics of games of course change. Warcraft III uses TCP, and > it sometimes stutters, but the gameplay of an RTS is a lot more > resilient than something that's physically (immediately) interactive. Stutters in UDP games as well , Diablo I battle net was a real pain . Diablo II still stutters but is a lot better.=20 Stuuter is normally caused by missed packets and internet routers drop UDP first .=20 >=20 > Regarding modem percentages, we see about 10% of users on modems, and > that's fairly consistent with what most other publicly available gaming > data reports. Out of all (non-game) internet traffic, more than 50% of > all connected households in the US now use broadband, and it's growing > at faster than 10 percentage units per year. If your more than 4 k from an exchange you have no option.=20 >=20 > > True ... but if you use TCP you can often use port 80 or 25 which most > > personal firewalls allow. NAT is possible with TCP but is normally not > > needed as you just open a port . >=20 > We have done measurment on this, and that's not true. Typically, NAT- > correct UDP will get through; for the cases where UDP does not get > through, 90% of the time TCP on port 80 also doesn't get through. Less > than one percent of our players use TCP-over-port-80; 99% use UDP-over- > port-231x. UDP would be your default. You would only use port 80 TCP if you could not use any other port. At least you gave them them the option which saves a lot of support.=20 >=20 > > > So, for low-latency interactive connections with (mostly) defined > > > bandwidth needs, like games and various interactive conferencing, UDP > > > wrapping a domain-specific protocol ends up being the best choice. >=20 > > I think the ideal case UDP will send the lower latency packet , but I > > think the practical case TCP will have much lower drop rates meaning you > > don't need to resend . >=20 > If the data arrives too late, it's useless to me, because the event it > was intended to influence already has passed. That's what it means to > be "real time". If you're not real-time, then TCP is much more convenient. > If you ARE real-time, then TCP is not the best choice, because the kernel > will withhold newer, available data from you, in order to await the > arrival of a delayed, older packet. What about an internet core router dropping UDP's , take some measurements on a busy night. I bet you will find a lot lower % TCP dropped and if you are sensitive than this is critical. That doesn't mean I wouldn't go UDP I would judge my companies UDP experience very carefully.=20 >=20 > Also, when the kernel goes to re-send, the data it re-sends is already > out of date, because the simulation has progressed! If you need to re- > send data, you want to re-send what the freshest data is, not what the > data was 400 milliseconds ago. With TCP, you can't do that; with UDP, > most designs inherently do this. >=20 > If you disagree, I think it's probably the case that your game design > isn't sensitive to real-time issues, which is a pretty good place to be > in. I just don't think the difference is bug enough in the real world . You will measure it over a LAN but not on the Net . Add it to the a few extra UDP packets which go disappearing and it is a much more complicated decision.=20 >=20 >=20 > Also, as far as examples go, take a packet sniffer to an X-box Live! > connection some time. You'll notice that it's ALL UDP. Even if the game > does a patch download, it's UDP -- I believe the X-box SDK re-implements > TCP-like semantics on top of UDP for these connections. There are many > good reasons to do it this way, if you have the engineering muscle to > shoot for best possible quality. GPRS does the same.=20 Regards ,=20 Ben >=20 >=20 > Cheers, >=20 > / h+ >=20 >=20 >=20 > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > GDAlgorithms-list mailing list > GDA...@li... > https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 |