forums.smartfoxserver.com

The problem is this his happening for legitimate traffic. The example I provided ensures that the bug is triggered. But I am sending legitimate packets with some multi-byte chars. This is a language learning game I'm making after all.

[edit] Oops. Posted twice.

@st0nerhat:
One way to follow Lapo's suggestion would be to explicitly test that the outgoing byte length doesn't exceed MAX_MSG_LEN by adding a check to SmartFoxClient.as in the writeToSocket() function (byteBuff.length). The problem with this approach is by that time you may no longer be able to have your client fail gracefully.

@Lapo:
A possible cause of byte truncation on the server would be if you were using some sort of buffer to read the incoming bytes, and had set the maximum size of that buffer to be too small. The behavior both st0nerhat and I are consistently seeing is that this limit is MAX_MSG_LEN. Taking into account that MAX_MSG_LEN is supposed to be a character limitation, the max buffer size should be changed to (MAX_MSG_LEN * 6) if you want to properly decode incoming bytes to UTF-8.

Increasing MAX_MSG_LEN may reduce the incidences of MalformedInputException, but as I showed in my example, it doesn't completely resolve it. I have observed this occurring with a very high MAX_MSG_LEN (10 MB). As long as messages are being sent to the server sufficiently often, this could still occur. Because of this, checking on the client also doesn't help. I would have to know how many bytes the server has processed since the last message and the latency between sending the message and it ending up in the receive buffer on the server's socket.

If you can send me a client app that reproduces the problem we will take a look. Just use our contact or support email and add a reference to this post.

Also, could you explain what is the use case for firing large multibyte characters chunks at huge rates?

Thanks