LabVIEW "UDP read" does not read all genuine UDP/IP packets

[pawel]

Hello All

The UDP server (VC6 application) send about 500 genuine UDP packets followed by IP packets as necessarily to the LabVIEW application over the network (standard 100M). Those packets are translated and concatenated by LabVIEW (or Windows) functions and are returned by "UDP read" function as about 5 LabVIEW'ish packets.

Everything would be OK, but sometimes the last (or couple of last) genuine UDP packet is not read by LabVIEW, even though the EtheReal.exe is showing this packet. Sometimes, mean 70% of all tries.

I have tried to throw "UDP read" into a "high - priority" vi, strip out all unnecessary stuff, so it basically runs alone in a "while loop until timeout (500ms)", and still, it looses those packets.

Does anybody have a clue, where to search for a bug? Did anybody observed such a situation?

Thanks in advance.
Pawel

[Ben]

This is simply the nature of UDP.

UDP should be thought of as a type of advertising. It is usefully when one computer wants to advertise that it offers a service. like normal advertising, it is effective if at least one of the messages gets through.

There is nothing in UDP that tries to ensure a packet gets delivered. It is just "spray and pray".

Attempting to build a reliable sequenced data path using UDP will very quickly become an exercise in futility.

Ben

[pawel]

Hello Ben

I know there is no handshaking for UDP. The thing, which surprised me, is that EatherReal shows those packets comming to the machine, it saves them and you can browse them later on. LabVIEW can not, even though it is running in a single loop only acquiring packets. It is simply much slower.

I have solved the problem, as you also point it out, through the TCP.

cheers
Pawel

[Ben]

Hi Pawel,

"EatherReal" is a variation on a on a class of application commonly called "sniffers".

I co-authored an early version of a sniffer back in early 80' (Sniffer copyright 1983).

At that time (and apperently to this day) there was an option to set set the ethernet port into a "promiscuous" (Pro-mis-cu-ous, just incase this word gets filered) mode.

In the "P" mode the network interface does NOT filter out packets based on protocol type but asserted an interupt that would run a interupt service routine that we use to to transfer the data buffer off so we could write the data to disk (computer were to slow back then to decode and display on the fly).

So in Sniffers the UDP part of the stack never needs to get involved AND all data is handle the same, ie grab what you can as fast as you can.

To go beyond what I have said above I would have had to have dug into the internals of the UDP stack as imlemented on the OS you are using.

The last time I got that deep it was DECnet and LAT running on a VMS OS.

Let me summarize by saying what you have found.

UDP is an unreliable communications protocol.

If your data absolutely has to get there, use TCP.

Have fun,

Ben