DelphiUdIT

A reflection on the discussion and on the concepts of "trusted". If by trusted it is meant that the connection between the client and the server is practically secure and that the client knows who the server is, then the concept of trusted is verified with the use of a server-side certificate (possibly issued by a recognized certifier and not by a self-signed certificate) and an encrypted connection via TLS, and that's what the example I posted does. But if we expand the concept of trusted, as I think @shineworld intends, then it is more complex to apply it. The "expanded" concept is that the connecting client is known and certified as if it were a server. A standard certificate (similar to that of the server) on the client side is not applicable because the files are exposed, especially the private key even if protected by a password, and anyone who can access the station could "copy" it. A solution would be a "hardware" certificate (as in a USB token), but it is not an economic solution and there is a fairly important management for the tokens: it must be said that many private companies and all public companies have by now equipped employees with a USB token or similar (token like credit card, etc ....). Other easily applicable solutions are then: apply the concept of "registration": at the very first connection (client installation) the client sends runtime data to the server (date and time of installation, processor UUID, etc ....) which the server registers (with its own coding ) and will use to test future connections. The client will send this data at each new connection and the server will refuse the connection if they are not included in the list of already registered clients. OBVIOUSLY THESE DATA MUST NOT BE DISCLOSED, IE MUST NOT PUBLICLY KNOW IF AND WHAT THE CLIENT SENDS TO THE SERVER (otherwise it is enough for a fake client to replicate the data of a real client to replace itself). apply the classic concept of username / password, but it makes sense if the entry is done by operator, if it has to be automated it means that username and password must be stored locally .... so other local encryption, .... etc ... . Bye

I post a simple TCP sample using SLL (TLSv1_2). It's only a little start point, but may help you. Inside there are the OpenSSL Win64 dll 1.0.2u and one certificate self signed valid for one year (localohst, 127.0.0.1). There is also a DHParam file used for DH "chiper" protocol, not necessary and not used. From there you can improve security, authentication, etc .... Bye TCPS Demo.zip

With this configuration (see libcrypto. so path for example ) you will load your OpenSSL libs.

In the past surely not. I always used "mine" libraries. Of course there are issues with versions (1.0.x, 1.1.x, 3.0.x), so it's best to distribute your own anyway. Bye

Really interesting, knowing if a file is already in use by another application via an api instead of trying to open it and manage the error (without knowing "who" is blocking it anyway) is very useful in some scenarios. Bye

With respect to your request, and speaking of databases, I've honestly never heard the concepts of UNDO / REDO but the concepts of COMMIT / ROLLBACK. All databases support the concepts of TRANSACTION / COMMIT / ROLLBACK. The main difference between theoretical and practical use is defined by both the DB used and the component used to manage the database (e.g. FIREDAC, ZEOS, ADO)..... I've never used Interbase, but I've used FireBird even if not "heavily" and the TRANSACTION support from the DB is complete and it's multi-user with the possibility of setting the LOCK resolution mode. Now I don't remeber if FIREDAC supports transactions at DB level (therefore multiuser, auto lock, ....) or at connection level (1 transaction for each connection, therefore not native multiuser). ZEOS only supports connection-level transactions, therefore 1 ACTIVE TRANSACTION for each connection, no concurrent multi-user. EDIT: my fault, there is no concurrent MULTI TRANSACTION with same client side application. Means that only one sql editing instruction (for example) = one transaction may be in use concurrently in that client side app. MULTIUSER from different client is always possible and even with multiple database connections, multiple concurrent transactions can be made. In any case the solution can be using only the transactions, and this is expressly true if there is multiuser. The resolution of inconsistencies, locks and all other problems is very complex and cannot be solved "manually" at the application code level. This is the page for the FireBird documentation, where the mechanisms of LOCK, TRANSACTION, COMMIT / ROLLBACK are explained very well. Bye P.S.: of course, a careful design of a database is always necessary, regardless of the use of TRANSACTIONs.

I saw, but the main loop should be ... A LOOP .... and in a console app there aren't so many variants .... It simply instantiates all objects at runtime (the graphical application you see instantiates everything at runtime, it's just for convenience and debugging that there is a graphical window). In the main loop you can do: var EndLife: boolean; begin EndLife := false; // Runtime object creation // End {$IFDEF POSIX} //is used to intercept the CTRL-C, in order to terminate the program correctly sigIntHandler._u.sa_sigaction := @my_handler_ctrl_c; sigemptyset(sigIntHandler.sa_mask); sigIntHandler.sa_flags := SA_SIGINFO; sigaction(SIGINT, @sigIntHandler, 0); {$ENDIF} while not EndLife do begin //In here you can put for example a WAITFOR with 100ms timeout, you can update a log file, send an I'M ALIVE, capture a variable to stop / start the web server ......... end; // Runtime object destruction // End end; //Capture CTRL-C, CTRL-BREAK, LOGOFF, SHUTDOWN, CLOSE ... events. I DIDN'T TEST THEM !!! {$IFDEF POSIX} procedure my_handler_ctrl_c(segnale: integer; segnale_info: Psiginfo_t; context: Pucontext_t); begin //writeln('Caught signal ', segnale); EndLife := True; _exit(1); end; {$ENDIF} These are simply an advise, i don't test it but i think may be a start point. Bye

May be yes, there are some significant differences .... first of all the use of pointers directly ...... these means that the errors are no so clear. If you use the normal array definition you get "Range check Error" instead of "Segmentation error"... isn't this enough? And in general, unless there are speed or interfacing problems with particular APIs, why use direct memory management in PASCAL? In all my life as a programmer I have no memory of having directly used GetMem in PASCAL, I have never felt the need (but I have programmed parts of code in assembler). If I have to interface with "something" that can't be handled in Pascal, I create a DLL in "C" and work them with the "C" style. But of course everyone is free to act as they wish, fortunately. Mine was advice. Bye

I don't use cosole application, i use a graphic (FMX) application (based on Indy demo). This is for ease of use only. In fact, the FORM does nothing except handle events and start / stop the server. All LOGs are sent to the console via writeln. Exact same thing in Linux. Now with TLS 1.3 support Bye P.S.: There is one flaw in certificate management, which is that the certificate's private key must be exposed and accessible to the application. This may be a vulnerability if the server is accessed locally by third parties.

When you use getmem, in general, you are given a virtual memory address expressed in this form: xxxx:0, whose length depends on how many bytes you allocate. If for example if you allocate 1000 bytes it will be: xxxx:0 - xxxx:999 Where xxxx is called segment. If you try to use xxxx:1000 you exit the memory segment and the segm "segment" error is thrown. This is a HARDWARE protection mechanism and you can do nothing to avoid it. I repeat, avoid using the logic of the "C" language and use the form and rules of "Pascal", they will help you avoid these errors. HI.

As mentioned in a previous post, I use classic (raw) UDP communication because Thethering is not normally supported in the industrial environment. To give an example of UDP performance and reliability (in this context, it may not be appropriate for other applications), I explain an application developed and in operation with 20 plants in operation for 5 years (some for 5 years, some for 1 year). The software runs on a PC with 3 x 1Gbit network cards and a USB / GigaEthernet adapter. There are 6 to 18 devices connected to the local network and they use only UDP communications. The average traffic on the various PC network cards is 150 Mbit to 750 Mbit per card. The PC software to trigger the devices (basically cameras) transmits between 500 thousand and one million UDP packets (for synchronization only) per day (10 / 12 hours of continuous work 7 days a week). If even one packet is lost the trigger chain stops, the plant stops, a log is updated and an email is sent to me to report this. In all installations, in all these years it has never happened that a UDP packet has been lost. Of course, all the hardware has been designed to ensure maximum reliability, starting from the power supply and network components such as switches. Creating a reliable network using UDP is possible in certain scenarios. Bye

1) It depends on how the COM Server is built: from Windows 7 onwards any application that works as a service cannot have ANY REFERENCE to graphic objects of any type or kind nor access to the graphic surface (obviously not even as an indirect reference). The only exception is to show a "message" window, even before logging in with a specific API. A service cannot launch a "normal" COM, ie which refers to graphical parts, but it can dialogue with a COM object already "running". I dont' know if the last implementation something is changed (is a lot of years that i don't develop COM object) As @david-heffernan mentioned, the COMs can be used even without registration using the sXs technology, basically a Windows Manifest describes it (but it can be used only and exclusively if the COM is built as "inprocess" and this is not compatible with a windows service). Now, the references I had for using this technology (which doesn't use .NET components) are no longer available. 2) Preventing multiple instances of the same application is simple to implement. And if you want to prevent multiple unwanted parallel "tasks" from being executed, for example The service might pause (almost) when it detects the GUI executable (after it has done all its operations). However, the interaction mechanism between a Windows service and an EXE application is relatively simple. 3) For multiprocess communication I always use TCP communication (Indy components like TIdTcpClient / Server) and sometimes (actually very often in industrial applications) I use UDP in BROADCAST.

Answering your question is very difficult. It all depends mainly on what the final goal of the application is and how the various processes are imposed on you. What is the infrastructure available (local computation, cloud, distributed computing)? Will the image acquisition be synchronous or asynchronous, will they be serialized? Does the application prioritize speed? Etc .... Bye

As @PeterBelow wrote to you, what you indicated can be written more simply, readably and effectively in Pascal. It looks like you're writing "C" code. Just in case, to explain better you can write this code which allows you to: 1) In case of fixed extensions, to avoid some errors because they are already checked during compilation; 2) However, in case of errors (as in dynamic extensions), much clearer errors will be generated (erange errror: "Range Check Error"); 3) You can use the Low, High methods to automatically limit the cycles to the maximum extent of the arrays, avoiding the risk of "overshooting" the limits. //Static array var ballnumber: array [0..6999] of byte; i: integer; begin for i := Low(ballnumber) to High(ballnumber) do ballnumber[i] := 5; end; //Dynamic array var ballnumber: array of byte; i: integer; begin try SetLength(ballnumber, 7000); //<----Like GetMem for i := Low(ballnumber) to High(ballnumber) do ballnumber[i] := 5; finally SetLength(ballnumber, 0); //<---- Like FreeMem end; end;

I used two standalone Indy web server (https): one in a Linux server and one in a Windows 11 system. The web servers (Linux and Windows are the same, simple compiled for different OS) use a TLSv1_2 secure connection and were tested in one year with direct public connection without any filter. SSLLabs (SSL Labs - Test SSL web server) give a valuation of "A" grade to the web server. Tipically every day the application registered 1 thousand of attack, some are simple scanners like others are trying to violate the server. The web servers never went down. With new processors and systems, the number of the Threads is not a problem. I think that Indy is more than mature to use in a production enviroment. Bye

This is the version of the arm 64 (arm64-V8a). The others should be the same. Fips means that are compiling with some cryptography function ? I thought fips modules could only be compiled with OPENSSL 3.

I have the *.so OpenSSL 1.02 library for all Android SO (x86, x86_64, V7a, V8a) ... they are all date 14/06/2022 and may be the version is 1.02s I really don't know where i found them, and since I also use Indy SSL I researched all libraries for all supported systems. Like i told, I don't know who "create" the library but I used them and no problems were found. Bye openssl-1.02_Android.zip

Using the the Jedi (JVCL) unit JvRas32 you can connect to a any VPN created in Windows (i used it lot of years ago only with Microsft VPN), i don't know if it is actual working:

MQTT is a standard protocol, define define by IETF RFC2119 and whose communication resources are reserved by IANA (TCP V4 Port 1883 and 8883). Oasis organization has take care to introduce some "working" improvement (marking them as "non-normative") to really be used in operative production environment (eg. IoT), and is the "the facto standard". P.S.: most of industrial electronic companies make some products compatible to MQTT, like OPC SERVER (often used to communicate with sensors). Often they do that in "modbus" products with which MQTT has vague similarities. Bye

If one publish a "retain" message, this message will remain "online" until it will be clean or override (eg. publish another message, retain or not). While the message is retain every one can subscribe and receive it. If the message it's clear or override, it's lost for ALL. MQTT is designed to maintain only the last message. Of course I talk about one "topic", one can publish as many topic as he wants. Bye

This may be, but to enable 64 bit ASLR you must enable "HIGH ENTROPY". Enable only ASLR and disable HE should not produce pointer with 64 bit data ..... or i misunderstand ASLR ? With my test i try the two combination (ASLR or ASLR + HE) and i had some problems anyway.

I don't understand very well what you are thinking to do. But remember that MQTT is not a database, it doesn't present you a storytime of alerts, it works on time basis and is totally asynchronous. If i publish a message (thinking that is a retain), until this message "stay" there all can view that, but when the message will clear (or change) .... who read the message its ok, the workstations that were offline and cannot read that "lost that message". Of course you can publish a message like a storyboard shifting all every time, but this is not the scope of the MQTT. If you made a broker or can control a broker, of course you can know how many clients are online and you can decide what to do. Bye

In Delphi 11.2 ASLR (and High Entropy too) may be used and is working. But when i tested it in a real running environment, there were some glitches (AV, memory leak, ....) that don't show up if I simply turn off ASLR. I've noticed that the use of 3rd party dlls (SDK or whatever) even if recent plays a role in this. All of course in a 64-bit environment. I didn't go into depth because I'm busy on several fronts, but in the near future I'd like to go into it further. For now I don't use ASLR and High Entropy. Bye

I'm implementing a new feature to the software I've produced that used e-mail as an alert. Now I'm also testing mosquitto as a server and I'm rebuilding a new MQTT client starting from an old repository on github https://github.com/wizinfantry/delphi-mqtt-client (that version is not working with new enviroment and needs some refresh). The current version of mosquitto supports up to the latest version of MQTT (MQTT 5.0 https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.pdf), SSL (up to TLS 1.3), TCP or websockets. Also you can connect to other brokers. And with retains, there's no problem at all losing alerts, especially using mobile devices as clients. In my opinion, since the server (broker) is already ready, implementing MQTT having a good Delphi "component" allows you to easily manage alerts. Bye P.S.: in this Embarcadero article there is more info and link to a client and broker MQTT write in Delphi: https://blogs.embarcadero.com/learn-how-to-use-the-mqtt-protocol-in-delphi-with-this-library/

PostMessage(HWND_BROADCAST , WM_SYSCOMMAND, SC_MONITORPOWER, 2); This should works, it always works in every version of Windows. If it not works, it's possible that you have some drivers, services or others that prevents you from turning it off. Any movements of the mouse and key pressing turn on the monitor. Bye