Issue with basic TCP server and ICS 9.4

[Angus Robertson 662]

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

 

 

 

[TristanC 1]

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 ?
 

[Angus Robertson 662]

The Snippets sample has two simple examples of using logprotTcpServer mode.  Did you the compiled sample work OK as a sample?   No idea why it fail would from C++.

 

Angus

 

[TristanC 1]

What are the 2 samples ?

I have tested the compiled executable OverbyteIcsIpStrmLogTst.exe in server mode and it works perfectly.

[Angus Robertson 662]

doSocketLocalClick has both a client and server, you only need the server code.  But it's very similar to OverbyteIcsIpStrmLogTst so may not help you get closer to the real C++ problem.

 

Angus

 

[TristanC 1]

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 ? 

[Angus Robertson 662]

CF_ACCEPT and CF_REJECT were only added to ICS this July, I'll rename them to avoid any conflicts with C++ header files.  

 

But it probably brings us closer to the problem. 

 

If you include C header files that diverge from the Pascal conversions we use, a mix of Delphi RTL and ICS own versions, conflicts might arise, ideally flagged by the compiler as in this case. 

 

The RTL conversions are rarely updated for new APIs, the Win services unit is missing stuff added 20 years ago.  And since ICS has to be compatible with Delphi 7, we need our own anyway.  

 

Angus

 

 

 

 

[TristanC 1]

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

[Angus Robertson 662]

Perhaps the July change forced C++ to rebuild header files for the ICS components? 

 

So your C++ TCP servers are now behaving correctly? 

 

As I've said before, my understanding of how all this works is zero.  Perhaps old headers should be deleted when packages are built, maybe that is what experienced C++ developers do, but that information needs to be fed back to me, so I can fix the root cause.  

 

Angus

 

[Angus Robertson 662]

Why did your project include winsock2.h? 

 

ICS applications should not need any winsock literals or types, others than those defined in OverbyteIcsTypes or other ICS units.  

 

Angus

 

 

 

[TristanC 1]

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

[Angus Robertson 662]

I don't see any references in the Delphi WinApi. Windows unit to winsock2.h, except as a single comment. 

 

But there are lots of $HPPEMIT defines bringing in other files like wintrust.h, so I guess that is how winsock2 comes in.  

 

At least the problem is fixed, for now.  

 

Angus

 

[w0wbagger 6]

15 hours ago, TristanC said:

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

Tristan, did this fix the issues you were having with the FTP component(s) as well? 

Thanks,

Ian

[TristanC 1]

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