Out of interest, whose implementation(s) of TCP/IP stacks are you using?

Win XP's

Quote

How good is the hardware and software?

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 ? And what bandwidths are you getting a 50% increase on?

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;

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.

Not sure what you mean. Bullet Proof FTP was the client... I'm not sure what the server was.

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

Quote

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.

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

Quote

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.

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

Quote

OnionNetworks...

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.

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

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.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

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.

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:

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

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

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.

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.

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

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

That too was discussed in the previous 8 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 . 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 ).

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 .

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.

Beware the rabbit of the mind, for it gnaweth on the carrot of the soul.

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 . Anyway, not a viable concept.

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.

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:

I have recently written my own MMOG network layer (to support 1000+ clients on a couple of ports) using the TCP SACK system outlined in 'RFC 3517' (gogle for it, as it also contains links to the previous relevant RFC's), and was quite pleased with the results and the time it saved using these docs.

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

And his "don't mix TCP and UDP" is too simplistic and off the cuff. There are legitimate reasons to use a combined strategy. There are some very sophisticated latency reduction techniques that depend on it (eg TEN's B.U.L.L.E.T.).

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?

EDIT: (moderator) this is definitely off-topic, and do NOT reply on this thread to this question. I will start another thread for replies.

I have a "not-so-off-topic" question:Many people claim, that prior to JDK 1.4.0 all IO operations were blocking and there was no way to avoid thread-per-client model. This I cannot really understand, because:

- ServerSocket.accept() really blocks, but it is not a problem, it is possible to have one thread just for accepting new connections, and one thread for handling all existing connections- InputStream.available() does not block, so it's possible to have non-blocking reads, if you call available() first- OutputStream.write(byte[]) does not seem to block either, at least as far as I know. In fact it does not provide any output, I've never seen it to throw an exception, even when the connection was closed. I really don't think it blocks. Correct me please, if I'm wrong.(I'm talking about Socket TCP connection)

I have implemented this, and it seems to work without a problem. I'm thinking of switching to NIO, but I'm not convinced it could bring any real advantage - can someone please try to convince me?

For an action game you will of course want UDP because you will be operating in frame rates of 20-50 per seond to simulate real-time operations. Dropping a frame or two doesn't really matter and if the network burps you can recover pretty fast. It also induces less overhead for the server because most action games are very heavy on server CPU because they have to make so many decisions on behalf of the clients. Remember in the action game world, it is usually users that run the server, not a server farm, so you need to think about "Joe shmoe's" server (that may actually be running the client at the same time)...not the 200 PC's with 2 processors sitting in the back room grazing on your OC-192 connection (read server farm here)

In an action game you can't have the server waiting for a response in order to make a decision...if "Jane Ubber Boomer's"' packet didn't arrive...Jane is out of luck....better to piss off one then many. If the packet arrives latter on, it doesn't even matter because that 50ms frame is long gone anyways...client magic like bezier prediciton will have already solved it anyways. There is a reason why so many action games use UDP the requirements of an action game fit very well.

For something like an MMOG it's really up to the developer. You can suffer the latency induced by guaranteed delivery becuase MMOG's are typically round based and don't require much server power at all (thus you can have crazy things like 10k on one box). This can be a benefit because if "Joe Wizard of Wilmouth" paid 75k GP for the fancy new cloak, you better be damn sure you got the message at the server or your CSR is gonna get an ear full With UDP you would have to force the client's into requesting confirmations of such things which isn't really good in todays MMOG environment simply because todays MMO clients are already overcomplicated with trying to render 200 players at once each with his unique and ubber goodies and customizations along with intricate/exahustive user interface...etc..and you have 10k other guys to worry about, double confirmation just doubled your servers work. MMOG's focus is on distribution, supporting vast numbers of clients, accuracy of information not accuracy of state like an FPS. Instead of operating at 30 frames per second, you don't need to think along those lines at all...the spell will reach the target if the roll was good...there is no collision detection for spells or sword swings....if there is in your MMOG (like Planetside) then your MMOG is really a monster scale action game and will have to go back to something like UDP or suffer with something you can not control ...the users internet connection causing you a mega platinum in CSR costs

THREAD WILL NOW BE LOCKED to prevent any more of these responses that add nothing to what's gone before. I made it stikcy in the first place to serve as a pseudo-FAQ, but I wasn't confident enough to lock it. Sorry about that.

If you have new ideas / concepts to explore, start new threads from now on.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org