FPiette

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.

In the trace you provide, I see all GET commands are using HTTP 1.0 which don not support persistent connections as far as I know. You should request version 1.1.

Hello, As you are reading this message, you probably use ICS. Good! But have you taken time to register your ICS copy? ICS is freeware but to use it, you must register it. Registration is very simple: just mail a [real, paper] picture postcard to the author (me). You can find instructions in the readme8.txt file in ICS distribution. Thanks. PS: If you already sent your picture postcard, simply ignore this message. If you want to know if I received it, then you must tell me by email when you sent it, from which country and what the picture look like (I have several thousands postcards!).

@Bob4231, don't do that. I'm only interested in real picture postcard. If you really like ICS, maybe you'll take time to find a picture postcard in a nearby town. I think they are sold everywhere in the world. BTW: I already have more than 4000 postcards!

Please be more specific about the error and where it occurs. You should run your program Under the debugger if the error is an exception.