Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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  
  [Kryonet] - large traffic causes client disconnect  (Read 6074 times)
0 Members and 1 Guest are viewing this topic.
Offline Unimatrix325
« Posted 2012-01-23 14:09:21 »

I have a question to kyonet lib. It seems to have problems with handling both large and numerous messages. When I send to many messages per second (hundreds) or some messages with a lot of data, the client just disconnects from the server. There is neither an exception nor an error message.
How am I supposed to prevent or handle this ?
Offline theagentd
« Reply #1 - Posted 2012-01-23 14:55:40 »

Everytime I kick someone in the balls he stops talking to me. What can I do to prevent this?
Don't kick him in the balls. xD

If he's on wireless there's a big chance the router just can't keep up. Could that be the problem?

Offline Unimatrix325
« Reply #2 - Posted 2012-01-23 15:13:18 »

Well of course that could be the problem, but that does not answer my question. I can't just arbitrary cut down the traffic to some magic number and then expect this problem won't occur again. I would expect that if the network can't keep up, that it will try to do it's best. Of course the messages will start having delay end eventually I may get some timeout or buffer overflow or whatever. On the other hand it may be a peak traffic which will calm down in few seconds and then it should catch up.
But I need some information, that the network is not able to handle the traffic. Not just plain "client disconnects".

In another words - it seems logical to expect from a network layer/library to deliver all the data I provide. I can understand that when I give 200kB of data on a 50kB connection it will take at least 4 seconds to send it. But I don't expect the answer "nope, I can't send 200kB" :-)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Nate

« JGO Bitwise Duke »

Medals: 167
Projects: 4
Exp: 14 years

Esoteric Software

« Reply #3 - Posted 2012-01-23 15:30:21 »

There should be a message logged. Try setting the logging level lower, Log.DEBUG() or Log.TRACE(). If you send enough data fast enough, you can fill the buffer in your networking hardware and KryoNet will start to fill the "write buffer". When this is full, Connection#sendTCP logs a message at WARN or ERROR. See the writeBufferSize parameter on the Client and Server constructors. This should be set higher if you expect occasional peak bursts of traffic size or frequency.

Offline Unimatrix325
« Reply #4 - Posted 2012-01-23 16:48:29 »

Ah, that sounds helpful.
I set the logging levels to trace, and yes. I can see "com.esotericsoftware.kryo.SerializationException: Buffer limit exceeded writing object of type..." at com.esotericsoftware.kryo.Kryo.writeClassAndObject( now.
I tried to set larger bufferSizes for server and client (32768, 16384). It helped, but it also increased the latency terribly. Or maybe not the latency because the whole game is getting frozen every second or two.
EDIT : ah, nevermind, that was caused by large amount of logging output. So it seems to be working.
Are there some recommanded values ? Or is there some approach I can take to this ? I can set the values higher, but still, it may happen, that they will overflow. Is there some solution to this situation ?
Offline Nate

« JGO Bitwise Duke »

Medals: 167
Projects: 4
Exp: 14 years

Esoteric Software

« Reply #5 - Posted 2012-01-23 17:53:20 »


/** @param writeBufferSize One buffer of this size is allocated. Objects are serialized to the write buffer where the bytes are
 * queued until they can be written to the socket.
 * <p>
 * Normally the socket is writable and the bytes are written immediately. If the socket cannot be written to and
 * enough serialized objects are queued to overflow the buffer, then the connection will be closed.
 * <p>
 * The write buffer should be sized at least as large as the largest object that will be sent, plus some head room to
 * allow for some serialized objects to be queued in case the buffer is temporarily not writable. The amount of head
 * room needed is dependent upon the size of objects being sent and how often they are sent.
 * @param objectBufferSize Two (using only TCP) or four (using both TCP and UDP) buffers of this size are allocated. These
 * buffers are used to hold the bytes for a single object graph until it can be sent over the network or
 * deserialized.
 * <p>
 * The object buffers should be sized at least as large as the largest object that will be sent or received. */

Other than that, not much you can do. You probably don't want your buffers growing unbounded. Kryo doesn't properly support streaming or auto growing the buffers. The next version will, whenever I get a bunch of free time.

Offline Unimatrix325
« Reply #6 - Posted 2012-01-23 18:01:38 »

Oh, silly me. I should have read the javadoc of course. Ok that is useful info, thanks.
Pages: [1]
  ignore  |  Print  

EgonOlsen (79 views)
2018-06-10 19:43:48

EgonOlsen (59 views)
2018-06-10 19:43:44

EgonOlsen (78 views)
2018-06-10 19:43:20

DesertCoockie (261 views)
2018-05-13 18:23:11

nelsongames (160 views)
2018-04-24 18:15:36

nelsongames (158 views)
2018-04-24 18:14:32

ivj94 (902 views)
2018-03-24 14:47:39

ivj94 (162 views)
2018-03-24 14:46:31

ivj94 (813 views)
2018-03-24 14:43:53

Solater (177 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!