FPiette

First remove any display and logging. This slow down considerably the server. Use display (Progress and so on) and logging for debugging purpose or apply a strategy more complex that what is in the demo.

This is not very clear to me. Are the users HTTP clients connected to the HTTP server? Are those client local or remote? Your "app" look like a standard console mode executable. Your service can call it calling CreateProcess but be aware that a service run with a special account, even when no user is logged in Windows and certainly not the user that has logged in Windows. The account for the service has different permissions from the logged in user. You must grant all required permissions and it is not easy to "impersonate" the user that a HTTP client is representing.

I put all options into a single executable and at run time, I read a configuration file to set the features enable Boolean variables. The configuration file is an INI file which is protected by a digital signature the customer receive with his license. If he manually edit the INI file, then the signature is invalidated and the product fall back to demo mode. Using this method, there is only one executable and producing a new release is easy: every customer get the features his license allow, nothing more, nothing less. Each customer can download the executable to get an update. Since you use Delphi, you already know that Embarcadero is doing the same: The installer contains all versions, all languages. You get the pro version if you pais a pro license. You get the enterprise version if you paid for it. As easy as that.

I'm a long time developer of open source components and I know this problem very well. The idea is not to ask the component developer to implement something you'd like but ask very simple thing like making a method virtual or change a method visibility from private to protected. Then you'll be able to implement yourself what you need in a derived class. Asking for such simple things which present almost no risk to break something is likely to succeed. But asking the component developer to implement something for you will probably be rejected. You'd better chances to implement it yourself and suggest your changes.

I don't usually modify 3rd party source code. Sometimes, I inherit from the 3rd party, adding my code only in separate source. If what I need cannot be done with inheritance en encapsulation, if I still find the 3rd party code valuable, I contact the author asking him to make some methods virtual or expose new properties. If he doesn't want, then I don not use his code because - as you experience - it will be a lot of work in the future.

This is the command line OpenSSL tool. That is not what you need at this stage. You need the OpenSSL DLL. The name of the DLL depends on the version. For OpenSSL 1.1, there are two DLLs: libssl-1_1.dll and libcrypto-1_1.dll. They are in the same directory as the OpenSSL.exe that you found. If not, your ICS setup is corrupted.

Remove inline everywhere you see it.

FTP use two connections. One for commands and one for data. FTP OnRequestDone event is triggered for every command once executed. Did you had a look at the source code ? OnRequestDone event has an argument RqTyp of type TFtpRequest which is an enumeration of all 78 FTP commands. When in the IDE, use CTRL+Click to immediately jump to any identifier definition.

List of HTTP status code.

There is no such thing as "full help". The documentation is in the source code (Component and samples) and on http://wiki.overbyte.be The wiki can be updated by anyone willing to share his knowledge. Just ask write permission.

HTTP component is asynchronous, it doesn't need a thread to be non blocking. It will consume very few CPU. As I see your application, you don't need multithreading at all. A thread would be necessary if - for example - you have a lengthy computation.

If the problem is reproducible, try running the application under the debugger. If it only happens on the customer computer, ask him if you can use Delphi Remote Debugger thru Internet. The debugger will readily show where the exception occurs. And by the way, try downloading the same file using one of ICS demos to be sure the issue is located in ICS or in your application. François

It is likely an issue of a security product. Maybe a firewall or an "internet security" product which monitor outgoing connections. You must enable connections done by your application into those products.

Try with passive mode.

The download should always be done from http://wiki.overbyte.eu/wiki/index.php/ICS_Download which is more up to date. Currently, V8.64 is the latest stable version recommended.

I don't see anything wrong in line 277. Strangely both files have an error at the same line, same column. Download ICS again and retry.

Angus, this model is not suitable for CGI. A CGI module is expected to run as quickly as possible. If a queue and retries have to be done, it must be launched independently by the CGI so that it becomes an independent process. Or the CGI could call a service doing the actual send. Or other similar solutions.

Simply remove the inline keyword. This will not affect the function, only the performance.

Maybe there is a caching device between your application and the server. This device always returns the same result. Just a guess.

You need to look at your form. "Action" is the URL you have to use to submit your form. "Method" is the way to submit if: Get or Post which maps directly to HTTP component. Then you have to look at all "input" tags to find the name of the items to send. Then you have to format a buffer with name/values pair and submit it. François Piette

That is correct. But this doesn't prevent ICS from being used from several threads. ICS do not need multithreading to do simultaneous operations on hundreds of sockets. It works nicely on a single thread. You only need multithreading if you need thousands of ACTIVE communications. And you need thread to off-lone the communication thread from processing. For example, if you have a lengthy database request and use a synchronous (blocking component) then you need a worker thread for the blocking database request. If you create a thread for each communication, you'll be quickly have poor performances. The best is to balance number of thread and number of connections. If well designed, you can develop an application using ICS having as much thread as the CPU core and each thread handling hundreds of connections. Whatever component you use, it is sure that handling thousands of simultaneous active connections requires proper design and proper hardware.

This is how Delphi and Windows works. Anything related to Windows messages and many other things need to be created/destroyed within a thread's context not the thread constructor. This is because a thread constructor run on the context of the calling thread, which obviously not the thread under construction. If you had given a look at ICS multihread samples, you'd known...

Calling connect is not enough to send a mail. See the sample program, seen the code behind "all in one" button.

Colek, I would create a new component instead of modifying the ICS one. You can either inherit from THttpCli component or inherit from TComponent and embed a THppCli to do what needs to be done. Either way has pros and cons but both are exactly what object oriented programming is all about. Think about moving the logic behind your application into a component instead of putting it into a TForm.

Do you have full source code for the add-ons you use? If yes, it should be fairly easy to port the code to the current Delphi version. I have done that a lot of times with great success. Without source, you have to replace the old add-ons by current version if it exists or by other ones. This may be more difficult. Advice: never use an add-on without full source code. btw: If you want to discuss porting your code, you should post in another forum, maybe this one https://en.delphipraxis.net/forum/4-vcl/ if we are talking about VCL.