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]
  ignore  |  Print  
  TCP or UDP for my game?  (Read 4290 times)
0 Members and 1 Guest are viewing this topic.
Offline lesto

Senior Newbie





« Posted 2011-10-28 02:18:49 »

Hi

i've read almost all TCP vs UDP thread, but i still have some question.

my game will be very x-wing vs tie-fighter like, almost a clone.

I've had some version running, fine in LAN, but unplayable on the internet.

My physic is DETERMINISTIC: so I can just send the input of the player to host, and from the host "collect" the actions and send them back to all clients.

also on client side i use 2 world: one is sinc with host world, the other is ainc and only use the action from client's side, and generally is in the future respect sinc world of "ping/2" ms.

Probably client will send very small packet every time an input is readed, while the server will elaborate this action "pool" at 30 or 40 FPS.

now imagine a 40FPS action update cycle (25ms).

A server collect all the action arrived during the current FPS, and execute them in the next FPS, then send them back to all client (well, sending them back can be done immediately, but then there will be too much overhead)

client A's ping with host is 100ms
client B's ping with host is 120ms

client A shot, the action arrive with 50ms of lag, worst case add 25ms for action to be executed, and send it back. because of asinc world, client A see it's shot after 50ms from send, and it will be corrected to 75ms after 125ms. I think that 50ms (or better half ping) from clicking a button and ship reaction are too much.
client B see the shot after 25+60ms, 85ms!  this is too much in a shooter game!

ok, maybe 100ms is not a good ping, but many game still playable. Ok thanks to asinc world the experienced lag is "ping/2+25ms"(worst case, with a "warp" of 25ms) on your ship, but you will still experience "your ping/2+25ms"(worst case) lag for other's ship.

As you can see I need guaranteed delivery(at least from server to client side), but I don't care about the order. client will send small packet very fast, and server "big" packet every 25ms.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #1 - Posted 2011-10-28 02:21:17 »

TCP.

See my work:
OTC Software
Online theagentd
« Reply #2 - Posted 2011-10-28 02:33:00 »

If you need deterministic physics, then you basically have to ensure that all packages get there one way or another. TCP does this for you. Lots of people will literally scream at you that TCP sucks balls and that you should always use UDP. This is completely wrong in this case, because if you were to use UDP you'd have create a TCP clone on top of it to handle resending and confirmation, e.t.c. Do you think you're better at writing network protocols than the people who came up with TCP? Use TCP.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mads

JGO Ninja


Medals: 26
Projects: 3
Exp: 6 years


One for all!


« Reply #3 - Posted 2011-10-28 03:53:17 »

TCP, unless it's not important,

Offline sproingie

JGO Kernel


Medals: 202



« Reply #4 - Posted 2011-10-28 05:55:32 »

If SCTP were actually usable, it'd be perfect.  Since using it over the internet is a pipe dream, use the next best thing: TCP.  Be sure to turn off the Nagle algorithm (Socket.setNoDelay(true)) for low latency.  You'll also want to look into the tunables in Socket.setPerformancePreferences -- just don't expect dramatic results from them.
Online theagentd
« Reply #5 - Posted 2011-10-28 13:32:02 »

Be sure to turn off the Nagle algorithm (Socket.setNoDelay(true)) for low latency.  You'll also want to look into the tunables in Socket.setPerformancePreferences -- just don't expect dramatic results from them.
Kill Nagle's algorithm the first thing you do. Having it enabled sneakily enough works fine during local testing (as it isn't used), but as soon as you have two computers connecting to each other you'll see ping jumping between 0 and 300 over LAN.

Myomyomyo.
Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #6 - Posted 2011-10-28 20:19:05 »

Be sure to turn off the Nagle algorithm (Socket.setNoDelay(true)) for low latency.  You'll also want to look into the tunables in Socket.setPerformancePreferences -- just don't expect dramatic results from them.
Kill Nagle's algorithm the first thing you do. Having it enabled sneakily enough works fine during local testing (as it isn't used), but as soon as you have two computers connecting to each other you'll see ping jumping between 0 and 300 over LAN.
OMG I didn't know about this, that's amazing. I need to try that.

See my work:
OTC Software
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #7 - Posted 2011-10-28 21:02:53 »

Disabling Nagle's algorithm might actually hurt. As every .write(...) will result in a distinct TCP packet.

I usually leave Nagle's algorithm on, and .flush() the OutputStream when I'm done with the message. That way I can make the OS pick the most efficient TCP packet sizes, while I'm generating the data, without the fear of doing a write(byte[]) that is too small (increasing overhead) or slightly too big (in which case a second, tiny TCP packet will be created, which is even worse).

IMHO, Nagle's algorithm should only be disabled if you're either a networking expert, or using NIO, which doesn't have a flushing mechanism.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2011-10-28 21:05:22 »

Maybe you'd assemble the entire byte[] you were going to send and only issue a single write() though.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 744
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2011-10-28 21:08:28 »

Maybe you'd assemble the entire byte[] you were going to send and only issue a single write() though.
Reading the original post, I think the author isn't.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Coder


Medals: 11


falling into the abyss of reality


« Reply #10 - Posted 2011-10-29 02:00:14 »

Quote
My physic is DETERMINISTIC

Independent of the networking aspect to your question, are you absolutely sure about this?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline sproingie

JGO Kernel


Medals: 202



« Reply #11 - Posted 2011-10-29 02:46:10 »

One shouldn't disable Nagle if they want maximum throughput on streams, no, but unless you want built-in delay on every packet smaller than the MTU, you'll want it on.  Flush is a userspace operation, and does not actually guarantee the TCP layer will immediately deliver your packet. 

Obviously, don't take on faith what you can and should measure.  If you're close to saturating the link for example, disabling Nagle will only make things worse.
Online theagentd
« Reply #12 - Posted 2011-10-29 05:01:41 »

Maybe you'd assemble the entire byte[] you were going to send and only issue a single write() though.
Reading the original post, I think the author isn't.
Gotta admit I don't, but it was a pretty long time since I did networking using byte[]s. I've only been using ByteBuffers recently, but not enough to actually be bothering about performance. Disabling Nagle's and using either a custom buffer or a BufferedOutputStream should be enough to accomplish that, right? Just flushing it (which actually should flush it with a single write()) every frame should work fine.

Does anyone know if Nagle's algorithm is used in NIO?

One shouldn't disable Nagle if they want maximum throughput on streams, no, but unless you want built-in delay on every packet smaller than the MTU, you'll want it on.  Flush is a userspace operation, and does not actually guarantee the TCP layer will immediately deliver your packet. 

Obviously, don't take on faith what you can and should measure.  If you're close to saturating the link for example, disabling Nagle will only make things worse.
You won't be close to saturating the link with a game unless you're Doing Something Wrong. You should be able to stay well under 10kb/sec upload, and if that saturates your link... Well, I guess the delay that comes with such a connection doesn't make it fit for gaming in the first place. If you do some simple buffering yourself you should be able to get something in between Nagle's and nothing at all. I'd say that's the best compromise.

Myomyomyo.
Offline lesto

Senior Newbie





« Reply #13 - Posted 2011-10-29 13:26:54 »

Maybe you'd assemble the entire byte[] you were going to send and only issue a single write() though.
Reading the original post, I think the author isn't.

I'm serializing object on java NIO, and this object is a linked list of actions... so every write should be be a flush. I'm also truncating the array on the size of MTU-100, and putting exceeding action in another array, but maybe this should be done by NIO.

Quote
My physic is DETERMINISTIC

Independent of the networking aspect to your question, are you absolutely sure about this?

yes! and i'm really happy about this. Physic is just 2D (jbox2D), but with some trick is full deterministic on windows (32 and 64bit), linux (32 and 64 bit), also windows machine was intel, linux was AMD plus a 32bit linux intel(eeepc!). I have an old mac to test on, but actually never "played" with him (I've to reinstall OS and so on...) more info on: http://box2d.org/forum/viewtopic.php?f=9&t=7074&start=10


One shouldn't disable Nagle if they want maximum throughput on streams, no, but unless you want built-in delay on every packet smaller than the MTU, you'll want it on.  Flush is a userspace operation, and does not actually guarantee the TCP layer will immediately deliver your packet. 

Obviously, don't take on faith what you can and should measure.  If you're close to saturating the link for example, disabling Nagle will only make things worse.
You won't be close to saturating the link with a game unless you're Doing Something Wrong. You should be able to stay well under 10kb/sec upload, and if that saturates your link... Well, I guess the delay that comes with such a connection doesn't make it fit for gaming in the first place. If you do some simple buffering yourself you should be able to get something in between Nagle's and nothing at all. I'd say that's the best compromise.

stream saturation can be easily archived in the host, if there are too many player.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #14 - Posted 2011-10-29 17:40:28 »

I couldn't help but notice the stickied topic right above this one.  Odds are it visited the same topics this one did.  Whatever you decide to optimize or tune, just make sure you make one change at a time and make sure to measure it, on the hardware and software you expect to be using in the real world (or at least as close as you can get).
Offline lesto

Senior Newbie





« Reply #15 - Posted 2011-11-02 19:10:34 »

I'm building a test engine for determinism, with a fake network layer.
I'll write news on jbox2d page, but i think I'll use TCP with noDelay(Nagle turned off), and let you know when i'll make it work.
Pages: [1]
  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.

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

Riven (38 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

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
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!