Single Message Sent is received as multiple Messages

[christandlg]

I have observed that occasionally (depending on message length) a single message sent by either server or client is received as multiple messages by the other party.

Steps to reproduce:

1. add waveform chart indicators to Client Single Connection and Server Single Connection examples to display received string length
2. build .exe from examples and run server and client on separate machines (issue also exists when both are running on the same machine, but much less frequent)
3. send a large payload (in my case, 8 MBs of 'a')
4. observe that waveform chart displays multiple received string lengths:
   

[christandlg]

wireshark reports correct number of bytes transmitted:

[samsharp99]

Hi @christandlg - thanks for raising the issue. There are a couple of things this could be:

• The 'read' is timing out and returning the partial data/message (the timeout error is dropped in the example VIs)
• There is known limit on a single frame of 2048MB but we're probably not hitting that here
• Some other bug/issue that I'm not aware of

For large messages, the use of WS framing is recommended but the implementation of it in my library is not extensively tested.

Testing locally (i.e. localhost with the client running on the same machine as the server), I can do 60MB no problem (but it start to take a long time):

It would perhaps make sense to distinguish (e.g. with a different error code) between 'no data received' and 'data received but did not complete within timeout period'.

[christandlg]

* The 'read' is timing out and returning the partial data/message (the timeout error is dropped in the example VIs)

I think this may be the core issue. It would explain the inconsistency in received message length and also explain !15, if in WebSocket.lvclass:Low-Level Read.vi a byte is parsed as opcode that actually is part of the message payload.

For large messages, the use of WS framing is recommended

How can I try that? Do I need to control the Finished? input of WebSocket.lvclass:Low-Level Write.vi ?

[ninjaboy667]

@samsharp99, @christandlg,

Have either of you found a solution to this?

To recreate, I added the following code to the Media Mongrels Example .js:

function massivesString() { let str = ""; for (let i = 0; i < 2000000; i++) { str += "a"; } return str; }

Then I add the following within the end connect function to call
async function spam() { while (true) { let aString = massivesString(); const payload = JSON.stringify({ data: aString }); send(payload); await new Promise(resolve => setTimeout(resolve, Math.random()*1000+700)); // Wait for 1 second before sending the next message } } spam()
Working on a production app, and this happens with random JSON payloads (very infrequently). Looking for the best way to handle this. Currently I have my cRIO disconnect on any bad OPCode. Looking for a way to handle this and keep the connection alive.

[ninjaboy667]

@samsharp99, @francois-normandin @christandlg

I think I found the issue! It has nothing to do with the size, rather the timeout logic, in relation to reading. I think it could happen for any device than with infrequent communication, no matter the size of the message it sent while the vi is close to timing out.

function massivesString() { const eightMB = "ab".repeat(4 * 1024 * 1024); return eightMB; }
Sending the data repeatedly, observe the following waveforms which record the length of the string received, which should be fixed:

This is a 10000 (10s) timeout.

Then here is with a 500 timeout (0.5s)

Then finally a timeout of -1 (which should be wait forever)