You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<One_Line_Description_Summary>A library implementing the WebSocket protocol including support for resource names</One_Line_Description_Summary>
31
31
<Description>This library is a fork of v1.6.0.22 of the WebSokets library by MediaMongrels Ltd.
32
32
33
+
<b>The main new feature is the introduction of support for resource names as per RFC 6455 and better adherence to the RFC standard.
34
+
35
+
As far as the author knows, this is the only LabVIEW WebSocket library supporting resource names. </b>
36
+
33
37
The library leverages on the TCP VIs for establishing a WebSocket connection and communicating through it. It allows, for example, a web browser to communicate with a LabVIEW application acting as a WebSocket server.
34
38
35
-
It contains VIs for performing websockets handshaking, reading/writing data and closing the connection. The API allows for you to write code to act as both a WebSocket server, and as a client.
39
+
It contains VIs for performing WebSocket handshaking, reading/writing data and closing the connection. The API allows for you to write code to act as both a WebSocket server, and as a client.
36
40
37
41
<b>Since the fork the following changes have been implemented:</b>
38
42
39
-
* Fixed a bugs in client handshake code:
43
+
* Fixed bugs in client handshake code:
40
44
* Refactored the client/server handshake code
41
45
* added support for WebSocket resources names as per RFC 6455
42
46
* Now the server handshake checks if a resource is available as of the input array of resource and it answers with a 404 Not Found HTTP response according to the RFC 6455. Server handshake similarly handles the malformed client handshake by answering with a 400 Bad Request HTTP response according to RFC 6455. We added a "ProcessHandshakeResponse.vi" that fully checks the server response as of RFC 6455, before there was only a partial check obtained by reusing "the ProcessHandshakeRequest.vi"server code.
@@ -53,7 +57,7 @@ It contains VIs for performing websockets handshaking, reading/writing data and
A library implementing the WebSocket protocol including support for resource names
3
+
4
+
## Description
5
+
6
+
This library is a fork of v1.6.0.22 of the WebSokets library by MediaMongrels Ltd.
7
+
8
+
**The main new feature is the introduction of support for resource names as per RFC 6455 and better adherence to the RFC standard.**
9
+
10
+
**As far as the author knows, this is the only LabVIEW WebSocket library supporting resource names.**
11
+
12
+
The library leverages on the TCP VIs for establishing a WebSocket connection and communicating through it. It allows, for example, a web browser to communicate with a LabVIEW application acting as a WebSocket server.
13
+
14
+
It contains VIs for performing WebSockets handshaking, reading/writing data and closing the connection. The API allows for you to write code to act as both a WebSocket server, and as a client.
15
+
16
+
**Since the fork the following changes have been implemented:**
17
+
18
+
* Added support for WebSocket resources names as per RFC 6455
19
+
* Fixed bugs in client handshake code
20
+
* Refactored the client/server handshake code
21
+
* Now the server handshake checks if a resource is available as of the input array of resource and it answers with a 404 Not Found HTTP response according to the RFC 6455. Server handshake similarly handles the malformed client handshake by answering with a 400 Bad Request HTTP response according to RFC 6455. We added a "ProcessHandshakeResponse.vi" that fully checks the server response as of RFC 6455, before there was only a partial check obtained by reusing "the ProcessHandshakeRequest.vi"server code.
22
+
* Data Framing Refactoring: Introduced a generic "SendDataFrame.vi" which sends a data frame according to all the possible Opcodes as defined "Opcodes.ctl" enum and also allows to set the Final Frame Bit (FIN Bit). This vi is now used in both the "Write.vi" and "Close.vi", as well as the newly introduced "Ping.vi" and "Pong.vi".
23
+
* The "Close.vi" now correctly sets the FIN bit and allows to send a Close Status as defined in the "StatusCode.ctl" ring and a close reason
24
+
* A "DecodeCloseReason.vi" was introduced to decode the Close Status and the reason as delivered by the "Read.vi"
25
+
* The "Write.vi" now can send binary an text data frames.
26
+
* The "Read.vi" was refactored so as to allow also binary data, to read the FIN bit and the close reason in case of receive "Connection Close" opcode. As a result now the calling code has the tools to handle the multi-framing and the Ping/Pong exchanges.
27
+
* Introduced an enum typedef defining the data format type either text or binary.
28
+
* Added a VI to create a valid WebSocket URI staring from IP address, port and service name.
29
+
* The close method now filters error 6066 originating from the waiting Read method when the peer closes the connection. This allows now for a clean connection close
0 commit comments