Does it fully implement the Websockets protocol standard?Mostly, it does not:
Nicely done. I wonder whether that would work with Mycroft?From what I've seen this simply uses Json-Messages on top of websocket UTF-8 messages, so I don't see why it should not work. You could define a class which owns the TWebsocketCommunincator, as well as a class hierachy for the Mycroft Message types, and simply wrap it. So your wrapper class subscribes to TWebsocketCommunincator.OnRecieveMessage, recieves the messages, loads the json, and than creates the respected Mycroft message from it. Similarly it can provide a write method, which takes such a mycroft message, converts it to json and writes it to the TWebsocketCommunincator.WriteData stream.
https://mycroft-ai.gitbook.io/docs/mycroft-technologies/mycroft-core/message-bus
Thanks for sharingAre you using the latest version of the master branch?
I was looking for something like this. I just tested the examples one server and two clients and I noticed the CPU load goes up to 52 percent when I open the second client, when I close the clients then the load on the CPU is even greater close to 100 percent. The tests were done with Windows 10.
What could be the problem?
Thanks for sharing this. I got it to compile in half a second and was receiving messages from the sample webpage you included.
I can't figure out how to push messages from the server back to the browser client. Any help?
Thanks again.
Are you using the latest version of the master branch?
Because I "fixed" this problem (as was reported in this issue: https://github.com/Warfley/LazWebsockets/issues/9) on May 29th
Not sure whether this gets attention after 1 year of silence, nevertheless:
1) great work! Thanks! Gives e the hope to solve my problem.
2) question: when I start and connect the html client several times, how can I differnetiate betwenn the 4 connections, e.g. to send different messages to each of them?
(a beginner in websockets)
Though I still don’t know how to identify TWebsocketCommunincator during Connect, I found a workaround which solves my specific problem:I answered you in your issue, but here again, with a little bit more detail. Previously the library did not track the open connections, you had to do it yourself, like with the array you are using. So what you did is actually how it was intendet. That said, I changed this, now the Handler has a thread safe list of active connections.
I identify the TWebsocketCommunincator during the first message received from a specific client and assign it to an array of TWebsocketCommunincator (:= TWebsocketCommunincator(Sender)). So I can send separate messages to the different clients.
First of all, just found a little bit of time to update this project again. Fixed the thread pooling issues that resulted in 100% CPU load, as well as a few other bugs.Though I still don’t know how to identify TWebsocketCommunincator during Connect, I found a workaround which solves my specific problem:I answered you in your issue, but here again, with a little bit more detail. Previously the library did not track the open connections, you had to do it yourself, like with the array you are using. So what you did is actually how it was intendet. That said, I changed this, now the Handler has a thread safe list of active connections.
I identify the TWebsocketCommunincator during the first message received from a specific client and assign it to an array of TWebsocketCommunincator (:= TWebsocketCommunincator(Sender)). So I can send separate messages to the different clients.
To identify a connection you have different options. The first one would be to look at the remote address and port (ACommunication.SocketStream.RemoteAddress.Address and ACommunication.SocketStream.RemoteAddress.Port). This combination is unique for every connection.
Another possibility is to have some form of identifier, for example upon connection your client could send a message like 'NAME=XXX' or something like that and you can read that message and then just store an association between name and the TWebsocketCommunicator object somewhere. For this you can for example use a TFPGMap, TDictionary or if performance does not matter to you and you don't want to use generics, TStringList.
BUT: when you have a threaded application, remember that you need to use thread safe objects. You can look at how the thread save connection list is managed within my TWebsocketHandler class. For further information I recommend you reading this wiki article, because multithreaded applications are not so simple: https://wiki.lazarus.freepascal.org/Multithreaded_Application_Tutorial#Critical_sections
The sever says that it accepted connection for 2 times at the same ip and port. My code take them as 2 connections and saved it in monitorList(a TList with infomation of each connection). When the server needs to dispatch messges to clients, it send message to all of the connections in that TList. And then the sever raised an error.
Try except should pretty much always work, but if you are using Lazarus, it will throw the message that an exception has been risen even if the exception will be cought. Just click the continue button so the except block will be executed. This is just a little annoyance with Lazarus
Found the problem with the identical port, I used the wrong identifier (LocalPort rather than RemotePort) pushed a fixed version to the github
Actually, making the WebsocketCommunicator better extensible is something that was already suggested earlier. I am not so keen on simply adding a PtrInt field to it, because this is not such a clean solution. What was suggested before is to have the ability to create a custom class that inherits from TWebsocketCommunicator and can be extended with custom data or functions.
I just added this feature, see the BroadcastServer example for how to use it.
I also changed up the ConnectionList, which I previously added to the SocketHandler base class, but I think that this is too restrictive, as there might be the need for other datastructures (like a map mapping an identifier to the Object), so this is something the SocketHandler now has to manage manually (see BroadcastServer as an example).