TristanC

I only use ICS for TCP and UDP server <-> client connection so I can't tell you for sure. But as the issue you encountered with your FTP server was very similar to the problem I has with my TCP server I am encline to believe it could fix it as well

Yes my c++ TCP server seems to work correctly. However I am currently implementing unit tests to check that the behaviour we have with c++ builder XE8 / ics 8.4 will remain the same with c++ builder12.3 / ics v9.4. I will come back to you with the results. Regarding the include of winsock2.h, I think it is due to this line in OverbyteIcsTypes.pas As it includes Winapi.Windows which itselt references the file winsock2.h

Okay thanks for your answer. So if it has been added in july, it means that it wasn't in the 9.4 official release right ? Which explains why I didn't have a compiler complaint before. But then I am not sure I understand what was the problem before because it looked like the client socket weren't properly created which could still be linked to a conflict with the winsock files, although I don't know exactly how

Hello Angus, I might have finally found what the issue is. I have tried to reinstall the ICS suite, except that instead of taking the ICS-V9.4 download, I took the ICS-V9 Snapshot one. And after the installation, when trying to compile my project, I had an error that I never add before : [bcc32c Error] OverbyteIcsTypes.hpp(398): expected unqualified-id [bcc32c Error] OverbyteIcsTypes.hpp(399): expected unqualified-id [bcc32c Error] OverbyteIcsTypes.hpp(400): expected unqualified-id relative to this part of the OverbyteIcsTypes.hpp file And apparently, it is due to CF_ACCEPT, CF_REJECT and CF_DEFER being already defined in <winsock2.h> for the WSAAccept function : https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsaaccept I have then added a check to undefine these variables before they are defined in the cpp like this : It now compiles and when I connect a client I finally have the information of the client displayed on my server side. However, while working, I am not sure yet if my solution can cause other issues down the line. Is it on purpose that these variables where named similarly to the windows defined ones ?

What are the 2 samples ? I have tested the compiled executable OverbyteIcsIpStrmLogTst.exe in server mode and it works perfectly.

Hello Angus, Sorry for the delay, due to other constraints, I couldn't continue testing before today. I am trying to set up a TCP server through the IcsIpStrmLog component with logprotTcpServer as the LogProtocol. I used the doServerClick function in OverbyteIcsIpStmLogTst1.pas file as an inspiration to build a simple server. The server launches fine but I encounter an exception when I try to connect a client : Socket operation on non-socket in setsockopt(SO_SNDBUF). Here is the call stack of where the error occurs : Do you have an idea what could cause this ? Could it be linked to my issue with the TWSocketServer ?

Ok, thanks for your time and help. Do you know if there is a way enable low level debugging of the ICS components so that I can more easily investigate it ? And how are the .cpp files generated, are they done on your side or converted automatically from Delphi .pas files ? My question being if there is somewhere I can look into the source files in c++ as I don't know Pascal.

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.

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

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

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.

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 :

Hello, it has been quite some time but I am encountering exactly the same issue as you, except with the TWSocketServer component when I try to create a very basic TCP server. I receive an OnClientConnect event when I try to connect for the first time but then, just like in your case, the TWSocketClient * that is passed to my function appears to be unitialized. And then my server doesn't handle any other event. Have you found the root of your issue or a way to circumvent it ? Thanks in advance for your help

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 :

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 ?