Forum > Third party

Websockets Server/Client Implementation

(1/7) > >>


for a project I required a websocket server to communicate with an web application. From a first glance I wasn't really satisfied with the few results I found on google didn't really satisfy me, so I've wrote my own.

Github Page

It works fully using the fcl ssockets unit and is therefore cross plattform available without any additional packages or components (like indy or synapse) required.

Also, once the protocol was implemented for the server it was only a small step to implement also a client, so this provides an implementation for a Server and a Client.

For further details see the on github.

For my little project for which has only to handle a few connections in a local network and everyone is nice it's now working fine, I haven't been able to test it on a larger scale. If you run into problems with it, feel free to open an issue on github or post here.

Well done!
Thanks for sharing!
Does it fully implement the Websockets protocol standard?

Nicely done. I wonder whether that would work with Mycroft?


Thanks for sharing this, very interesting.


--- Quote from: edwinyzh on March 01, 2020, 04:34:56 am ---Does it fully implement the Websockets protocol standard?

--- End quote ---
Mostly, it does not:
1. provide any support for extensions (i.e. no mechanism like overloading some functions or so), so any extensions need to be implemented on the source level.  I'm actually currently thinking about a nice method to implement this neatly..
2. check for the validity of UTF-8 String message. It will simply copy the bytes. The protocol requires to fail the connection in case of malformed UTF-8, which right now is currently in the responsibility of the user (i.e. if you get an error processing the messages, you need to call close explicitly). So just from a technical point of view byte messages and String messages are handled identical.
3. provide a special mechanism for  subprotocols. They need to be implemented by the User, i.e. in the TWebsocketHandler (by overriding the Accept method you also can influence the handshake), but I don't know enough about the subprotocols to know if this is sufficient.
4. Support Messages in Close-Frames like statuscodes, while this is actually not hard to implement, it's something I hadn't time to do.
5. Use websocket URI's but requires you to provide the host, port and path (including the query) directly
And lastly, using fragmented Frames, while implemented, is currently kinda pointless, as the implementation works on a message basis (for having seamless threading support), meaning the messages get buffered anyway. But controll messages are still handled, even when waiting for fragments of another message

Besides those points this should be standard compliant. But I worked more on an example basis and only superficially read through the standard and the only parts I've read in depth where the most important core protocol features.

--- Quote from: MarkMLl on March 01, 2020, 10:42:39 am ---Nicely done. I wonder whether that would work with Mycroft?

--- End quote ---
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.

There are also a few things I should mention: For one, it can handle SSL, but I have no idea how, as the ssockets Unit has nearly no documentation and all of my knowledge about it comes from looking at fpHttpClient. Thats why I provide ras access to the TSocketHandler, so you can still use it, if you know how. For me this isn't currently a problem, as I only need the server, which is behind an NGINX reverse proxy, who does all the HTTPS stuff.
The second thing to keep in mind with this library is that it is very conservative in terms of Threading, while it is thread safe (i.e. there can't be any problems from calling the send/recieve/close functions in parallel), it does not make any assumptions what runs on what Thread. I did this because I didn't want to rely on Synchronize or TThread.Queue, because I didn't want that library to be dependend on the user calling CheckSynchronize regularly. So if you want to lift messages to the main thread, you need to call Synchronize seperately. My application does mostly MySQL stuff, which is also thread safe, so I don't care which threads recieve and send messages. But if you are for example writing an LCL application, you might want to use synchronize or TThread.Queue

While for my purposes this is currently enough, if you wish for additional features, feel free to leave a ticket at Github, I will try to keep this library as general as possible to be able to cover many use cases, so feedback is highly appreciated, especially for cases which I haven't thought of before


[0] Message Index

[#] Next page

Go to full version