Detecting UDP transmission status

[IanR99]

Well, I have to devise a UDP test program. A quick scan of the LV help and I had a couple of UDP VIs that send and receive - wow. By putting the UDP Write VI and UDP Read VI into loops I have the basis of an effective link test. After a bit of tweaking to allow me to set block lengths, addresses etc, all is well. So to control everything I have a Wait VI inside the TX loop that waits for a number of ms set by a control on my front panel - the shortest wait I can get is 1ms - that being the resolution on the PC clock. However I am only using a fraction of the 1Gb network (<1% according to task managers Network status tab) lengthening the block towards 65Kbytes ups this number but still gives a low % use - clearly I need to hit the TX faster than once per ms. Heho I try writing a delay loop based on doing two random number generations and multiplying the results (10 of these on my m/c is approx 1 microsecond) however even doing 1ms worth does not have the same effect as a 1ms Wait - I add a 0 Wait (help says this relinquishes the hold the VI has on running but that has no discernable effect. What happens is the TX VI reports UDP errors and dies. After a lot of experimenting I hit on the 'simple' expedient of sitting in a loop on the Write VI only leaving when I get no error or an error other than 55 (Error 55 being port busy) this takes the bandwidth up to over 90% (on occasions and >85% consistently. I did try limiting the number of retries but even a limit of 300 was sometimes exceeded while just hitting UDP Write till error 55 goes away always works (just). At the receive end the number of good blocks drops with high speed - but not badly and that is what I would expect. So my ultimate question is - Is there anyway, other than the '1 ms Wait' or sitting in the 'UDP Write not returning 55 loop' of sensing the status of a UDP port or even waiting till the port is free to be written to. Secondly, leaving the link running in this high speed state will eventually 'crash' (after 10 - 20 minutes) bizarrely the Task manager shows the link still at >85% but the RX end just times out - if I leave the RX PC alone and reboot the TX then the timeouts stop and the RX is happy - this suggest that something in the TX (like port address etc) is becoming corrupted when pumping out 65kbyte blocks at 900kb/sec - but then what do I expect hammering the link at that speed - so second question is any thoughts on how to find where this issue occurs and has anyone else seen this?

[Ray.R]

Can you post your code?

Although not the same problem as you are having, I saw this thread which may be interesting to read:

http://forums.ni.com/ni/board/message?board.id=170&message.id=380491&query.id=662379

[Mark_Yedinak]

What specifically are you trying to do? Your application sounds like a typical denial of service attack. Also, assuming this is a legitimate application some code would help for making suggestions.

[IanR99]

I am attempting to establish the maximum reliable speed of a UDP link and teaching myself about UDP as I go. I seem only to be able to attach 3 files (need 4) so will send 4th as separate message. Please be kind about my code it is experimental 🙂 Two of the VIs send and receive a simple message while the other two put/check a ckecksum on the message (could be removed with no great harm as UDP puts on its own chksum). To run 'full tilt' set 'ms delay' and microsecond delay' to 0 in TX VI. Ignore microsend delay code it was experimental. Set block length parameters to big values to see high data rates (e.g. 65000 - but set max block length to read to 66000 before running Read VI. VIs will work both running on same machine (localhost in TX). You will have to work out your own network addresses to run over a real link.

[IanR99]

Fourth VI - well both checksum VIs to be sure.

[gt3000]

Hello IanR99,

Before you continue, it might be good to look at some of the fundamentals of UDP, and its use in LabVIEW.

UDP Communication in LabVIEW

KB 4AL9NF2L: Lost UDP packets at high transfer rates

KB 39J9C1HD: Communication using Multiple IP addresses

Listening to see if a port is ready could be like trying to have multiple connections on the same port.  The third article could provide you with further ideas.

Which version of LabVIEW are you using?

Which OS are you using?

Regards,

[IanR99]

I am using LV 2009 under XP Professional SP3 on both PCs.

I am just intrigued by how I might get to the limits of UDP performance. For example the UDP Write VI returns error 55 to say that the port is busy - it must therefor be able to detect that busy condition - how could I detect the same thing without doing a write? On one of the pages you directed me to there is talk of VIs to sense/change the size of the Windows buffers through DLLs - I will download and study them.