Jump to content

UDP Read of Variable Size Packets


Recommended Posts

Hi all,

I had a couple of questions related to reading udp packets in Labview. I am receiving 100 - 200 Mbps of variably sized packets. The first byte in the packet specifies its size in bytes*4.

1) When I perform a read, I have no idea how much data to request, so I set an arbitrary size. It seems in doing this that I am getting multiple packets together and that I subsequently need to parse the data into packets after reading. Doing so seems to slow down the machine a bit and I'm nervous I'm dropping packets (see next point). I also tried reading only 1 byte, then reading X number of bytes based on that 1 byte, but that threw errors (I think it was error 113 about more data being available than I read).

2) How do I tell if I am overflowing the socket buffer? I am getting weird behavior that seems to indicate dropped packets occasionally but no error is coming out of the udp read function.

Thanks,

Jim

Link to post

Reading first byte to determine the number of bytes to read, then doing a second read of that number of bytes is the correct way to do this. Could you check what error you're receiving, and attach the code that demonstrates it? There's no reason that should return an error, and code 113 does not match your description of it.

Link to post

I suspect you might be getting a *warning* that there is more data than you read, but an error does not make sense, as ned said.

Link to post

And to add to that, based on the description you should just ignore it as your software is designed for this. You can check for this error code and clear the error cluster if it appears to ignore it.

VISA throws something similar as well.

(null)

Link to post

Hi all,

Thanks so much for the help. I had some errors in my implemenation (U8 vs I32) and bytes vs quadlets (bytes*4).

After fixing them the problem remains. I wasn't sure of the error off hand, but I confirmed it is 113. Unfortunately ignoring it seems not to work as there is simply no data returned. My guess is this is a Labview implementation that if this error occurs it chooses to retain the data for a subsequent read rather than require concatenation.

This error occurs on the first read. I thought it might be a startup issue but on subsequent read loops I still get nothing.

Thoughts? Thanks again for the help.

Jim

Link to post

Are you routing the error 113 back into the read node? The majority of LabVIEW nodes do not perform any significant function if there's an incoming error.

Link to post

I am not. There is no error input to the first udp read. The second udp read has an input but I clear the error if it is 113. However, I never get to the second udp read because the first udp read is always empty and I have a case structure around the second one in which it doesn't run if the first one returns no data.

Link to post

I'm not sure why that's not working for you. You should probably post your VI, just for clarity.

An alternative, though not as "correct" of a solution, would be to have a parallel loop constantly reading as much data as possible (if you can get that to work) and then dumping it onto a queue which is processed by another loop. The consumer loop would have to be able to figure out where packet boundaries are and I don't know how tenuous that would be for your application. If you wanted to add complexity, you could package the UDP data with a boolean that lets the producer hint at whether it's a packet boundary or not.

Link to post

I looked at the documentation for the UDP read VI, and I believe you are getting error 113 and no data on that first read because the one byte you attempt to read is part of a larger packet. From the documentation of the Max Size control of that VI:

max size is the maximum number of bytes to read. The default is 548. (Windows) If you wire a value other than 548 to this input, Windows might return an error because the function cannot read fewer bytes than are in a packet.

  • Like 1
Link to post

Way to read the documenation! Thanks.

I'm not sure how to improve the reading I have. I've tried two options:

1) Processing an entire "read" and concatenating a partial packet (if it exists) to the next read

2) Implementing a circular buffer.

The first was a lot simpler but performance was not great. The second was much more difficult and I didn't see much performance gain (if any). I think it is likely due to memory copying that isn't immediately clear to me. Ideally I would only have one fixed space in memory that I am ever working with for all packets, in addition to the memory generated for each packet that I pull out of the buffer.

I was sort of hoping this was a solved problem with a accepted way of handling it.

Finally, any ideas why I am not getting buffer overflow errors? Does Labview report this?

Link to post

I think you are not getting overflow errors because the operating system drops packets silently once the buffer is full. I have no idea why you are getting partial packets - the documentation seems to imply that LabVIEW only reads complete packets (I may be wrong on this). I think asbo's solution is probably the best approach to take with the issue of not reading fast enough.

Link to post

My apologies for misleading you, I suggested the standard approach for TCP and missed the note in the documentation that makes it unsuitable for UDP.

If you post your circular buffer approach I'm sure someone will be happy to suggest how it can be made more efficient.

Link to post

Thanks all for the feedback.

I haven't changed the default buffer size yet so I'll give that a try:

http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D

I'm also doing minimal processing (read a couple of bytes and conditionally throw onto a queue) in addition to the packet splitting, so I hadn't split it up yet into separate read and split loops but I'll try that next.

After some brief web searching it wasn't immediately obvious if there was some system way to detect buffer overflow. I'll probably just do some testing and convince myself that at high rates exceeding my typical usage the system seems stable.

The partial packets may be indicative of a buffer overflow. I'm going to work on getting the system to be more reliable then see if the problem still exists.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By iayestaran
      Hi everyone,
      I am perceiving some strange behavior in my UDP connections. Every time I re-start my cRIO 9063, the UDP Write block outputs ERROR 66 (LabVIEW:  The network connection was closed by the peer. If you are using the Open VI Reference function on a remote VI Server connection, verify that the machine is allowed access by selecting Tools>>Options>>VI Server on the server side.) and it does not transmit. 
      The most bizarre thing is that if I simply stop the execution and re-launch it again (given that I am executing the code of the cRIO in Debug mode from a Windows laptop), the UDP connection behaves perfectly well. The only time it fails is the first time I launch the program after I reset the cRIO. For me, it looks like some service is not properly initialized when the cRIO is started.
      I attach a picture with the UDP connections of my LabVIEW RT program. The 'Comms RX' VI simply calls the 'UDP Read' function, and the 'Comms TX' calls the 'UDP Write'. The 'Open UDP Conn' also simply calls 'UDP Open'. 
      Can anyone help me?

    • By Calorified
      Hi there,

       

      I have RIO in a Windows VirtualBox inside a Ubunbtu Host OS.

       

      I am sending data from a C++ program in the Ubuntu Host system to labview within the Guest OS.

      I can receive the data on labview installed on the windows guest os. Below is the png of the Windows working program.

       



       

      But when I tried to send the data to myRIO, I was getting a udp read only error 42.

       

      Somewhere on the NI forums, someone suggested the net address of the "UDP Multicast Read-Only" vi  be wired to the address of the RIO which I have done below

       



      .

       

      Now, the code runs on myRIO but I can't receive any data on RIO. The multicast address I am sending to from Boost Asio C++ is 235.255.0.1 on port 30001.

       

      The RIO has a public ip of 172.22.11.2 and I set up a static ip address for it in NI MAX as the address of the UDP Multicast : "235.255.0.1.

       

       

       

      At this moment, I do not see what I am missing. All firewalls have been disabled and I have set the permissions for RIO through the Windows security page.

       

      Any help would be appreciated.

      Thank you!

    • By Calorified
      I have a UDP connection setup on a Windows 7 machine that runs an IMAQ code. The machine can send and receive udp connection so long as data being sent it is on the same machine. When I send the code from a different process (running on Windows 7), I am able to read the data on the RIO udp receiver VI (running on the Windows Host) as well.
      So I changed the sending program to a labview code and the udp receiver won't pick up the data.
      Could there be something I am missing?
      Attached are the PNG files (lava1 is the talker (same as the Kinect Code VI) while lava2 is the receiver).
      Any clues would be appreciated.


      Kinect Code.vi
    • By ShaunR
      Name: Transport.lvlib
      Submitter: ShaunR
      Submitted: 27 Aug 2011
      Category: Remote Control, Monitoring and the Internet
      LabVIEW Version: 2009License Type: Other (included with download)



      Transport.lvlib is a LabView API to simplify and accelerate networked communication development.
      It simplifies development by abstracting TCPIP, UDP and Bluetooth and TLS interfaces
      into a single polymorphic vi which is a thin wrapper around the conventional
      open, read, write, close and listener VIs for all the network interfaces.
       
      Features:
      Supports TCP/IP, Bluetooth, UDP (p2p, broadcast and multicast) and TLS.
      Supports symetric encryption (blowfish).
      Supports compression (zlib).
       
      INSTALLATION:
      Run the supplied installer and follow the instructions.

      Click here to download this file
    • By hilbert00
      Dear LabVIEW friends, 
       
        I'm running into a problem distribution my application. This is opening a UDP connection registering a service as explained in the documentation. It is perfectly working when running within the development system and also as a standalone application on the development computer. 
       
      The problem is with the installer and the distribution package. When I install the application of a different computer, it fails with error 63 at the Open UDP. Reading the available documentation it looks like it is a Service Locator fault. So I checked and indeed the NI Service Locator is not running on that machine and it is not even distributed with the installer. 
       
      I've tried to go through the list of additional installers in the Installer build properties but couldn't find anything useful. 
       
      I'm sure I'm doing badly something wrong, can you help me in sorting this out?
       
      Cheers,
      toto
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.