Issue with basic TCP server and ICS 9.4

[TristanC 0]

First let me preface it by saying I use ICS with C++ Builder 12 and not with Delphi.
I apologize if this is not the right place to talk about my issue but it is the most active place I found discussing ICS.

I am trying to build a very simple TCP server using a TWSocketServer accepting connections from TWSocketClient.

I have coded such a server on C++ Builder XE8 with ICS 8.47 and it works just fine.

However, I am in the process of upgrading to C++ Builder 12 and to ICS 9.4 and it is where my issues start.

The server starts fine, and when I try to connect a client, I get the event and the client is accepted.
However, when I check the client data in the debugger, everything is set to NULL.

And after this first connection, my server doesn’t receive any other event, whether it is other clients connection, the deconnection of a client or any data that a client might send.

Does someone have any idea what could cause this ?

I have enclosed my .h and .cpp files but it is very basic.

Unit1.cpp

Unit1.h

[Angus Robertson 658]

Are you saying the same code runs OK in the older version of ICS, but not the new version?    

 

You don't say what your project is for, but you would be better starting with the TIcsIpStrmLog component that hides all the low level stuff from you, try running the pre-built OverbyteIcsIpStmLogTst sample, configuring it as a TCP Server, and start it.  All the logging for diagnostics is built in. 

 

Angus

 

[TristanC 0]

Hello,

Thank you for your answer.

Yes it is running ok for ICS 8.47 / C++ Builder XE8 but not with ICS 9.4 / C++ Builder 12.
The project I enclosed is just a simple project I did to test ICS components. I was in the process of migrating an application from C++ Builder XE8 to C++ Builder 12 when I noticed that some of my implementations using ICS were no longer working.

I haven't found the OverbyteIcsIpStmLogTst in the demos-cpp-vcl folder, only in the demos-delphi-vcl and unfortunately, I don't have delphi on my version of C++ Builder.

[Angus Robertson 658]

You can download prebuilt samples from https://wiki.overbyte.eu/wiki/index.php/ICS_Samples to avoid building them yourself. 

 

Sorry, no idea why your sample no longer works, but I don't write C++ so can not test it.  I am very careful when updating ICS to make it remain compatible with older versions of Delphi, events and such like rarely change.  

 

Logging events is the only to debug your problem.  

 

Angus

 

[TristanC 0]

Thanks for the link, when I use the .exe directly it works fine both with OverbyteIcsTcpSrv.exe and OverbyteIcsIpStmLogTst.exe
But I have tried recompiling the the OverbyteIcsTcpSrv from the cbproj file in the demos-cpp-vcl folder and here it doesn't work.

I am at a loss for why but I will keep investigating, thanks for your help

[Angus Robertson 658]

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

 

[TristanC 0]

I translated it to a C++ Builder 12 project and it appears to be working, or at least I get output similar to what I am getting from the .exe snippet

[Angus Robertson 658]

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

 

[TristanC 0]

I receive the same kind of data when I switch to port 21502 and deactivate SSL so it appears to be working as well.

Additionnally I have checked that the lines that I receive with my code on the SSL port is the same as what is received through your own snippet tool

[Angus Robertson 658]

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

 

Edited Monday at 03:43 PM by Angus Robertson

[TristanC 0]

I am not sure to fully understand ?
Do you mean testing this client against the server I coded originally and wasn't working, in order to test if the issues were linked to the clients or to the server ?

[Angus Robertson 658]

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

 

Angus

 

[TristanC 0]

I have tried to connect to my original server using the RemoteSocket component.
However I have the same issue that I had originally, the connection event is detected but the client appears not to be initialized.
As a result, I don't receive any of the data I send from my server, getting this error on the server side :

[Angus Robertson 658]

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

 

[TristanC 0]

Thanks, I will try to convert it from Pascal to C++ in order to log all information and see if I can understand why the TWSocketClient *Client that is passed to my OnClientConnect function is basically empty.

I have also found this topic that is awfully similar to what I am facing, maybe they will be able to help me : 

 

[Angus Robertson 658]

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

[TristanC 0]

Sure but for now except understanding that the TWSocketClient is empty when passed I haven't been able to successfully log anything as my server appears stuck after. Notably, I can still successfully connect with clients but don't receive any connection event on the server side. So it was more about looking at the logs in the TIcsIpStrmLog.pas to see if I can add something I missed.

Yes, I looked at the .pas files for OverbyteIcsTcpSrv both in the 9.4 release and here : https://svn.overbyte.be/svn/icsv9/demos-delphi-vcl/OverbyteIcsTcpSrv1.pas
9.4 release is almost identical to the .cpp samples baring some additional logs.
And based on the last version of the file, I have implemented an OnClientCreate event, but the TWSocketClient * passed to this function is empty as well.

[Angus Robertson 658]

Quote

TWSocketClient is empty when passed

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 

[TristanC 0]

My issue is that on the WSocketServer1ClientConnect function, I am supposed to receive a TWSocketClient* object that is then cast into a TTcpSrvClient*. For Delphi it is equivalent to the Client object passed here : procedure TTcpSrvForm.WSocketServer1ClientConnect(Sender : TObject; Client : TWSocketClient; Error  : Word); and then the case into a  TTcpSrvClient* is similar to this with Client as TTcpSrvClient do begin.
The issue is that the TWSocketClient* that is passed to my function seems to be badly initialized as all its properties are set to NULL or are empty.
In the screenshot below, I have set a breakpoint in the WSocketServer1ClientConnect function function and on the right in the debug inspector, you can see the properties of the Client object that is passed, which are mostly set to NULL or default values. In particular FPeerAddr and FPeerPort are both NULL.
The result of that is that I cannot communicate with the clients from the server afterwards and I also don't receive any other event (connection, deconnection, data sent...)

 

And as you can see, when the client connect, I don't have any info about it :

 

While when I use the sample executable directly (which I think must be compiled from Delphi), I have the correct informations about the client

 

 

[Angus Robertson 658]

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

 

 

 

 

 

[TristanC 0]

Yes, I have tried that at first and it doesn't solve the issue unfortunately. The object that is empty is the Client : TWSocketClient, casting it into another custom class or not has no impact

[Angus Robertson 658]

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

 

[TristanC 0]

I have tried it but unfortunately, the Client object is still the same.
For it being easier, I am now doing all the tests of the c++ version of the OverbyteIcsTcpSrv sample.

[Angus Robertson 658]

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