Matlab UDP randomly missing data

I have a test I would like to run for many hours. It is very simple, I send a command to my network device and expect an acknowledge message back. I utilize fwrite and fread to send/receive these messages.

Sometimes when I set this test to run overnight I find the next morning that the test failed to receive an acknowledge. The response I expect is only 4 bytes long: 0x01; 0x7F; 0x06; 0x10.

I can look at my UDP socket after this failure and I noticed in the Read/Write state there were "BytesAvailable". Looking here I found 3 bytes: 0x7F; 0x06; 0x10. It appears that the socket failed to read the first byte.

Like I said before, this happens very intermittently and I haven't found a way to reliably reproduce.

Does anyone know what could be causing this, is this a known issue, or maybe a way to work around this issue? Thanks for any help!

[Walter Roberson]

Are all 4 bytes stored in the same packet? Or are those separate packets?

With UDP you need to assume that whole packets might go missing without a trace, and you should expect that any one packet might have its bytes corrupted (not in modern ethernets but possible still in wireless).

However, if the packet is received then leading bytes of the payload should not be missing (in old ethernets, trailing bytes could go missing due to faulty equipment.)

In your situation, is it possible that all 4 bytes were received in the socket, but that one of those bytes has already been read out of the buffer?

[Marshall]

Sorry for not clarifying and thanks for the reply Walter.

Yes, both the command and response are each a single packet. The 4 byte payload is in a single packet.

You do bring up a good point that maybe that leading byte was read out of the buffer already. However, I'm not sure with my application this is possible. I will not send the next command message until I have verified that I have received the 4 byte ack. And the ack (or any other message) should never be sent without the command. So I do not think I could be receiving 2 acks around the same time, causing the first byte of the second ack to be read in with the first ack. Also, DatagramTerminateMode is 'on'.

[Marshall]

Found out a little bit more information. I am comparing the bytes I get from the udp fread with the set of 4 bytes I expect. When the test fails because I do not receive the acknowledge I have compared the first byte I expect (0x01) with the 4 bytes and obviously failed. This is then the state I described above where the remaining 3 bytes are left in the UDP buffer.

So the socket did not fail to read the first byte, but instead read the first byte only. These bytes are the payload of only one packet so I don't know how it would be possible to only get the first byte (and obviously the rest of the bytes are in the buffer...)?

[Marshall]

I caught the error on Wireshark. The packet looks normal.

Answer 1

[Walter Roberson]

datagram terminate mode means that the data becomes available with each datagram instead of waiting for a terminator such as linefeed. But becomes available means it goes into the buffer. If you only ask to fread() a single byte then the remaining bytes stay in the buffer.

You can ask to read (object).BytesAvailable bytes from (object) and then use the bytes from where you store them instead of reading as-you-need-them.

[Marshall]

Thanks for the reply Walter.

I currently was not using the size parameter in fread, just the object. It's curious as to why most of the time it reads all bytes fine, but then when it wants to it only reads the one byte?

I don't know that reading a size of obj.BytesAvailable would work though. In the failure case where I read only one byte, wouldn't BytesAvailable at that time be '1' - thus producing the same result, or is fread literally just deciding it is lazy and only wants to read 1 byte this time.

I may be able to work with making sure size is set correctly. For this example I could always just have it be '4' for my four expected bytes. I will make this change and continue testing to see if the problem goes away.