Documentation update, the license set, VIPM package built

Author: AndreaV-Lsi

Examples/Test Client.zip

@@ -0,0 +1,9 @@
+Copyright (c) 2016 MediaMongrels Ltd
+Copyright (c) 2023 LS Instruments AG
+
+
+Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Examples/Test Client/LabVIEW Client/Client.vi

@@ -6,14 +6,14 @@ v1.0.0
 		1. the client needs to send an HTTP full URI and not a WS URI when we decide to put a full URI and not just the a path in the request.
 		2. The regex in the "Parse URI.vi" method has been improved for the dummy resource name "/"
 	* Refactored  the client/server handshake code
-	* added support for WebSockets resources as per RFC 6455
-	* 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. The answer is handled by the client handshake code which throws an error. Server handshake similarly handles the malformed client handshake by answering with a 400 Bad Request HTTP response according to RFC 6455. The response is handled by the client code throwing an error. We added a "ProcessHandshakeResponse.vi" that fully check the server response as of RFC 6455, before there was only a partial check obtained by reusing "the ProcessHandshakeRequest.vi"server code.
+	* added support for WebSockets resources names as per RFC 6455
+	* Now the server handshake checks if a resource name is available as of the input array of resource names and it answers with a 404 Not Found HTTP response according to the RFC 6455. The answer is handled by the client handshake code which throws an error. Server handshake similarly handles the malformed client handshake by answering with a 400 Bad Request HTTP response according to RFC 6455. The response is handled by the client code throwing an error. We added a "ProcessHandshakeResponse.vi" that fully check the server response as of RFC 6455, before there was only a partial check obtained by reusing "the ProcessHandshakeRequest.vi"server code.
 	* 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". 
 	* 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
 	* A "DecodeCloseReason.vi" was introduced to decode the Close Status and the reason as delivered by the "Read.vi"
 	* The "Write.vi" now can send binary an text data frames. 
 	* 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.
 	* The example server and clients were updated accordingly
-	* Introduced an enum typedef defining the data format type either text or binary.Other minor changes
-	* added a VI to create a valid websocket URI staring from IP address, port and service name. This VI is intended to facilitate the code modifications required when upgrading from older versions of the library where the the client handshake VI was not taking a ws URI as input but IP address and port separately 
+	* Introduced an enum typedef defining the data format type either text or binary. Other minor changes
+	* added a VI to create a valid WebSocket URI staring from IP address, port and service name. This VI is intended to facilitate the code modifications required when upgrading from older versions of the library where the the client handshake VI was not taking a ws URI as input but IP address and port separately 
 	* The Close method often follows the Read method returning the error 6066 "Closed by the peer". Checking of an input error within prevented it from sending Close frame in response, thus making the peer crash with the error 66 "TCP connection closed". This fix lets the Close message even if the error 6066 is present.

Examples/Test Server/Server.vi

@@ -1,2 +1,2 @@
-[My Computer]
-My Computer = "172.27.112.1"
+[My Computer]
+My Computer = "172.31.48.1"