FPiette

You should create a worker thread for the lengthy database operations and keep your TCoreWebServer run in his own thread. Having the database thread will transform blocking database operation into non blocking one which will nicely fit into the ICS stuff. Having specialized database thread will also be easier to develop and debug.

You'd better replace your loop by an event chain. This is easy to do once you understood event driven programming. This being said, you can make a synchronous version by using a wait loop. This will waste CPU...

Beside the sample Angus mentionned, you may also have a look at the sample OverbyteIcsSvcTcp.dpr. It is a simple service using TWSocket. Replacing TWSockt by any other ICS component do not really change the code. Note that this sample is organized so that the server code can be used within a normal application which is also provided (OverbyteIcsSrvTcp.dpr). The actual server code, common to the service and the application can be found in OverbyteIcsTcpCmd.pas. It is much easier to develop using this dual application (Normal and service): you mainly debug the normal application and when it works correctly, you recompile using the service environment. F. Piette

There is no such example in ICS. Are you interested by the server side (I mean Web server)or by the client side (I mean Web browser)?

You should rewrite your program to use async requests. This has better performances and is the recommanded way of using ICS.

Look at TWSocketServer if you want something basic able to listen for client and instanciate new TWSocket for each client. It doesn't do anything special related to HTTP protocol which is handled by THttpSrv component. As you can see there is a full hierarchy of classes each one being more intelligent. TWSocket is below everything, TWSocketServer add support for server features above TWSocket. THttpServer add HTTP protocol support (server side) to TWSocketServer. THttpAppSrv add REST application layer to THttpServer. In this hierarchy, there are some more intermediate classes for "custom", "Line mode", "proxy", "SSL/TLS" and more.

HTTP protocol is more complex than you think... There is also THttpAppSrv component and his demo application OverbyteIcsWebAppServer. THttpAppSrv is more oriented to answer with "computed" responses.

It looks like you are rewriting HTTP protocol. Why don't you use the HTTP server component. It does everything for you. See sample programs containing HTTP server component.

Maybe SendStrLF is the culprit:HTTP protocol need CRLF and the end of each request header line. And an additional CRLF at the end of header. The the document must follow, if any.

Sorry, I have no idea. It looks like you feed bad parameters to the component. I suggest you restart from beginning, starting with the samples provided which are working. Then modify the sample step by step until it either works for you or fail. If it fails, use the debugger to try understand what is wrong.

In a previous message you told us you get back an error message from the server, right? Go back to this situation and using WireShark, capture the request and the response. Compare it with the "reference" application.

Do you have another application able to request the same server? If you do, I suggest you use WireShark to spy on the data passing thru the network from that application and then do the same with you own application. Comparing to two traces, you'll probably discover what is wrong in the data formatting you use.

After compiling the packages, you must install the design time packages. Right click on the project and select "install" in popup menu.

There are at least two important rules to write a multithread program which make use of ICS: 1) All ICS components must be created in the context of the thread. This is done for example in the start of thread's Execute method. 2) The thread must have a message pump also called message loop. There is one prebuilt in TWSocket. Have a look at OverbyteIcsThrdSrv1. pas (A unit in one of the ICS samples) and look at TClientThread.Execute. As Angus said, ICS is able to handle hundreds of connections in a single thread as far as ICS is concerned. Of course you may have heavy processing requiring a thread to not block the system. ICS is asynchronous, non-blocking and event-driven. It has all the required features to avoid multi-threading. And if you need multithreading, you should probably consider having tens or hundreds of ICS component in a single thread (For example, if you need 1000 component working simultaneously, use 5 threads each handling 200 components. Or if you have not that much simultaneous components, another design is to have a single thread for all ICS component and then a thread for each lengthy (computation or blocking operation) process. A good multithreading application is hard to write and hard to debug.

I looked closer to you code. I don't see any message pump. The component cannot work. See multithreaded sample programs delivered with ICS. They all include a message pump (GetMessage/PeekMessage.DispatchMessage and so on).