ioan

I ended up using this guide: The only changes required: uses IdOpenSSLVersion, IdOpenSSLIOHandlerServer; DefaultCipher = 'ECDHE-ECDSA-AES128-GCM-SHA256:' + 'ECDHE-PSK-CHACHA20-POLY1305:' + 'ECDHE-ECDSA-AES256-GCM-SHA384: '+ 'ECDHE-ECDSA-CHACHA20-POLY1305:' + 'ECDHE-RSA-AES256-GCM-SHA384:'+ 'ECDHE-RSA-AES128-GCM-SHA256:'+ 'DHE-RSA-AES256-GCM-SHA384:'+ 'DHE-RSA-AES128-GCM-SHA256:'+ 'DHE-PSK-AES256-GCM-SHA384:' + 'DHE-PSK-AES128-GCM-SHA256:' + '!ADH:!EXP:!RC4:!eNULL@STRENGTH'; // block 3DES / DES / RC2 / IDEA IdOpenSSLIOHandlerServer := TIdOpenSSLIOHandlerServer.Create(nil); IdOpenSSLIOHandlerServer.Options.TLSVersionMinimum := TIdOpenSSLVersion.TLSv1_2; IdOpenSSLIOHandlerServer.Options.TLSVersionMaximum := TIdOpenSSLVersion.TLSv1_3; IdOpenSSLIOHandlerServer.Options.CipherList := DefaultCipher; IdOpenSSLIOHandlerServer.Options.CertFile := fCertPath + 'cert.pem'; IdOpenSSLIOHandlerServer.Options.VerifyCertificate := fCertPath + 'root.pem'; IdOpenSSLIOHandlerServer.Options.CertKey := fCertPath + 'key.pem'; IdTCPServerTLS := TIdTCPServer.Create(nil); IdTCPServerTLS.IOHandler := IdOpenSSLIOHandlerServer; IdTCPServerTLS.ContextClass := TMyContext; IdTCPServerTLS.DefaultPort := fATAPort; IdTCPServerTLS.OnConnect := IdTCPServerNOTLSConnect; IdTCPServerTLS.OnDisconnect := IdTCPServerNOTLSDisconnect; IdTCPServerTLS.OnExecute := IdTCPServerNOTLSExecute; IdTCPServerTLS.Active := true;

I love this forum, but I believe discussions about an open-source project should take place where the sources are. As long as the project remains of interest, it will always be easy for anyone to read the archives and find solutions.

What 3rd party projects did you use for TLS 1.3 with Indy?

Any guide on how to install the Indy version that supports TLS 1.3, while keeping the default installation also? Also, after installing it, how do I enable, for example a TIdTCPServer to accept both, TLS 1.2 and 1.3 connections?

You can try loading the correct version of the DLL at the start of each application using something like this (place this unit as the first unit in the uses section of your .dpr file): unit loadssldll; interface uses Windows, System.IOUtils, System.Types, System.SysUtils; implementation uses SvcMgr, avglobal, avfiles; procedure LoadOpenSSLDll; var libHandle: array of cardinal; dllpath: string; fName: string; poz: integer; begin {$IFDEF WIN32} dllpath := GlobalRootPath + 'OpenSSL_32'; {$ELSE} dllpath := GlobalRootPath + 'OpenSSL_64'; {$ENDIF} SetDllDirectory(PWideChar(dllpath)); poz := 0; for fName in TDirectory.GetFiles(System.SysUtils.IncludeTrailingPathDelimiter(dllpath), '*.dll') do begin if (ExtractFileExt(fName) <> '.dll') then // make sure that .dll Continue else begin Inc(poz); SetLength(libHandle, poz); libHandle[poz-1] := LoadLibrary(PWideChar(TPath.GetFileName(fname))); if (libHandle[poz-1] = 0) then begin with TEventLogger.Create(globalAppName) do begin try LogMessage('ERROR (loadssldll.LoadOpenSSLDll): ' + dllpath + ' cannot be loaded.', EVENTLOG_ERROR_TYPE); finally Free; end; end; Halt(1); // the libs aren't found, terminate end; end; end; SetDllDirectory(nil); end; initialization LoadOpenSSLDll; end.

7, the most holy number!

Try something like this: var s: TStream; begin s := TFileStream.Create('soundfile.mp3', fmCreate); try IdHttp1.Get(your_file_url, s); finally s.Free; end; end;

I don't buy it, I don't think this is just hardware failure. My conspiracy theory is that it started with hardware failure and then they realized that the backup didn't backup for 20 years. No matter what hardware failure you have, it doesn't take two weeks to get it back up and running.

You need to make the names match: procedure TfrmDatabaseTutorial.ShowSelectedResults(); Selected not Select

For Enterprise and I just got a quote for $1199 for a year.

TClientDataSet 😉

I have a situation where one server is responsible for hosting several thousands of files, and multiple other servers require access to these files. These servers may have hundreds of concurrent threads accessing, adding, or deleting files on the shared drive. I have been using a windows shared directory to facilitate this access, but I have experienced issues where the shared directory becomes unresponsive, possibly due to too many simultaneous connections. What is the best solution for this scenario? Thanks!

You could use a thread, something like this: type TMyThread = class(TThread) private FRet: string; protected procedure Execute; override; published property Ret: string read FRet; end; TForm5 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } procedure HandleThreadTerminate(Sender: TObject); end; var Form5: TForm5; implementation {$R *.dfm} procedure TForm5.Button1Click(Sender: TObject); var Thread: TMyThread; begin Thread := TMyThread.Create(true); Thread.FreeOnTerminate := true; Thread.OnTerminate := HandleThreadTerminate; Thread.Start; end; procedure TForm5.HandleThreadTerminate(Sender: TObject); begin caption := TMyThread(Sender).Ret; end; { TMyThread } procedure TMyThread.Execute; begin if not clientclass.connected then begin FRet :=''; exit; end; clientclass.msgvalid:=false; idTCPClient.IOHandler.WriteLn(msg); while (not Terminated) and (not clientclass.msgvalid) do begin FRet:=clientclass.msgfromserver; TThread.Sleep(0); end; end;

I started from scratch (had in plan to trim some fat anyway) and now I'm accessing the database directly from the TThread, inspired by the example from Embarcadero: https://docwiki.embarcadero.com/RADStudio/Sydney/en/Multithreading_(FireDAC) The service now works very well, no more access violations. I wish I had the time and patience to actually find exactly what exactly caused the problem, but the problem only appeared in production and I was pressed to fix it fast so I pretty much made it from scratch.

The stack trace I posted is the only thing I get when this access violation occurs. Usually when there is an exception, I get more detailed stack trace, but with this problem, that's the only thing I get.