Linux + TROSuperTCPServer + TROSuperTCPChannel + RemObjects + Slow Free/Disconnect

TServer_Connection = class(TInterfacedObject,IXXXXX)
BinMessage: TROBinMessage;
AESServerComp: TROAESEncryptionEnvelope;
channel: TROSuperTCPChannel;

I am using the above in a simple test setup in a Linux 64bit app with Delphi 10.2 (25.0.29899.2631)

Because Synapse doesn’t work in Delphi on Linux (but does on Freepascal),I have to use the TROSuperTCPChannel based on Indy.
The server uses TROSuperTCPServer on Windows

With the RO Server (Windows) running on the bare metal and linux (CentOS7) running as a HyperV VM, I experience a 24-30 second delay when freeing the TROSuperTCPChannel which seems to be occurring in the active=false/disconnect code of indy.

my indy reports version for TIdTCPClient

Is it possible to confirm this report and provide suggestions…

I’m currently doing this, but not sure if it is a good solution long term

It would be good to have a fully working SuperChannel/Server for linux :slight_smile:

procedure TServer_Connection.done;
newTask: ITask;
newTask := TTask.Create( procedure()
end );

if you created client with Lazarus and synapse channel, would it work without such delays?

DelphiIndyProject.dpr.pas (1.2 KB)
LinuxSynapseProject1.lpr.pas (1.1 KB)

I’ve tried to make these projects and test beds identical
Both executing on the same virtual machine (CentOS7) connecting to the same Windows RO server
The only difference is one is built using Synapse and Lazarus and the other is Delphi and Indy. rename .dpr.pas to .dpr. Both console applications.

Here is the output

19:28:22.850: Start
Server Time = 19:28:11.912
19:28:22.865: Done

Delphi + indy
19:32:01.451: Start
Server Time = 19:31:50.517
19:32:25.474: Done

it seems to be some problems with Indy itself because main functionality of SuperTCP are put to base class (TROBaseSuperTCPChannel)

I agree but I’m hoping as a company you can review and resolve the issue with indy or make a fix internally as you guys are meant to be the experts in this stuff.

Normally this might not be as bigger issue with synapse as the alternative, but as it stands with the lack of progress on any resolution to make synapse and delphi working together you effectively have no properly working TCP socket on Delphi + Linux which is disappointing after 12 months.

I appreciate Delphi isn’t the flavour of the month @ RemObjects anymore but many of us still need or want to use it and we have been your loyal customers for many years before the exciting new water/elements etc projects began. It would be nice to see a little more time put into RemotingSDK especially ensuring it works out of the box with Lazarus and Delphi on Linux as Linux is the perfect operating system for Remoting servers.

I feel like I’m paying for your product and doing your alpha and beta testing at the moment on Linux.

1 Like

Thanks, logged as bugs://80061

I can’t say terms when it will be fixed


can you reproduce this issue with socket version of SuperTCP?