Angus Robertson

OpenSSL has issued a new release 3.5.2. In OpenSSL 3.5.2, the FIPS provider now performs a PCT on key import for RSA, EC and ECX. Windows binaries are available in SVN and the overnight zip file and separately from https://wiki.overbyte.eu/wiki/index.php/ICS_Download or https://www.magsys.co.uk/delphi/magics.asp In addition to the three DLL files, the zips include compiled RES resource files that contain the same DLLs, text files and version information, see the RC file. The RES file may be linked into application EXE files and code then used to extract the DLLs from the resource to a temporary directory to avoid distributing them separately. ICS V9.1 and later optionally support loading the resource file. These OpenSSL versions are included with ICS V9.5 beta available from SVN and the overnight zip. ICS V9.5 beta now defaults to using OpenSSL 3.5.2, provided the new OverbyteIcsDefs.inc files is installed, or you undefine OpenSSL_35 and suppress an earlier version. Angus

I don't believe the logging code built into ICS will help you, I hardly use it myself and I do all ICS development. It looks pretty to have lots of information logged, but it was originally written for SSL development, but that has been stable for years. No idea how the CPP files are created, certainly not by me, but I know some ICS units contain {$HPPEMIT 'Symbol'} hints for those files added 10 years ago and not touched since. So perhaps there are hints missing, but not being a C++ developer, someone else will need to fix them. It's likely other C++ users have fixed units in the past, but rarely do they get shared. Since TIcsIpStrmLog seems to work OK, you could try adapting your application to use that, it mostly uses simple non-object parameters. The OverbyteIcsAppMonSrv unit is the best example of using it as a server to handle multiple clients at a time. Angus

SVN has new versions of the Websocket components and three samples, will be zipped overnight. IcsAppMonMan which contacts multiple Websocket servers is much better on startup with async connections. Angus

If the sample used to work on old versions of C++ and fails now, that would suggest something has changed in C++. Perhaps the way classes are declared has changed in C++, or the C++ header files are not created correctly. But not being a C++ developer, I'm afraid there is nothing more I can do. Diagnosing this needs help from someone that actually understands C++. If changes are needed to make ICS compatible with C++, I'll do them when someone tells me what to change. There seem to be a lot of C++ developers using ICS, maybe old versions, but it's at least two years since someone supplied a C++ fix to me. Angus

And yet the debugger shows some of the TWSocketClient properties, albeit not some I'd expect to be set. We know the SocketServer component is working correctly when used in other components. In your original code, I don't see any public client class declaration, our sample has: TTcpSrvClient = class(TWSocketClient) public RcvdLine : String; ConnectTime : TDateTime; end; This should be assigned to the server as WSocketServer1.ClientClass := TTcpSrvClient;, but your code has Server->ClientClass = __classid(TTestClient); where TTestClient is not defined publicly, only within another procedure. If you remove the line setting the ClientClasss, the Client parameter should then contain the correct values. Angus

Have you tried avoiding the cast for (Client : TWSocketClient) but accessing it directly, ie Client->GetPeerAddr())? That should get you past onClientConnect, but you still need a cast for onDataAvailable. Angus

I guess I don't understand your real problem. In which specific server event, which passed parameter is empty? In your TForm1::ClientDataAvailable, I don't see a client declared, but C++ is meaningless to me. In Delphi we'd declare Client, set it, then use it. Our sample has a clear 'Client = (TTcpSrvClient *)Sender;' which I understand. Angus

I didn't mean convert the TIcsIpStrmLogs sample, but put more events and logging into your own application. Or compare yourold C++ OverbyteIcsTcpSrv sample with the current Delphi version, which I updated and tested last week for a new TWSocketServer event. Until then, the only changes in the sample in 15 years were to add a new unit, Types. Angus

I can only suggest logging in the various server events, as the TIcsIpStrmLog component does so you can track the problem. It is unlikely to be with the ICS code. Angus

I'll look at your changes, but I rewrote the WSConnect function yesterday, adding an async option so it is no longer blocking, which was a serious anomaly for ICS. I've also changed the ICS server component not to send welcome or other data immediately, before the client has a chance to process the 101 command and switch to Websocket mode. Still testing all this. Angus

I meant test your original code or the ICS OverbyteIcsTcpSrv sample against the ComGen data stream. Angus

So now you just need to disconnect and reconnect a few times to make sure close session is working. Then test again with your original data source. I often find testing with alternate clients or servers shows up missed issues ComGen on mahpub5 is configured to just send a line every 10 seconds, but it could be 100 lines per second, or lots of short repeated sessions. It uses an array of TIcsIpStrmLog components, so does everything that component does. Angus

Good, so at least the ICS socket server component is behaving correctly, but does not explain why it fails when you use it at a lower level. Try connecting to non-SSL port :21502 on my server and see if your own code receives the same information? If not, you need more diagnostics to see what is happening. You are connecting to a free tool I wrote called ComGen which I've used extensively for testing ICS over 15 years. Angus

Should be done in SVN in a couple of days. Angus

I'm afraid the C++ samples have not been tested for 13 years. Please try running the sample OverbyteIcsSnippets, click Remote Socket Traffic, and data should start appearing from one of my servers. All the code is in a single function, doSocketRemoteClick that should be easy to convert to C++ If that fails, we do have a serious C++ problem. Angus