01-22-2018 10:40 AM
I realize that the Idea Exchange is the more appropriate place to post this request. But as you know the request has largely been ignored. By raising the issue here as well perhaps NI will see that this is a bigger issue in general and perhaps they may actually do something about it. As a LabVIEW Champion I can assure you that I am raising this issue directly with NI in hopes they will address it sooner rather than later. Unfortunately with NXG out now development resources are split across the two platforms and I can envision legacy LabVIEW getting fewer and fewer new features. And at the moment NXG is not quite ready to be a replacement yet.
01-23-2018 03:51 AM
Hi Ettepet,
Our team has done some digging and we do not have any examples of how to use TCP/IP with primal functions. This does not mean that it cannot be done. Because SSL is just an additional abstraction layer on top of TCP IP, the functionality can be implemented. However, it would be a lot of work. We have come up with a couple of ways of implementing this on a high level.
1. We use OpenSSL with webservices on our cRIO's. Basically it just means that we encrypt the data before we send it through a dll. You could implement this thinking and use ready-made windows compatible dlls to encrypt and send the data. What you need to do is write a LabVIEW wrapper for that dll (pretty much what the server example posted before is doing).
2. Write your own encryption scheme and encrypt the data before sending it through the TCP/IP primal functions. In this model you would call a specific dll or external code to first encrypt the data and LabVIEW would only handle the communication over TCP.
Also, if encryption is required, would it be an option to implement it in a more out-of-the-box manner rather than using raw TCP/IP communications?
With regards to the Idea Exchange page, out R&D team monitors these posts and if enough demand is shown for this. I can see that there is demand and the more people interact on the idea page, more likely it is to be picked up by R&D.
Riley Ilieva
Applications Engineer
National Instruments
01-25-2018 06:19 AM
So I still need the code for the Client side, as was my original request.
@Riley_Ilieva wrote:
With regards to the Idea Exchange page, out R&D team monitors these posts and if enough demand is shown for this. I can see that there is demand and the more people interact on the idea page, more likely it is to be picked up by R&D.
Unfortunately this is not the case here. There should not have been a need to ask for implementation of secure TCP/IP connections in LabVIEW in 2016. It should have been done by NI years earlier.
Voting hasn't helped this closely linked 8 year old (!) IDEA either: Native SSH and SFTP Support. Just like with SSL TLS Support its status hasn't been changed from "New" either.
Hopefully we can solve this through forum shared .NET code examples, and not be reliant on an extremely ignorant NI.
02-02-2018 03:59 AM
Hi,
We have passed this request to R&D who are also looking at feature prioritization for future versions. They plan to implement a handful of idea exchange features in each release. They are currently evaluating this specific request for a future version of LabVIEW.
The server side example was not provided by our engineers or R&D. It was developed by a forum user. It is possible to incorporate this feature in the client side but as this is not currently a feature of LabVIEW, it would take some coding. This could explain why a client example has not been developed yet.
Kind Regards,
Riley Ilieva
Applications Engineer
National Instruments
04-03-2018 08:44 AM
The implementation of the SSL client is bit tricky in LabVIEW. When I was designing it to work for my server code (that is posted here), LabVIEW was hanging more than often. Also I needed asynchronous communication and which cannot be supported by only LabVIEW .net calls.
So I ended up writing a C# code that implemented the SSL client functionality. I used that DLL and registered the connect/authenticate/read/write events using event callbacks functionality in LabVIEW.
So there is a solution but not really straightforward.
04-04-2018 03:34 AM
@RJ_15 wrote:
The implementation of the SSL client is bit tricky in LabVIEW. When I was designing it to work for my server code (that is posted here), LabVIEW was hanging more than often. Also I needed asynchronous communication and which cannot be supported by only LabVIEW .net calls.
So I ended up writing a C# code that implemented the SSL client functionality. I used that DLL and registered the connect/authenticate/read/write events using event callbacks functionality in LabVIEW.
So there is a solution but not really straightforward.
Thanks for sharing your experiences RJ_15!
Why would the client code be less stable than the server side? You would think that the calls were just the corresponding calls on the client side.
Also, it sounds as if you first created a synchronous version of the client side. Do you still have any code from that?
05-12-2020 04:30 AM
Hi,
I would like to build a MQTT client with TLS support. Do you have any recommendation on how this might be achieved?
The MQTT client is something like the one here https://forums.ni.com/t5/Example-Code/MQTT-Client-API-in-native-LabVIEW/ta-p/3520582?profile.languag...
Do you have any reference or examples of using any .net DLL with labview to enable TLS support for the MQTT client?
Thank you for your kind attention.
regards