Hi,
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 ?
[quote]Everytime I kick someone in the balls he stops talking to me. What can I do to prevent this?
[/quote]
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?
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” 
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.
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(Kryo.java:483) 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 ?
Javadocs:
http://kryonet.googlecode.com/svn/api/com/esotericsoftware/kryonet/Client.html#Client(int,%20int)
/** @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.
Oh, silly me. I should have read the javadoc of course. Ok that is useful info, thanks.