how labview handles UDP fragmentation

[Hazkel]

I am building a 2 simple UDP communication applications. (one for many clients, and one for server)

• it is 2 way (read/ transmit)
• many clients - one server
• data is not critical (i.e both client and server need only  the most-recent value)

Attached is screenshot of client and server applications.

To my understanding the UPD protocol does not guarantee data integrity so packed my be received fragmented or not at all.

My first question is - what does labview do when this happens?
I see three options:

1. it transfers data in a fragmented manner (for example if original data is "ABCD" it will be received as "CDBAF"
2. no data will be received by Labview (i.e. data will be discarded and "UDP read" will give Error56 - timeout)
3. the "UDP Read " will give another error

Which scenario of above is true?

My second question is more tricky, and not pure Labview related.

I don't expect a definite answer for it. But will much appreciate your best answers based on your experience.

The network is WAN (via internet and not local network).

What will be the probability for data fragmentation or data loss.

I intend to have about 20 clients each one of them sending ~1K bytes of data every 1 second.

What percentage of data loss should i expect (~1%, ~10%, ~50% ?).

Thanks

[GerdW]

Hi Hazkel,

it transfers data in a fragmented manner (for example if original data is "ABCD" it will be received as "CDBAF"

LabVIEW will output UDP packets in the order they are received.

no data will be received by Labview (i.e. data will be discarded and "UDP read" will give Error56 - timeout)

LabVIEW will output data packets in the order they are received. Why should there be a timeout as long as you receive any packets?

the "UDP Read " will give another error

How should LabVIEW detect missing packets or "wrong" order of packets? There is no way to detect this in the network stack!

You could detect wrong packet order when there is any marker in the packet…

[Hazkel]

Thank a lot for the quick reply.

I understand that the order of data send by different  "UDP write" command my be compromised. (due to packet fragmentation)

and I have found and article dealing with Reassembling Out-of-Sequence UDP Packets in LabVIEW.

And apologize for the next question:

Is the any risk that data order sent in a single  "UDP write" command will be compromised?

to be more specific: if I use a single "UDP write" command to send a flattened string of a cluster that contains several KB of data:

I understand there is a risk data will be discards (packed loss)

But is the any risk data will be corrupt (due to fragmentation)?

[GerdW]

Hi Hazkel,

if I use a single "UDP write" command to send a flattened string of a cluster that contains several KB of data: I understand there is a risk data will be discards (packed loss)

For large UDP message there is a risk that some network components will filter and cancel them! Usually UDP messages should be limited in size, LabVIEW uses 548 bytes by default…

Read the LabVIEW help for the UDPRead function!

Larger UDP messages might travel through your local net without problems, but that isn't guaranteed outside your local net.

But is the any risk data will be corrupt (due to fragmentation)?

I'm not an expert in network stacks and UDP/TCP implementations…

[Mark_Yedinak · Accepted solution]

In today's networks it is very unlikely you will see packets fragmented smaller than 548 bytes. If you format your and send your data using packets of 548 bytes you will most likely not have any issues. Data within a single packet will not be reordered. If your data is several kilobytes and you send it in multiple fragments of 548 bytes you may receive those packets out of order and you would need to order them appropriately. You may also miss a fragment. If you need to insure that you receive complete data you will should fragment your data into 548 byte chunks and include some type of packet header which include a packet ID and a sequence number. That way you can reassemble the data and detect missing fragments. You stated that you didn't need all of the data so this type of approach should work.

Data loss is unknown since it depends on the networks and the paths that your data will traverse. Not to mention that firewall rules and other types of data regulations could affect your data. You could experience 100% between one client and the server and 100% loss between another depending on the network configurations, the routes, the firewalls the data traverses, etc.

[Hazkel]

Thanks a Lot for the detailed and enlightening reply!

 your remark :"You could experience 100% between one client and the server and 100% loss between another depending on the network configurations, the routes, the firewalls the data traverses, etc"

Fits my personal experience with communication over the internet (opposed to local network). I Never built a multi client UDP application. But rather a single client TCP application.

And indeed I have seen various problematic scenarios at the client side. (Need to cancel anti virus, open firewall ect).

My main problem which is a bit off-topic is: I have good control on my PC and my companies network. But I have limited to none of  control on my customers PC and network.

Is there any hassle-free method to pass data via WAN.

I believe that non of the technics mentioned in Transferring Data over a Network are hassle-free since all of them go down to raw TCP or UDP communication.

 

[Mark_Yedinak]

Use a RESTFUL protocol approach. It will be TP so you will will have individual connections for each client at the server end but the data will go over HTTP which in general makes it through most firewalls and virus scanners.