Sheffield LabVIEW User Group

Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.

Re: WebSockets: Bringing LabVIEW to the Web

I had some time to dig into the code this morning and want to check my understanding.  Server Main.vi is the UI for the server and fires up the WebSocket Server.vi.  The WebSocket Server.vi listens for clients, and when a client makes contact over TCP it spins up a ConnectionHandler.vi.  So the WebSocket Server.vi is a TCP listener that spins up ConnectionHandler.vi clones, which act as the actual WebSocket interface.  So each thin client gets its own ConnectionHandler.vi AKA WebSocket interface.  I like how you use the user events to handle broadcasting data to all registered ConnectionHandler.vi listeners. 

I understand that if I wanted to open this up to the internet outside my LAN I would need port forwarding and a DNS hosting service, what are the security concerns of using web sockets outside of a LAN?  I can google this question, and will do so, but you have context and experience so I thought I would lob it at you as well.

CLA, CLED, CTD,CPI, LabVIEW Champion
President at Composed Systems
Using LV 2016, 2015, 2014


Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.
0 Kudos
Message 21 of 25
(2,056 Views)

Re: WebSockets: Bringing LabVIEW to the Web

Yes, you're spot on regarding the architecture. It's a great architecture (I don't claim to have created it!) for any network handling when you need to support multiple clients connecting on a listen port. It obviously makes passing data around a bit more complicated but user events are ideal for being able to 'broadcast' data to every connected client.

You wouldn't necessarily need a DNS hosting service - you could have a static IP address. Having a DNS record or using a dynamic DNS service just makes it easier to remember the address.

There are no particular security concerns with 'web sockets' that don't apply to any other network service (e.g. opening up a HTTP web server or any other type of network service). My library doesn't support 'secure' websockets connections with SSL but it is in the spec which would secure the data in transit. Anything you read on the net will probably apply here too - preventing unauthorised connections, preventing denial of service attacks, securing data in transit etc.

0 Kudos
Message 22 of 25
(2,056 Views)

Re: WebSockets: Bringing LabVIEW to the Web

I wish I had run into you at NI Week last August, I am realizing that I have a bunch of questions.  With websockets, is the client always a thin client in a web browser?  For some context, if I had multiple systems producing data it doesn't seem like it makes sense to have each system act as a websocket server, it seems like I would want a centralized server and have my systems act as clients, while also having thin clients in a web browser.  Assume its all on a LAN, it seems like websockets could provide a way to build a thin client that allows users to get real time feedback from systems while also allowing the users to send requests for the systems perform "safe" actions.

Would this be misusing the websockets?

CLA, CLED, CTD,CPI, LabVIEW Champion
President at Composed Systems
Using LV 2016, 2015, 2014


Don't forget Kudos for Good Answers, and Mark a solution if your problem is solved.
0 Kudos
Message 23 of 25
(2,056 Views)

Re: WebSockets: Bringing LabVIEW to the Web

In our use case, we have test stations that all act independently of each other. The engineers want to be able to view the current status of a test, and in the event of something not looking right, be able to send a remote 'shutdown' command. We're talking a very low number of people accessing each one at a time.

If you wanted to have a large number of clients connecting, then it would make more sense to have a centralised server which receives data from each test system and serves the thin clients. I think that's how the LabSockets solution works - it has to have an intermediate server between the thin client and the test system. This allows you to handle higher numbers of connections without impacting on your test system. I probably wouldn't use LabVIEW for this - something like node.js might be more suitable for serving some web files and dealing with the websockets connections. Having this intermediate server would also introduce another source of latency - one of the things I liked about websockets is that it offers much lower latency than a HTTP request - which is what allowed me to use it for my Tetris project).

My library does actually support being a websocket client as well as a server - I've written seperate LabVIEW applications which communicate directly with the main application's websocket server (using the same library).

0 Kudos
Message 24 of 25
(2,056 Views)
Highlighted

Re: WebSockets: Bringing LabVIEW to the Web

Hi Sam,

 

First of all, BIG THANK YOU!! for this shared code. I love it. 

 

Can we use this code for multiple web client and single LabVIEW server? 

0 Kudos
Message 25 of 25
(1,553 Views)
Reply
This is an open group. Sign in and click the "Join Group" button to become a group member and start posting.