LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DataSocket slowdown

Hi,

I'm using DataSockets to simply share a whole array of data from a server to a client for real-time remote experimentation purposes. The server simply appends the newest point to the end of the array once a new point is generated, and then removes the oldest point from the array if necessary to keep the size fixed at some specified maximum value.

I've noticed that if I allow the maximum array size to grow larger than 200 points, the DataSocket server slows down tremendously. For instance, if I specify that the array should grow to be a 500 points at the max and then begin cycling out old points, once 201 points are in the array, every DataSocket write afterwards takes an enormous amount of time. Is there a maximum array size supported by th
e DataSocket server?

I also looked into the buffered DataSockets example (and it works fine), but it doesn't suit my needs because it doesn't appear to run in LabView player. I tried signing all the VIs in the example, but the Player reports that the VIs in dataskt.llb (those VIs used in the example which are included with the Player) have problems in their block diagrams.

Any thoughts or suggestions would be greatly appreciated. I'm running all of this on Win2k.
0 Kudos
Message 1 of 6
(2,565 Views)
I used to use DataSocket too but found a number of performance/installation issues that were a pain. In the long run I changed to using VI server remote VI calls. I am currently passing a very large data structure and am having no problems with transfer rates.

What sort of transfer rate do you need? How often do you need to send the 500 values across the network?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 2 of 6
(2,565 Views)
Thanks for the suggestion about using VI server remote calls. I didn't even know that option existed, and after a precursory glance, it looks like it could be a viable option.

I need to send only new values to clients across the network once they become available on the server. I have no stipulations on the transfer rate, just as long as no points are missed by the client.

Do you have any suggestions as to where I can look for some examples on using VI server? I have some experience, but could use a good reference.

Thanks,
Pete
0 Kudos
Message 3 of 6
(2,565 Views)
There are numerous examples of using VI server to make calls to VIs on another machine. Check the examples in LV and on NI's web site.

But basically, all you do is open a reference to the copy of LV running on the other machine using the Open Application Reference function. The reference you get from this operation allows you to open a reference to the VI that you want to run. The only proviso is that the required VI must be open on the other machine.

From here on it's just like executing a VI using Call by Reference on your own machine.

In fact, handled properly, it can disguise the fact that you are even getting your data from a remote machine.

Also if the purpose of the remote call is to simply fetch data over the network, the t
arget will probibly want to be some sort of cache VI that hold the data is an uninitialized shift-register and is written in the host VI and read in the client.

However, there is nothing saying that the VI you call can't read a DAQ card or instrument on the remote machine and return the results to you. In that case, there wouldn't even necessarily be an application running on the remote machine...

If you have any questions after poking through a few examples, give a hollar.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 4 of 6
(2,565 Views)
Hi Mike,

I have a question about VI server security. I like your idea of using a data store that can be read by a client and written to by a server. That approach can actually help limit the amount of data sent to the client by determining how much new data has been added to the store since the last point the client read. However, this approach seems to have one drawback--a client can just as easily write to the data store by calling VI by reference and passing it some data. Is there any way to prevent this?

One solution I came up with was to create a password string and then have the server send it to the data store VI each time it wants to write some data. Then, at least, a client would have to figure out the password. The password wo
uld also be secure as long as the data store exists on the same machine as the server VI so that the password isn't sent as plaintext over a network connection.

Do you know of any other ways of handling this kind of security?

Thanks,
Pete
0 Kudos
Message 5 of 6
(2,565 Views)
IMHO, if you are trying to keep another developer out you are headed for a difficult time, but the password sound like a good start. The main thing is that the best you are ever going to do is the equivalent of a hook on a screen door, it keeps the neighbors kids or stray cats from wandering into your living room, but if someone really wants to get past it, they will...

No security is complete and the best of the automated system still in the end depend on the most basic of security devices--trust. Admittedly, some things will make it harder for untrustworthy folks to get in, but there is no perfect guard.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 6 of 6
(2,565 Views)