Angus Robertson

You said you did not get the error with Indy, was that using TLSv1.3? If this is down to re-using TLS sessions, it might our caching is broken, despite the logging suggesting it is attempting to re-use an old session. Without tracing TLS packets, which is tedious, hard to know if caching really works. Angus

Okay, I can reproduce it by forcing ICS to use TLSv1.2. So not sure if this is really a FileZilla bug given it works on the older versions that did not support TLSv1.3. The old version also has a configuration option 'require TLS session resumption of data connection when using PROT P' which sound like the error message, but I have that ticked on the old beta, and that setting and lots of other interesting and useful ones have disappeared from the new version. Seems like users should go back to the reliable beta rather than the 'release' version <g> Angus

I can find no problem accessing my own FileZilla servers. My hosted server had v0.9.60 beta from a year ago: > PASV < 227 Entering Passive Mode (217,146,102,143,82,95) ! Passive connection requested to: 217.146.102.143:21087, control channel: 217.146.102.143 > MLSD /webapps/telerest/templates/testing/ Check for Old SSL Session Old SSL Session Found Cached < 150 Opening data channel for directory listing of "/webapps/telerest/templates/testing" ! SSL Connected OK with TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384, key auth ECDSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD filezilla.ftptest.org SSL Connected OK with TLSv1.2, cipher ECDHE-ECDSA-AES256-GCM-SHA384, key auth ECDSA, key exchange ECDH, encryption AESGCM(256), message auth AEAD < 226 Successfully transferred "/webapps/telerest/templates/testing" It seems after a decade of beta releases, v1 finally came out this summer, so I installed v1.2.0 on my hosted server, unfortunately Windows Firewall blocks it, despite it being added manually, so installed it locally, and it also works. 15:05:41:693 > PASV 15:05:41:693 Starting SSL Session 15:05:41:693 Cache SSL Session: New 15:05:41:693 < 227 Entering Passive Mode (192,168,1,105,251,19) 15:05:41:693 ! Passive connection requested to: 192.168.1.105:64275, control channel: 192.168.1.105 15:05:41:693 > LIST 15:05:41:694 Check for Old SSL Session 15:05:41:695 Old SSL Session Found Cached 15:05:41:695 < 150 Starting data transfer. 15:05:41:697 ! SSL Connected OK with TLSv1.3, cipher TLS_AES_256_GCM_SHA384, encryption AESGCM(256), message auth AEAD 15:05:41:697 pc21-web5.magenta SSL Connected OK with TLSv1.3, cipher TLS_AES_256_GCM_SHA384, encryption AESGCM(256), message auth AEAD So no idea why you are seeing error 425, is there something more useful in the FileZilla server log? If this is something to do with re-using SSL sessions, when ICS caches a session it adds the port number to the IP address when saving it, to prevent different services being accessed by the same session, but this is effectively what happens with the FTP data channel. So in TIcsFtpMulti you could try removing FtpCli.ControlSocket.PeerPort from xxNewSession and xxGetSession and see that improves matters. I'm not going to change this until I find out how FileZilla is configured to cause the error. Angus

Thanks, I already have FileZilla installed, albeit an older version, will test later and see what FileZilla has broken. Angus

OverbyteIcsXferTst.dpr is a complete ready to build testing project, takes a couple of minutes to start downloading stuff, with logs. I have FileZilla on one of my public servers, will test it later. Angus

The ICS FTP components have been tested regularly against FileZilla Server since 0.9.10 beta 15 years ago as you can read in the source code, can not recall testing it for a while, since I don't recall it every being broken. If FileZilla has re-invented the FTP protocol in some non-standard way, I'll look at it, once I see full logs from OverbyteIcsXferTst. Angus

You should never use TDateTime for duration calculations, users can change the system time, and summer time saving changes it twice a year (unless you use UTC time). Always use the difference between two GetTickCount64 Int64 values. Angus

No real idea what that response means, ICS does not share TLS sessions, they are new for each connection. Which ICS component are you using? It should be TIcsFtpMulti for which there is a sample OverbyteIcsXferTst.dpr which will allow you to test again FileZilla saving a proper log that may show the error. Angus

Can you please try and install the latest ICS from SVN or the overnight zip, we've made various C++ package changes (CPP 11.0 only) this week that should resolve the lib files not being updated, and fixes some CPP warnings. Same applies for any other CPP users, V8.68 is finished and will be released next week, so now is the time to test it installs correctly. V8.68 is a minor release, mainly install problems, added OpenSSL 3.0.1, and support for new HTTP request and response methods to help caching (Entity Tags), the REST component will now download files of any size, including resuming failed partial downloads, and HTTP error reporting is improved, as illustrated in the previous post here that previously would have said just Abort without any explanation. Angus

Probably unrelated, but just been reading an article in PC Pro magazine about the new Intel 12th generation processors, which have two types of core, performance and efficiency, something ARM has had for a while. Only Windows 11 has the extra code to receive telemetry from the Intel Thread Director in the CPU to negotiate on which cores processes should run. Windows 10 application performance may be more random, and different each time you run it. Which is slightly frightening. So just saying modern CPUs may affect applications in ways you have not considered. VMs are even worse. Angus

All I can say is you must build the common and vcl packages before the design package. But as you say, if you don't put any components on forms you don't need any packages, just build the units that your application actually uses. Angus

BTW, for C++ you should be using the early version of V8.68 from SVN or the overnight zip (same wiki page as the stable version), I fixed a load of C++ package and sample issues back in October so that 10.4 and 11.0 build again, including the ones you mention, sorry only just remembered. Angus

Sorry, I don't support C++, I just distribute files updated by other ICS C++ users. Hopefully one of them will be along shortly to help. OverbyteIcsSslThrdLock.pas has long gone, just remove any reference to it. ICS builds with Delphi 11.0 without any warning, if C++ gives warnings just ignore them. Angus

All that happens internally within the ICS TRestOAuth component, it holds the expiry date so knows when to refresh the access token. Getting a new refresh token has various options since many applications are used unattended, not just Windows services, so it will notify an administrator that a new OAuth2 login us required, but API access will fail until it happens. It is unfortunate that OAuth2 was designed without a refresh expiry date being known, so things could be planned better. Angus

Provided you have set the RefrToken or RefreshToken property, you won't see a login window. It;'s expiry is unknown to the application, but can happen if the account secrets are changed, if you invalidate it through the online console, or at the whim of Google or Microsoft. So applications need to handle token failure, as I mentioned a couple of days ago. The same refresh token can be used on multiple computers, at least for Gmail which is the service I use regularly as a backup when my own SMTP server is down. This why the ICS MailQueue component handles multiple email servers, with OAuth2. Angus

I think you are confusing the two tokens that OAuth2 should return. In ICS, AccToken property is the short lived token used for HTTP requests. The RefreshToken property is a long lived token that you should store safely like a password, and may be used repeatedly by the component to refresh AccToken, in background without any interaction. I tested GMail yesterday, and the saved refresh token meant it just worked without a new login. So you need to check if Azure is returning a refresh token and whether you are saving it for re-use. You may need to provide specific scope settings to get a refresh token, see the constant OAuthUriMSRest. Angus

The ICS packages all build okay with FMX and YuOpenSSL, why do you think it is incompatible? Or at least only with lots of deprecated warnings from OpenSSL, that we never see when using the DLLs. Just built one of the FMX samples and that works fine, once I'd commented out a couple of old lines. Need to update those old samples. Angus

I only removed TSuperWriterSock last year, perhaps there are references to it in an old HPP file built from an earlier ICS version? We don't distribute HPP files, maybe deleting it would cause it to be rebuilt correctly - but I know almost nothing about C++. I'd prefer not to restore unused code. Angus

I assume you are referring to an OAuth2 login page appearing in a browser during authentication. For Google, the Refresh Token you receive after an interactive OAuth2 login remains effective for several months or longer, generally, so can be used by services, believe this is the case with Microsoft as well, but don't recall from testing. Your service can email an admin to update the token manually if it expires. You must store the Refresh Token securely as if it were a password, because that's really what it is, it is used by OAuth2 to get a new 12 hour or something Application Token which is the one you use to access APIs. If you set AuthType to OAuthTypeMan, an event will be called in which you can send the email. The event could launch an interactive application, if the service is running on PC with someone watching the screen. Angus

I only remember one security patch for Delphi, well over 10 years ago, relating to a graphics function that did not check a PChar string length properly. Have there been any others? Angus

Sorry, never done any testing with THttpTunnelWSocket, it does seem to be used by the FTP components as a proxy option, but not tested that feature for a long time either. Angus

UDP application have to be designed to work around data loss, that is not the fault of a low level UDP component. If one loses packets and another does not, the first is probably less efficient. UDP is the basis of HTTP/3 and QUIC, which is reliable. Angus

If you have to send a response on SQL completion, you have to process all JSON in that request before sending a response, so a queue is not that useful, So this is down to your server design, if you are listening for connections that is a server, and you have still not explained how you are doing that, it is not a 'web site', it's a server. Another web server may be sending your server requests, but that is not relevant. Angus

You have still not clarified how exactly you are receiving the JSON, just a vague 'Cliente Server'. But if a new request is stopping an old request, it sounds like you have a single listener for receiving requests, whereas any proper server would accept multiple requests and handle each one separately, sometimes in a thread, but not necessarily with good program design and the ICS internet components. While a FIFO queue can help, there is a problem if you need to send a response for the SQL update status, particularly if you are continually opening and closing SQL connections. None of this design is really relevant to how many JSON records you receive, you just process them in one go, ideally with one SQL update. Angus

How are you receiving the JSON, with a web server or TCP service? I have a similar application that accepts data in various ways and writes to a SQL database, I use a FIFO queue (a stringlist) for the SQL stored procedures, so any that arrive faster than the SQL can accept them (about 20 per second) get queued. If the volume is really high, you can open multiple connections to the SQL server and do some in parallel. Angus