The current implementation of the library uses the native LabVIEW TCP/IP VIs which do not support TLS/SSL communications required for Secure WebSockets.
The text was updated successfully, but these errors were encountered:
The move to an OO-based Socket API was designed to allow wss:// support to be added by creating additional Socket classes that encapsulate the SSL/TLS layer.
Two methods have been investigated/prototyped so far:
Using the .NET Secure Socket library - this would be for Windows targets only and the behaviour of the .NET Socket functions is not easily compatible with the native TCP/IP functions (e.g. timeouts).
Wrapping the NI-provided OpenSSL implementation - some prototyping on this has been done and some WebSocket client support functionality has been implemented but was not fully debugged and difficult to implement (due to the number of different ways of using OpenSSL e.g. SSL / BIO functions) and wanting to use a non-blocking socket. The other approach for this would be to wrap the OpenSSL functions to make them more easily usable in LabVIEW but not much progress was made in this regard.
At NI Days Europe 2019 in November, NI announced that SSL/TLS support would be added to the TCP/IP palette in LabVIEW 2020.
The intention is to develop wss:// support using the LV2020 Beta and release in time for the full release of LabVIEW 2020.
Initial experiments with the TLS/SSL support added to LabVIEW 2020 are promising but there are a number of small issues related to their timeout / error code behaviour.
I am intending to develop/release the TLS/SSL support as an addon package to allow continued support for older LabVIEW versions (>= LV2013) and the addon package will be for >=LV2020.
The current implementation of the library uses the native LabVIEW TCP/IP VIs which do not support TLS/SSL communications required for Secure WebSockets.
The text was updated successfully, but these errors were encountered: