Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5]
  ignore  |  Print  
  UDP Vs TCP/IP  (Read 92009 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #120 - Posted 2003-12-01 23:44:30 »

Quote

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 Smiley ? 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.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #121 - Posted 2003-12-01 23:49:04 »

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

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #122 - Posted 2003-12-02 09:52:51 »

Quote

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

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! Wink). 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). Sad

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 Smiley) I'll certainly have a go with the java impl.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #123 - Posted 2003-12-02 22:06:35 »

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


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #124 - Posted 2003-12-03 02:28:46 »

Quote
and unfortunately you aren't likely to.

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:

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.

Offline Jeff

JGO Coder




Got any cats?


« Reply #125 - Posted 2003-12-03 03:52:19 »

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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #126 - Posted 2003-12-03 10:47:19 »

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.


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

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #127 - Posted 2003-12-03 12:05:55 »

Quote
Scott (?)

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

Offline jared888

Senior Newbie




Eat your own shorts. Leave mine alone.


« Reply #128 - Posted 2004-04-15 19:16:46 »

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?

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #129 - Posted 2004-04-15 19:37:43 »

Quote

Here is what I have read so far.

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


That too was discussed in the previous 8 Smiley 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 Smiley. If your game never sucks, you didn't need to use UDP at all Cheesy. When it does suck, you'll quickly understand (because you've already read this thread Wink) 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 Grin).

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

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline jared888

Senior Newbie




Eat your own shorts. Leave mine alone.


« Reply #130 - Posted 2004-04-16 15:45:51 »

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.

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #131 - Posted 2004-04-16 16:33:08 »

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


! That explains things, then Smiley

Quote

My deep (but not deepest) apologies.


I'm sorry that it's so long Sad, 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 Tongue. Anyway, not a viable concept.

malloc will be first against the wall when the revolution comes...
Offline Jeff

JGO Coder




Got any cats?


« Reply #132 - Posted 2004-04-16 19:56:41 »

Quote
Or, alternatively, just use TCP until your game starts to suck Smiley. If your game never sucks, you didn't need to use UDP at all .


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.


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!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline grayarea

Junior Newbie





« Reply #133 - Posted 2004-04-18 11:19:21 »

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

Senior Member




AFK


« Reply #134 - Posted 2004-06-27 12:52:50 »

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?
Offline mhale

Senior Newbie




Take pity, I'm just a poor blob!


« Reply #135 - Posted 2004-06-30 21:52:21 »

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.
Offline aNt

Senior Member




AFK


« Reply #136 - Posted 2004-07-01 07:37:09 »

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

i will work with tcp and change the game logic to fit Smiley
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #137 - Posted 2004-08-11 16:09:55 »

Quote

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

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #138 - Posted 2004-08-11 16:12:01 »

Quote

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?

malloc will be first against the wall when the revolution comes...
Offline crystalsquid

Junior Member




... Boing ...


« Reply #139 - Posted 2004-08-12 16:57:36 »

Quote

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


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 Smiley

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

- Dom



Offline Matlu

Junior Member




Hasta La Victoria Siempre!


« Reply #140 - Posted 2004-08-15 01:18:59 »

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

Multiplayer Online Games
http://www.duelboard.com
Offline Vorax

Senior Member


Projects: 1


System shutting down in 5..4..3...


« Reply #141 - Posted 2005-01-06 23:41:17 »

Hmmm....a thread about UDP vs TCP for games?

UDP!!!!

Seriuosly though, it really depends on what you are writting.  

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

Bottom line: FPS = UDP... MMO = Whatever you fancy, but TCP is easiest.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #142 - Posted 2005-01-07 00:49:34 »

Quote
Hmmm....a thread about UDP vs TCP for games?

UDP!!!!
...
Bottom line: FPS = UDP... MMO = Whatever you fancy, but TCP is easiest.


No, and no. Please read the *whole* thread before replying.

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.

malloc will be first against the wall when the revolution comes...
Pages: 1 ... 3 4 [5]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

E.R. Fleming (14 views)
2014-07-29 03:07:13

E.R. Fleming (4 views)
2014-07-29 03:06:25

pw (39 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!