Scenario: I have three programs: a TCP Server (written in Processing), and Producer and Consumer (they are not Processing sketches). Producer produces an array of bytes. Producer and Consumer connect to the TCP Server, and Consumer “subscribes” to the messages coming from Producer (the TCP Server handles this).
When Producer sends a byte array to the TCP Server, this forwards it to the Consumer. The max. size of my array is around 31kbytes.
But I noticed that when the size is above (or around 10kbytes), occasionally Consumer does not receive the entire array; and many times it claims it has only received 7300 bytes (this figure occurs often enough not to be considered a coincidence).
I checked the size of the message received by the TCP Server; this is correct. So the problem can be either in the write call that the Server executes, or in the read call in my Consumer (which , I repeat, is not written in Processing).
To debug this, I will add a Processing Client, to see if this receives the message correctly; but does anyone know if “7300” means something in this context? This figure occurs too often when the full message is not received by Consumer.
Two guesses. One is that it relates to your network. Top search hit for TCP 7300 bytes mentions SMB and NetBIOS – see this passage:
Second guess (less likely) – if you periodically get wrong messages of exactly the same length, sometimes that might mean that the same error message is being encoded each time – so the error / error message text is accidentally the message payload, which is why the message is always the same length.
Sorry for not having followed the post.
Soon after my question, I realize that very often the part of the message I was receiving was coming in multiples of 1460 bytes (7300 = 1460*5). So 1460 looks like a “magic number”. But I also got a different “magic number”. The reason for these two different numbers is that the message could be fragmented -) when it is received by the TCP Server, and -) when it is received by the Consumer. The TCP server and the Consumer have different implementations of the TCP functions.
Luckily my original message contains a header, and some info from which the Consumer can compute its length. So I have to read from the TCP stream until I get enough data to complete a message, and keep what is left as the beginning of the next message.