The WebSocket.lvclass:Socket Read.vi and WebSocket.lvclass:Socket Write.vi don't use the Socket property which already exists for the class. If it used the property nodes, it would make it more consistent and easier to track down changes to the socket (changes only occur in one VI).

Hi I'm using this very nice library

to write a data, millions data, to check connection, to reconnect, everything works perfect.
But to receive the data, I have a issue and I cannot solve it. it works only for 10 min and then instead of arrive data and go to code 0 it stays on code 56 and even if I try to read on 56 I read nothing. the connection is still good.
What I have to do?

Could anyone help me please?

thanks
Rafael

The webocket protocol states that a reason can be given by the endpoint, when sending a closing frame. It should be a two byte code (1000 for "everything is fine") followed by an optional utf-8 encoded message. Python's websockets server generates an error, when no code is sent, assuming something went wrong.
It would be good to send a confirmation that closing was expected.
I could fix my issue by changing the "close frame.vi" as follows:

Download (valid until 2020-01-31)

I would recommend to make the Ring Menu into a Control and use it as an optional input. Then one can program a client that automatically closes the connection with the correct error code, when e.g. a binary payload instead of an expected text payload is received.

I was experimenting with MQTT over Websockets this weekend and my local server would connect fine, but fail to connect to HiveMQ's online broker with error 52 (invalid handshake). I traced the issue to a case insensitive header response from the HiveMQ broker.
Although this is very unusual, RFC 2616 does state that all HTTP headers should be matched regardless of case sensitivity.

For example, the server's response was of this sort:

HTTP/1.1 101 Switching Protocols
upgrade: websocket
connection: upgrade
sec-websocket-accept: +he/auQq5ZNFUZ2w0qtJugDEhbI=

I have not given much thoughts on the impact of storing the headers in lowercase all the time, but a quick test worked for me.
Perhaps the fix is as simple as this:

Hello, Thanks for the great code. It works with echo server using ws, but not wss.

Any suggestions?

In testing for Websockets and standard TCP error code comparisons, I've run into an infinite loop when I purposefully perform a read on a default socket.

I should not be trying to read from a Websocket if there is no connection (listener timed out) but running the test below on a TCP read would simply return "Error 1: Invalid argument".

In the screenshot above, the probe on (33) shows that the Websocket is default value and the socket object is of type "Socket.lvclass". I entered an infinite loop where the Internal Read would time out, but be floored at 0ms and repeat itself without stopping. The workaround was to ensure that I had a TCP socket in my default Websocket object, even though the TCP connection ID is invalid.

I believe it should terminate the loop when the timeout for the Calculate Timeout method (outside the loop) is Elasped = True, before getting into the loop and actually waiting for frames.

An equivalent TCP operation would be a 0ms timeout on the Read method... Even if there are bytes (frames) on the bus, it should return immediately.

To add WebSockets Client/Server support for LabVIEW NXG.

WebSockets support has already been added to the NXG Web Module but the corresponding functionality has not been implemented for 'regular' LabVIEW NXG.

This will require importing the 'classic' LabVIEW library and building it into an NI Package.

There is a bug in the generation of the WebSockets-Secret where the secret is not correctly Base64 encoded which leads to issues when communicating with 3rd-party WebSockets servers (e.g. Python).

For large packet sizes (>1Mb), the Base64 encode/decode functions are not performant.

Investigate and see if improvements can be made to increase library performance.

The current implementation of the library uses the native LabVIEW TCP/IP VIs which do not support TLS/SSL communications required for Secure WebSockets.