FPiette

Would be interesting if you explain what was the real issue. other user will find your message and will be happy with your explanation. Thanks.

In any application, any time-consuming operation can be implemented without thread by correctly making use of cooperative multitasking of Windows. That is use asynchronous operation. Any computing time taking significant time has to be divided in small chunk allowing other processing to take place. Any blocking task can be rewritten to work asynchronously by using worker threads. If you have to support a large number of concurrent and active clients, you'd better have a sufficient hardware. A simple desktop PC won't support the load. Use a real hardware server with multiple Intel Xeon and a huge memory (Something like 128GB of RAM look OK). Also think about network bandwidth and disk I/O throughput. Not all 1Gbps Ethernet adapter are actually able to sustain that speed. Maybe a 10Gbps network card is required with sufficient power on the adapter itself. About the disk, think about SSD but pay attention that they are not all equals, and if you need hard disks, they are also not all equal! Use 15krpm and high speed SAS disk adapter with lot of cache. Don't forget that RAID takes time. Use RAID1 which is less efficient that RAID5 in term of usable capacity, but is much faster. To summarize, you have to write the best software and run it on the best hardware to get the best performances. It is likely that the overall performance will be similar to the weakest piece in the chain.

Just checked right now. I can drag and drop a TWSocket (Or other) from component palette to the form.

Loooong time ago, back in 1996 when I started ICS, a went to that way. I quickly stopped it because it makes things much more complex for both the component developer and the component user. Since then, I am still happy to use delegation instead of inheritance. Inheritance is largely used in ICS, see TWSocket itself as an example. But delegation has to be used when it has to!

This is probably the best thing to do if you want to spare learning the inner working of TWSocket. All ICS components does just like that: create a new class and have one or more field of TWSocket type. By the way, given the log you showed, you are playing with HTTP protocol. Why not use ICS HTTP component instaed of TWSocket. This is the best choice unless you plan to reimplement HTTP. ICS HTTP component if really powerfull. Rewriting it is probably a huge work.

Putty can work as a SSH proxy tunnel (https://www.math.ucla.edu/computing/kb/creating-ssh-proxy-tunnel-putty). The idea is that you run Putty configured as SSH tunnel and you connect your ICS/TWSocket application to PuTTY which relay to the SSH server.

Welcome Everyone! Welcome to this forum intended for ICS support. Feel free to ask your ICS questions here. Before asking, search this forum and also check http://wiki.overbyte.be Please stay on topic. Use other forums for subjects not directly related to ICS. --- François PIETTE The author of the freeware Internet Component Suite (ICS) The author of the freeware multi-tier middleware MidWare http://www.overbyte.be

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).

No sure it is the problem but an ICS component must be created in the context of the thread handling his events. And that thread must have a message pump.

The hpp file is created by the compiler when you install the components. The source code is actually OverbyteIcsSspi.pas. This source code reference several windows SDK header files. Maybe you have a different Windows SDK? Also, look at the source code OverbyteIcsSspi.pas: it the file I have, the symbol SEC_E_INVALID_HANDLE is commented out.

Creating a DLL project and adding all ICS source code is not enough ! You have to export the function you want to have and since you use C#, no export function can have arguments or return value other than simple C data types. You also have to pay attention to strings and characters: in D2006, there where ASCII. Now they are Unicode (C# support unicode as well). Since you are using your old DLL, it is likely that you exactly know which functions are exported and which argument they have. You should reproduce than.