LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DataSocket and datadasocket Firewalls

Hi,

I am planning to build and application that distributes and collects data fro multiple clients via internet conection. I am quite fond of the datasockest server approach due to its simplicity.

I do not have much experience with datasocket and have two major concerns:

 

1. Though I have full control on the server side PC running the datasocket server and the server-side VI. (i.e. I can Disable firewall, define static IP , and most importantly -port forwarding). I do not have any control on the client PC that is running on the client application.

I have read article http://www.ni.com/white-paper/12402/en/. But still do not understand what has to be done on client side. I know for a fact that when the client will install Labview runtime and when he will run my application (exe program) he will be prompted by the windows OS to "allow access to labview program" (or somthing like that...)

Is this the only step my clients should do to configure there firewall. I am afraid I can not ask them to do any action beyond approval my application access during installation.  Should I be concerned from other issue, related to security form the client side? (clients are pribably regular domestic clients, with avarege routers).

2. Please have look at the diagrams. is this an acceptable approach fro multiple client connection? (i do not plan more than 10 clients, so scalability is not a big issue.) the diagram ilustrates application runing on each clients PC. And VI running on server PC colecting data from 4 clients.

 

Thanks!Client.JPG

 

Client.JPG

0 Kudos
Message 1 of 6
(4,041 Views)
My advice is to avoid datasockets. I have tried them several times over the years, and never with a good result. VI Server is reliable and easy to use also.

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
(4,016 Views)

Thanks for the honest reply...

The problem is I do not want to be fully dependent on network and Internet connection.

As a fallback strategy I would like my application to run on the client side even if no internet communication is possible. (This of course undermines the whole remote data sharing concept, but for my needs - a "dis-connected" application running on the client side is much better that an application that is not running at all...).

So I think VI server is not a good solution for me.

I am just thinking out load maybe building my application on simple TCP communication will be more reliable and require less security concerns than datasockt?

 

0 Kudos
Message 3 of 6
(4,003 Views)

As you pointed out from the NI White Paper, DataSocket uses TCP port 3015 so it will need to be allowed through the firewall.

 

Using direct TCP will allow you to define the Port(s).

 

I would suggest you take a look at the below example for reference when using either DataSocket or direct TCP.

 

If you decide to go with DataSocket, you can always create a VI that programmatically controls the DataSocket Server from the reader VI so it starts as soon as you run the reader VI.

 

Sebastian.

Download All
0 Kudos
Message 4 of 6
(3,971 Views)

Thanks Sebastian,

 

My main concern regarding the port opening is what happens on the client side.

As for the server  side I have full control on the network and PC settings.

The client remote site is out of my hands. I do not have access to the client side router, nor to the operation system.

Only thing I can hand to the client side is Labview runtime and the compiled application. (exe file)

I wonder if besides accepting certain conditions that are presented to the customer during labview runtime installation I should be afraid on other restrictions thay may raise up.

 

I hope I was clear...

 

0 Kudos
Message 5 of 6
(3,967 Views)

The type of restriction you can come across depend entirely on the hardware and software architecture from your client (OS, Firewall, Anti-Virus).

 

Instead of guessing what restriction we can stumble upon why don't we do a quick test with the DataSocket example? Perhaps you can send them the Reader VI and with the correct URL from the Writer VI you should be able to see the example data. 

 

If your customer has their router/firewall and security settings (Win XP, 7 or 10) set to default and the port 3015 enabled, most likely you should not have any issues at all, but its better to do the test.

 

Let us know if this works.

 

Sebastian.

0 Kudos
Message 6 of 6
(3,939 Views)