Leaderboard

Meaning, the server sends something to a client that it did not explicitly ask for. Such as a notification when another client connects/disconnects, or when a client sends a message to other client. Things which can happen at any time, outside of the normal request/response flow of "I want something" -> "Here you go" (solicited). "Oh, BTW, here is something else I have for you but you didn't ask for" (unsolicited). That contains a mix of solicited and unsolicited messaging. The new client connects, gets a greeting, says hello, and gets acknowledged. The client initiated an action and got a direct response before doing anything else. That is solicited messaging. Then, all of the other clients get notified of the new connection. They didn't have to send any requests to receive that event, they are just blindly told that it happened, when it happened. It happened in the background, and they have to passively watch out for it. That is unsolicited messaging. That is unsolicited messaging. Client1 sends a request to the server (solicited), but then the server notifies Client2/etc (unsolicited). Client2/etc did not send a request to receive that event, it/they are blindly told when the event happens. Same thing. All that extra messaging that the server does in the background needs to be handled properly. But if you code your server to just receive a request and send a response, you won't be able to handle that extra messaging at all. And right there is the problem. The code you showed doesn't handle that last part. You can't just write to a given client connection whenever and from wherever you want. You have to serialize your outgoing messaging. Think of what would happen if 2 clients happen to connect/disconnect at the same moment and thus need to notify the same target client. Or if multiple clients send private messages to the same target client at the same moment. You don't want multiple messages to that target client to overlap, that will corrupt your socket communications. So, you must provide some mechanism to make sure that subsequent messages wait their turn while an earlier message is still being written to the socket. That could as simple as putting a critical section or other exclusive lock around socket writes. But, that can cause unwanted blockages in threads that want to write to a socket, so that is where my earlier suggestion to use a per-client queue comes into play instead. That way, only the thread that actually writes the queue to the socket may block, while other threads are free to continue putting new messages into the queue. Well, that is certainly true, if you do the writing in the OnExecute event (as you usually should). But, if OnExecute never writes, only reads, then you can do the writing from another thread. I didn't say anything about a delay.

OpenSSL has released new versions of the three active versions, 3.2.1, 3.1.5 and 3.0.13 which have three low priority security fixes. Windows binaries are available in SVN and the overnight zip file and separately from https://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp In addition to the three DLL files, the zips include compiled RES resource files that contain the same DLLs, text files and version information, see the RC file. The RES file may be linked into application EXE files and code then used to extract the DLLs from the resource to a temporary directory to avoid distributing them separately. ICS V9.1 and later optionally support loading the resource file, currently in SVN and the overnight zip. Beware V9.1 has a lot of other changes that may need application changes, please read the SVN change log very carefully. There will be a lot of new documentation about V9.1 over the next two weeks. Separately, YuOpenSSL has released 3.0.13 as commercial DCUs allowing applications to be used with OpenSSL without needing separate DLLs. Angus

Yes. I purchased a license. great stuff! Thanks!

Sure, I do that all the time - but tinkering with something and being good at something are not the same. It's not just the language you need to learn, it's the libraries. I can read and write code in Go, Rust, C, C++, Javascript, Typescript, C#, Delphi - but I would only consider myself good at writing the last 3 (I have used a bunch more languages over the years too). What you are forgetting is just how little time most people have to dedicate to open source development - if you look at the most popular open source delphi projects, you will see they have only a hand full of regular contributors. If you add having to learn a new language (whatever that may be) then you are narrowing the pool of possible contributors substantially. Examples https://github.com/VSoftTechnologies/DUnitX/graphs/contributors - 56 contributors but only one regular one (the author - myself). https://github.com/danieleteti/delphimvcframework/graphs/contributors 42 contributors but only one regular one (the author). https://bitbucket.org/sglienke/spring4d/src/master/ - bitbucket doesn't show the number of contributors but the 99% of the commits come from one person ( the maintainer/new author). Most other contributors contribute the odd bug fix but they tend to be one offs. If they have to learn another language (or are not good at a language) then they either won't contribute or they will move on to an alternative. So yes, being an open source author can be somewhat joyless.

In the category Fun with Generics: https://blog.grijjy.com/2022/01/25/crgp/