Kryonet - Client continues to send but stops receiving

Networking & Multiplayer
#1

Hello, I am trying to make a simple multiplayer game using Slick and Kryonet.

I am having problems with the client. It will connect to the server and read a few messages, but after that, it stops receiving messages and it times out. It doesn’t stop sending messages to the server, however. The server seems okay, as it is sending and receiving messages as I expect that it would. After 12s, the client times out. The debugger also indicates that, after the first few packets received, the client listener received function is not being called at all.

I’ve tried running the client in debug mode and pausing it about a second after it connects. The messages that ordinarily would not have been read now show up in the message queue. Similarly, if I prematurely quit the client (not running in debug mode), the client log shows that the client has read the messages.

I’m confused! Any help would be appreciated.

Code:
http://pastebin.java-gaming.org/349099d665d

Server Log: http://pastebin.com/TpPBv0dh
Client Log: http://pastebin.com/FZM9DB7q

#2

Hey, Nate, if you’re (probably) reading this:
There seems to be some major issue with Kryonet.

Someone tried to run RuinsOfRevenge, which uses Kryonet for the networking. But he seems to have the exact same problem.

Hope you’ll try to fix that, Nate!

#3

@lemm, hard to say what the problem is. I guess you’ll have to debug it. Set a breakpoint in Client where a message would be received and see what is going on. I see you have your own synchronization, maybe something goes wrong there.

@matheus23, I’m not aware of any issues, so I can’t fix anything. If someone makes a minimal, executable example showing the problem then I can take a look.

#4

Yeah, I’m sorry. I can’t reproduce it. But some people can. It seems to be dependent on the setup.

#5

Yeah, unfortunately that sort of thing is really hard to fix. :frowning:

#6

As long as you have someone who appears to get that bug /** @see {user:lemm} */, it should be at least possible somehow.

#7 
		
//Kryonet Client.java


// Line 221
if (select == 0) {
			// NIO freaks and returns immediately with 0 sometimes, so try to keep from hogging the CPU.
			long elapsedTime = System.currentTimeMillis() - startTime;
			try {
				if (elapsedTime < 25) Thread.sleep(25 - elapsedTime);
			} catch (InterruptedException ex) {
			}
		} else {
			Set<SelectionKey> keys = selector.selectedKeys();
			synchronized (keys) {
				for (Iterator<SelectionKey> iter = keys.iterator(); iter.hasNext();) {
					SelectionKey selectionKey = iter.next();
					iter.remove();

// ...

I started GameClient in a debugging session and I set the debugger to break if the selector had any keys (i.e., if the program reached “Set keys = selector.selectedKeys();”). The program would only break once every five seconds or so (or it wouldn’t break at all before timing out). In the client log, it was seen that all of the GameStateUpdate packets delivered from the server would then be processed at once. So it looks like the client is receiving the messages from the server, but they can’t be delivered to Kryonet for some reason, so they all clump up until they are all delivered at once.

I also removed the synchronized blocks in my code and it didn’t seem to affect anything.

I am running the client and the server on the same computer. The client is connecting to the server at 127.0.0.1.

#8

Okay, it I have mitigated the problem by sending client position updates to the server at a slower rate. I raised INPUT_SEND_RATE from 1000/60 to 1000/10 and my game is working as expected.

#9

Are you using [icode]setTCPNoDelay(true);[/icode]?

It’s been a while since I use Kryonet, but it may help.

Edit: If you were sending too fast, then that would do it.

#10

@lemm, if you run from SVN there has been a fix to Client and Server to avoid the sleep in the code you posted in most cases. Without this, in some cases this could lead to the 25ms sleep happening very often. Maybe this happened enough that your messages sent at 16ms intervals eventually fill the buffers.

#11

Ah, that seems to have fixed it! I bumped the Client send rate back to 60 messages per second and it’s working as expected.

Thanks for your help.

#12

Sweet! :slight_smile: Just committed a new fix for where one client is disconnected, other clients could get disconnected.