Why is LockSupport.parkNanos(1); in there at all? It serves no useful purpose I can determine, and it looks like something dropped in because someone told you to.
Welcome to the wonderful world of lag compensation, client side prediction, interpolation and related crap…
You can find various examples how to deal with that on the internet. You won’t get through without as soon as you leave your cozy LAN.
I just can’t find the source I used, maybe later.
Alright, jumping into the next phase: I made a UDP version of my client/server, but the connection starts out slow, then speeds up if I hold down a movement button for a littlebit.
Copy pasted from my SO question:
Alright, so I got a game I’m working on (Right now just movement) and when I move the character it starts out slowly connecting to the server, but if I hold down a move button it speeds up to about half the localhost connection. I heard there’s something in UDP Java that says the first 2000-20000 packets I send are going to be slow unless I send some JVM argument while running, like -X something?
Can someone tell me that JVM line argument? And/or why my connection starts out slow, and speeds up?
PS: should UDP be the same speed as TCP?
There is no ‘connection’ in UDP. There is no such thing as a slow IP packet either.
Well, any chance I can send you my client and you can tell me whats going on? 
I’ll just have to take a wild guess then.
You’re sending way too many packets, half of which get lost along the way. Send less, compensate with guesstimated positions. Do some additional reading about sockets and familiarize yourself with the TCP and UDP protocols some more.
Try and create a simple server (f.ex an echo server ) before jumping into real-time action servers.
That doesn’t explain why it gets faster when I’m sending MORE packets though.
The internet is quite a lively place. Node’s are created and destroyed on the fly. Patterns emerge. Really, the internet is a crazy place. And that’s the explanation. If you stick to local host you’d be oblivious to the erratic antics of the internet.
I suggest you just make it work over LAN first and worry about optimization over the internet (lag) later. In any case, real-time action is quite a handful.
What about trying to make a simple echo server first? Have you tried it? Should take only a handful of minutes and you can test it over telnet (command prompt).
[EDIT]: Also, I didn’t link the article just for shits and giggles, it’s a great article and I’m certain it’s going to give everyone who reads it valuable insight. In fact, I’m sure this article was linked to me on this very forum at some point.
It already works perfectly over lan, Why would I need to make a echo server? All the connections work, they’re just laggy when not on localhost or 127, or LAN.
The logic works, and the movement works.
Could be your VPS just isn’t fast. What are the specs for your virtual server, and is it Xen or OpenVZ or something else?
I’m just trying to get a foothold on the problem. I’m concerned you might not be fully capable of tackling a real-time action game. Especially if it’s your first server app. Then again, who is.
How many packets are the clients sending to the server per second? Is it once per game logic update? while key is being pressed? We don’t have access to your protocol and we don’t know how much bandwidth is used. We can’t, at least I can’t, begin to help find a solution to your lag problem if all we know is that it’s “laggy”.
TCP and UDP are two different beasts. A TCP packet has lots of fancy information that lets the TCP packet arrive at their destination IN ORDER they were sent. UDP are lightweight packets that basically only have a destination address. It neither checks or care weather it arrives at its destination or not. While TCP does multiple checks and confirms with the sender that data has been sent etc.
In general TCP is slower and more reliable and UDP is faster but unreliable. Please read the 6 page Article I linked earlier, it has some insights in the inner workings of TCP and UDP I’m sure you’d love to hear about.
Xen CentOS 5 64bit 256 MB 10 GB
Yeah that should be pretty good, and with available memory that low it means it’s probably not overselling RAM. It’s still possible for there to be congestion beyond your control though, which is why measuring the latency of an echo server would be appropriate, or some other kind of stub server that does nothing but send fake traffic with the same sort of packets your game would. There’s a lot of variables here, you have to tackle them one at a time.
I read an excellent explanation of a real time UDP networking on the Steam site. Something about the source engine networking capabilities. Anyone still have that link?