FPiette

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.

Thanks for feedback. Could you please make the fixed project available for other users?

Try adding Crypt32.lib to the project.

Why not put a try/except in you OnDataAvailable event handler?

I don't see in your log that the persistent connection fails. I only see that the server is not happy with the request ("401 Invalid client!"). If the request succeed you get a 200 response code, not a 401. You should first resolve that. Maybe a cookie is required or some specific header lines.