Not entirely sure what is wrong here, I have a single message that does not like being received, but it will send just fine.
This is the error I am getting on the server side receiving the message from the client:
[2019-03-25 13:18:30] [SEVERE ] Unhandled error, endpoint:NioEndpoint[1, java.nio.channels.SocketChannel[connected local=/127.0.0.1:13480 remote=/127.0.0.1:54611]], context:Envelope[NioEndpoint[1, java.nio.channels.SocketChannel[connected local=/127.0.0.1:13480 remote=/127.0.0.1:54611]], reliable, 8192]
java.lang.IllegalArgumentException
at java.nio.ByteBuffer.allocate(Unknown Source)
at com.jme3.network.base.MessageProtocol.addBuffer(MessageProtocol.java:141)
at com.jme3.network.base.KernelAdapter.createAndDispatch(KernelAdapter.java:220)
at com.jme3.network.base.KernelAdapter.run(KernelAdapter.java:284)
[2019-03-25 13:18:30] [INFO ] Disconnected /127.0.0.1:54611
The message looks like so:
@Serializable
public class JmeSyncChunkMessage extends AbstractMessage implements NetworkMessage {
private int x, y, z;
private float dx, dy, dz;
private float[] voxels, density;
private String world;
public JmeSyncChunkMessage() {
this.setReliable(true);
}
... all the setters and getters ...
}
The float arrays are exactly 6859 each. I just realized I am exceeding the 32KB limit. What I don’t understand is why there is not a buffer overflow error on the send side if I am exceeding the 32KB limit…
It doesn’t solve your problem, but rather than send chunks across the network, I send a request for a chunk, and the server returns a hash. That way the server only has to generate once and sends the saved hash to all clients.
On the client I generate the chunk and compare the hash and if it’s the same I use it. It sounds a little strange but it means the server is authoritative, only generates once, and you reduce traffic drastically.
Normally that would be fine, but in this case, the client is sending new chunk data to the server. Nothing within the system is generated. It is all hand sculpted terrain on the client.
I am going to try breaking the packet up, I just don’t understand the error…
I don’t know why the send side isn’t bombing… it should be.
The only other thing that causes this sort of issue is corrupted streams. Like one side using a different order in their serialization initialization than another. But if your using the built-in support that autosends the server’s list then that shouldn’t happen either.
…and if you are running from the same classes then you also shouldn’t have binary mismatch issues, either.
These are just some of the things I can think of that would corrupt the stream.