IP to string node issue

[sathiya]

Hi,

   In our application we are exchanging data on every 50 ms between client and server systems via UDP.  The data exchange between client and server was happening without any issue except the memory leak. Later we found that the IP to String function with dot notation input as false on the UDP listener creates the memory leak. So we changed the IP to String function with dot notation input as true then the memory leak issue was gone.

Is anybody experienced such memory leak issue with the IP to String Function and how managed this issue? what would be the reason for the memory leak with the IP to String function with dot notation input as false? 

Thanks

Sathiyanarayanan

[The_Devil]

Hi,

I have myself not faced such a problem but I have used the inplace structure for memory management. You can refer to the following links it might be helpful.

http://zone.ni.com/devzone/cda/tut/p/id/6211

http://digital.ni.com/public.nsf/allkb/771AC793114A5CB986256CAB00079F57?OpenDocument

Let me know if it helps.

Thank You.

Regards,

Priyank 

[altenbach]

If dot notation is false, the function needs to query a DNS server, something I would probably not do every 50ms. Querying a DNS server can be slow, so maybe you get a built-up of DNS lookup requests. Can you open a command window and do a "netstat -n" during run. how many connections are listed?

What is the purpose of your use of the IP-to-string function. How often does the IP change? Is it the same most of the time?

What is your LabVIEW version? What is your OS? Can you show us some code on how you are using this?

---

The Devil wrote:

I have myself not faced such a problem but I have used the inplace structure for memory management. ...

---

This problem cannot be solved with the in-place structure. Your answer is completely meaningless in this context. Can you explain your thought process that led you to suggest this as a solution? Makes no sense to me! 😉

Message Edited by altenbach on 01-24-2010 09:57 PM

[tst]

Come on Altenbach. It's The Devil. Did you really expect something helpful? 😉

[The_Devil]

ooohhk... every1.. 🙂

But I never meant for this and I agree its not useful for this query but I thought of sharing it with the person here. I am sorry but I am sure it gave you all a good laugh.. 😄

So cheers..!!!

The DEVIL

[sathiya]

Hi,

    Sorry for my delayed reply. Today I executed the same application with dot notation false and checked with netstat. The number of connections were not got changed. It was same always, but the memory was keep on incrementing....

 We are using LabVIEW 8.6, WinXP. The main reason we were using IP to sting function in conjunction with the UDP read is that our application receides on the system can receive data from multiple System on same logical port number and each system will send the data on different application protocol on UDP. So based on the source system name, our application decides which application protocol to be used to parse the data. Now we made a workaround by adding a lookup table for IP numbers for all the system which will communicate data to our application. Based on the Source IP number received from UDP read function, our application will find the system name on Look up table and selects the application protocol to parse.

Though we made workaround still we are not able to find the reason for increasing the memory with IP to string function with dot notation false

Thanks

Sathiya

[altenbach]

---

sathiya wrote:

Though we made workaround still we are not able to find the reason for increasing the memory with IP to string function with dot notation false

---

Can you tell us you exact LabVIEW version and OS, and maybe attach some simple code that shows the memory leak so we can reproduce it.

Do all IPs have valid public names? What are your DNS settings? Do you run any kind of personal firewall software?

What do you mean by "lookup table"? Couldn't you simply add these names to the "hosts" file?

Your program could also maintain a cache so each IP needs to be translated only exactly once.

[rolfk]

Protocol versions based on the senders IP number sounds to me like a complete mess to manage that will at some point really go bad. Either you should at least assign new port numbers on protocol changes (not very smart  sure to cause its own problems over time) or better yet include protocol version information in the data stream.