UDP Vs TCP/IP

Networking & Multiplayer
#121

Win XP’s

[quote]How good is the hardware and software?
[/quote]
Not sure what you mean. Bullet Proof FTP was the client… I’m not sure what the server was.

[quote]Also, just how much less than 100ms is your ping time :slight_smile: ? And what bandwidths are you getting a 50% increase on?
[/quote]
70ms to 100ms. The bandwidth for our tests was actually fairly low 2.4Mbps I think. I’m told this stuff really shines at 10Mb and above.

[quote]I only ask because IME TCP has been very good to me in very low packet-loss very high bandwidth situations, although 100 ms sounds very high (I would expect to get significantly less than that trans-atlantic, IIRC?). At the same time, bad implementations of TCP have been excrutiatingly painful;
[/quote]
But 100ms isn’t that unusual within North America. (My ping from home to java-gaming.org is 68ms, I’m using a 1.5Mbps broadband connection.)
As for TCP implementation I must live with what the OS gives me in that regard. I’m not about to replace the TCP stack in my OS.

The fact is that TCP is an excellent general purpose solution to implement a reliable communication channel with guaranteed in-order delivery. It is not necessarily the best solution for any particular information transfer on over IP.

I’m not suggesting at all that it is worth re-implementing a reliable protocol on top of UDP. However, in the case of reliable bulk transfers I’ve seen that TCP is clearly inferior to a FEC-based UDP method with typical internet connections.

It’s all about choosing a solution that better fits the specific problem you are trying to solve.

OnionNetworks, who I mentioned way earlier in this thread have a free Java implementation of some FEC stuff here http://onionnetworks.com/developers/index.php that could perhaps be used to experiment with these concepts. I don’t have any experience with their FEC implementation so I’m not sure if it can handle anything like what I was testing. I think it is based on “Tornado Codes”.

My company licensed similar technology but based on a newer algorithm (“Raptor Codes”) that uses less CPU power and has very little overhead required in order for the receiver to decode the data, it also had already made a name for itself in the industry we are targeting, so it was good from a marketing point as well.

I recommend reading chapter 20 of TCP/IP Illustrated Volume 1. (ISBN 0-201-63346-9). It’s an older reference, 1994, but I don’t know that typical TCP implementations in the wild have changed much since then. I have only skimmed it thus far… but it looks to be invaluable.

#122

Check http://www.internettrafficreport.com/main.htm

Note the average response times… (currently 94 - 359ms), and the average packet loss (currently 0 - 9%).

Some scary math… shows limits of TCP: http://www.slac.stanford.edu/comp/net/wan-mon/thru-vs-loss.html
Note that the oly factors for TCP rate are RTT (round trip time), MSS ( maximum segment size), and p (packet loss)… bandwidth is NOT in the equation for computing the upper bound. (RTT handles bandwidth as well).

#123

Just that FTP performance is going to depend upon (as well as anything else):

[]quality of hardware implementation of TCP - this is only relevant on particularly high bandwidth (>1Mbps) or on VERY inappropriate network cards, where the network card can in some cases be CPU limited :slight_smile: - but both on the client side and the server (and for a co-lo’d server, the network card can become an important factor)
[]quality of TCP/IP stack on both client and server side
[*]quality of FTP software implementation both client and server - e.g. there are the Apache’s of the FTP server world, and then there are the Zeus’s

Sure; I was just interested to know which you were using, in case I’m ever in a position to experiment myself anytime soon :).

Yup, although you enlightened me in that other thread to the inherent limit in TCP (obvious if you think about it, but I never had - I think I’d just blindly trusted that someone else had thought about such issues already! ;)). Since then I’ve found a few people who work in similar environments and been trying to get more perspective on this - unfortunately, I don’t seem to have found anyone who actually has a low-level knowledge yet: I keep getting half-accurate explanations with enough mistakes in them that I know the person talking doesn’t fully understand what they’re saying (although they think they do). :frowning:

Thanks for the refs; if I do get a chance to play with this soon (without it being an abuse of the systems I have access to :)) I’ll certainly have a go with the java impl.

#124

[quote] get more perspective on this - unfortunately, I don’t seem to have found anyone who actually has a low-level knowledge yet: I keep getting half-accurate explanations with enough mistakes in them that I know the person talking doesn’t fully understand what they’re saying (although they think they do). :(.
[/quote]
and unfortunately you aren’t likely to.

My knowledge is deeper then most of those who get up and talk about this in the game industry and, frankly, ITS still very superficial. People who really understand all the ins and outs of these very complex protocols are few, far between, and mostly in academia.

One thing that IS sure though is that, unless you have such a background, or have a situation perfectly naturally suited to a highly simplified and streamlined protocol, yo (or I, or almost anyone in the game industry) is not likely to invent better on your own.

Another subject that bears on this that we’ve hardly touched on, and I frankly don’t know much about, is practical router design. But in my naive understanding, routers, have fixed memory buffers and, if they get over-filled, they drop packets.

Now if I were a router and I had too many packets, and those packets fell into to categories-- one set labeled as “must get through” and the other set labeled as “don’t care” i think I’d likely drop the latter.

The point being that routers can understand the difference btw TCP and UPD because thats standardized. You build your own pseudo UDP on top of TCP and you are giving up any help they can offer.

#125

[quote]and unfortunately you aren’t likely to.
[/quote]
I certainly don’t claim to be an expert… I’m one of those that “doesn’t fully understand what they’re saying” (but I know that:D) I’m just discovering all this for myself. I only know bits and pieces of the big picture… unfortunately as Jeff says, the big picture appears to be too big for most people to bother with. I must make do with my limited understanding the best I can.

[quote]One thing that IS sure though is that, unless you have such a background, or have a situation perfectly naturally suited to a highly simplified and streamlined protocol, yo (or I, or almost anyone in the game industry) is not likely to invent better on your own.
[/quote]
Well TCP is a general solution ans as with all general solutions there are compromises made. I see this as not much different from finding a better collection class or sorting algorithm because the standard Java ones are not the best for your particular use case. (e.g. “I know my data is mostly sorted already”, or “I need to store collections of primatives”)

[quote]Another subject that bears on this that we’ve hardly touched on, and I frankly don’t know much about, is practical router design. But in my naive understanding, routers, have fixed memory buffers and, if they get over-filled, they drop packets.
…
The point being that routers can understand the difference btw TCP and UPD because thats standardized. You build your own pseudo UDP on top of TCP and you are giving up any help they can offer.
[/quote]
Exactly… this is why you need to have more than the superficial understanding (we all seem to agree that is what WE have:)) to do things right. There are lots of papers by those that know more than us here. I know of a few:

RFC 3448 (TCP Friendly Rate Control)

“Wave and Equation Based Rate Control Using Multicast Round Trip Time” -SIGCOMM’02, August 19-23,
2002, Pittsburgh, Pennsylvania, USA.
Copyright 2002 ACM 158113570X/02/0008

RFCs 3450-3453:
-Asynchronous Layered Coding (ALC) Protocol Instantiation
-Layered Coding Transport (LCT) Building Block
-Forward Error Correction (FEC) Building Block
-The Use of Forward Error Correction (FEC) in Reliable Multicast

The people behind those papers appear to know the details of how routers handle traffic and have done all the math to come up with some interesting alternative protocols.

#126

Yep I basically agree. Where you have a special case that can be exploited, and the knowledge to exploit it, there certainly may be better ways to get the job done. (FEC being a good example, the special case being that you know the future of your data stream.)

#127

Erm, yeah. I didn’t even consider asking games developers about it. I’m trying my old professors in digital comms now…

And I’m certainly not interested in inventing anything better - I’m far more concerned with finding out exactly what the limits are (I could calculate that myself but I’m a bit lazy :)) and more importantly an overview of what people are doing and have done about it. Scott (?) has provided a few glimpses, but I’d like to get a wider perspective if I can.

#128

[quote]Scott (?)
[/quote]
Yep.

If you learn anything interesting be sure to report back. I don’t have much time left to do any more research in the near term, but I will likely revisit the subject in a few months when I need to implement dynamic rate control. I’m not looking forward to it :wink:

#129

Ok…I am at home working out the usage of my networking class (I am wrapping the sockets soz I can plug them into different components of my game, and soz they run as separate threads).

Here is what I have read so far.

Easiest way to use existing thechnology and get fps cook the grenade accuracy is use UDP.

Easiest way to get reliability is use TCP.

Now…and please let me know exactly how much I don’t know. I bow before the combined wisdom of the gurus within this forum…

what if I want the reliability of TCP and the arcade quality speed of UDP?

Here is my proposed solution, laugh if oyu will…

Game server sends UDP to client with “current gamestate”. brute force.
Client sends TCP to server. Reliable never lost packets.

Whaddya think?

#130

That too was discussed in the previous 8 :slight_smile: pages.

It looks like you have had some trouble understanding the previous 8 pages?.

The shortest answer is simply to use someone else’s layer. Unfortunately, the only free ones I know of that have come highly recommended are non-java (e.g. eNet and Raknet), and Quazal is all “extremely expensive, we’ll rip you off ha-ha-ha”.

Read back and find the pages (IIRC somewhere between 3 and 5) which explain the small number of reasons why you don’t want to use TCP (there’s really only two of them), and once you understand those it should be clear that the ONLY way to answer your question is by reference to your complete game-design.

There is no way for anyone here to tell you if your proposal will work, because we have no idea what your game needs.

Or, alternatively, just use TCP until your game starts to suck :). If your game never sucks, you didn’t need to use UDP at all :D. When it does suck, you’ll quickly understand (because you’ve already read this thread ;)) why it’s sucking and how to fix it - that may be the easiest way for you to learn (e.g. I personally find it easiest to learn-by-my-mistakes ;D).

OR, if you pester me enough, I’ll write get an article on it for JGF (either me or someone else). It’s not a high priority right now simply because this thread already describes 98% of what you need to know - and there are other tutorials that aren’t yet written but are NOT covered by a thread here :(.

#131

I need to start reading the entire thread before diving in.

My deep (but not deepest) apologies. (The deepest ones are reserved for my wife, whom seems to be offended whenever she wants something.)(She usually gets what she wants.)

I have had no intention of writing my own IP protocol (I ain’t no Jon Postel), I was going to use the existing java.net.* stuff and wait until it didn’t work anymore. Then I was going to give up on game programming and return to playing halo.

#132

[quote]I need to start reading the entire thread before diving in.
[/quote]
! That explains things, then :slight_smile:

I’m sorry that it’s so long :(, but until an articles is written, you just have to read it.

Technically speaking, I have the power to go through the last 8 pages and delete and edit people’s posts as I see fit, and in theory I could get it down to a much more manageable 3-4 pages. Unfortunately, I’d also need to remove everyone’s names because they’d no longer be verbatim quotes :P. Anyway, not a viable concept.

#133

[quote]Or, alternatively, just use TCP until your game starts to suck :). If your game never sucks, you didn’t need to use UDP at all .
[/quote]
Thsi si very good advice and a specific mof a mreo general concept:

The ebstw ay to fast code is:
(1) Write the code in the simplest, clearest, most encapsulated way you can.
(2) Test and fidn out where the slow parts really are.
(3) Just tune those.

Its a basic forumla for good fast code. Otherwise you spend a lot of energy on things that turn out not to matter at all AND needlessly complicate your code base.

#134

I haven’t seen this mentioned in the thread but it seems relevant. The Reliable Data Protocol (RFC’s 908/1151) is built on UDP and can deliver reliable, out of order data packets without bringing in congestion control and other features of TCP. It looks like there’s a pretty complete Java implementation of it developed as part of a larger project by USC.

A link to an explanatory article on their use of RDP and the implementation they provide:
http://www.isi.edu/div7/arp/ACC/docs/html/rdp/

The project homepage:
http://www.isi.edu/active-signal/ARP/index.html

#135

tcp: for game logic data exchange (pos of player, gun fired etc)

udp: for live chat and stuff.

using both is ok i take it? cool?

#136

I would have thought you should use TCP for chat, since its a reliable protocol. You don’t want to be losing bits of players conversation. In fact, I assumed you actually meant to type it this way round:

udp: for game logic data exchange (pos of player, gun fired etc)

tcp: for live chat and stuff.

#137

tcp: untill things get slow. then udp to see if it helps.

i will work with tcp and change the game logic to fit :slight_smile:

#138

Did this ever get used in a game? It was 9 months ago that you posted this…

#139

In the nine months since you mentioned this I’ve not found any reference (or any person who has a reference) to this BULLET thing. Partly hampered of course by Google’s case- and period-insensitivity, but I trawled several thousand results and found nothing.

If it’s as sophisticated as you say, could you please give us a ref for more info?

#140

Not in a published game yet. We’re still working on it, but its on the back-burner while we work on smaller downloadable games first :slight_smile:

Don’t worry - as soon as we have something to show it will be appearing in the ‘Your Games Here’ thread!

  • Dom