search

EsotericSoftware / kryonet

TCP/UDP client/server library for Java, based on Kryo
BSD 3-Clause "New" or "Revised" License
1.82k stars 419 forks source link

Multithreaded flooding reliably broken with 2.20 #31

Open ghost opened 10 years ago

ghost commented 10 years ago

From pie...@spotify.com on January 21, 2013 01:14:47

What steps will reproduce the problem?

  1. Clone https://github.com/pcarrier/kryoflood
  2. Run mvn package
  3. Observe that everything runs fine with: java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar com.github.pcarrier.kryoflood.Main cs 1
  4. Observe that everything breaks with: java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar com.github.pcarrier.kryoflood.Main cs 2
  5. When digging, please be patient with my benchmark coding style :)

    What is the expected output? What do you see instead?

    The server goes BufferOverflowException as soon as there are more than one client.

    What version of the product are you using? On what operating system?

    I am using kryonet-2.18-all.jar from kryonet-2.20.zip. Not sure which version that is.

    Please provide any additional information below.

    Usage: "cs" to run a client and a server that floods it with UDP messages "csu 20" to run 20 clients and a server that floods them with TCP messages (c for client(s), s for server, u for UDP, followed by a number to have multiple clients) This is the output with 2 clients: --- 8< --- % java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar com.github.pcarrier.kryoflood.Main cs 2 0: Infinity msg/s 1: Infinity msg/s 0 connected! 1 connected! Exception in thread "Server@1" java.nio.BufferOverflowException at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183) at com.esotericsoftware.kryo.io.ByteBufferOutputStream.write(ByteBufferOutputStream.java:42) at com.esotericsoftware.kryo.io.Output.flush(Output.java:154) at com.esotericsoftware.kryonet.KryoSerialization.write(KryoSerialization.java:51) at com.esotericsoftware.kryonet.TcpConnection.send(TcpConnection.java:192) at com.esotericsoftware.kryonet.Connection.sendTCP(Connection.java:59) at com.github.pcarrier.kryoflood.Main$1$1.run(Main.java:43) Exception in thread "Client" com.esotericsoftware.kryonet.KryoNetException: Incorrect number of bytes (12 remaining) used to deserialize object: SimpleTest(id=456673020, message=Hello!) at com.esotericsoftware.kryonet.TcpConnection.readObject(TcpConnection.java:146) at com.esotericsoftware.kryonet.Client.update(Client.java:239) at com.esotericsoftware.kryonet.Client.run(Client.java:317) at java.lang.Thread.run(Thread.java:722) Exception in thread "Client" com.esotericsoftware.kryonet.KryoNetException: Invalid object length: 0 at com.esotericsoftware.kryonet.TcpConnection.readObject(TcpConnection.java:116) at com.esotericsoftware.kryonet.Client.update(Client.java:239) at com.esotericsoftware.kryonet.Client.run(Client.java:317) at java.lang.Thread.run(Thread.java:722) --- >8 --- Whereas with one client, everything runs fine: --- 8< --- % java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar com.github.pcarrier.kryoflood.Main cs 1 0: Infinity msg/s 0 connected! 0: 107526.88 msg/s 0: 172117.05 msg/s 0: 157480.31 msg/s 0: 153374.23 msg/s 0: 149700.6 msg/s 0: 154320.98 msg/s 0: 167224.08 msg/s 0: 186219.73 msg/s 0: 168918.92 msg/s 0: 169204.73 msg/s --- >8 ---

Original issue: http://code.google.com/p/kryonet/issues/detail?id=30

ghost commented 10 years ago

From pie...@spotify.com on January 20, 2013 16:31:05

And this can be reproduced when running server and clients in completely separate processes as well.

For example: % java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar com.github.pcarrier.kryoflood.Main s & % java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar com.github.pcarrier.kryoflood.Main c & % java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar com.github.pcarrier.kryoflood.Main c

ghost commented 10 years ago

From pie...@spotify.com on January 20, 2013 17:37:31

I assume this is more or less an expected behaviour and that "I should take my precautions", but it seems that the server could catch this and return an exception, instead of failing in flight and breaking the client's state.