SuperTcpIPChannels timeouts


I use a DevExpress XtraScheduler control to display appointments for many years. In the event CustomDrawAppointment (which is called for every visible appointment) we sometimes have to go to our database with DataAbstract remoteDataAdapter to get a maximum of 4 lines in certain cases. This has always worked just fine before version .1543. We had to update to a later version and now we get a lot of timeouts if the call for the extra info is made more then one time in the event.

We make use of a SuperTcpIPClientChannel en ServerChannel for a very long time.
This is the error message with stack trace:

2023-04-26 15:45:39.6009|ERROR|Adire.DataProxy.DataService|(PlanningControleDataTable_FK_Planning) |System.Exception: Timeout waiting for a response
bij RemObjects.SDK.IpSuperTcpClientChannel.IntDispatch(Stream request, IMessage response) in c:\CI\b\rofx\937\RemObjects SDK for .NET\Source\RemObjects.SDK\ClientChannels\IpSuperTcpClientChannel.cs:regel 710
bij RemObjects.SDK.ClientChannel.Dispatch(IMessage message) in c:\CI\b\rofx\937\RemObjects SDK for .NET\Source\RemObjects.SDK\ClientChannels\ClientChannel.cs:regel 325
bij RemObjects.SDK.DynamicRequest.InternalMakeRequest() in c:\CI\b\rofx\937\RemObjects SDK for .NET\Source\RemObjects.SDK\RemoteService\DynamicRequest.cs:regel 182
bij RemObjects.DataAbstract.RemoteDataAdapter.SendFillRequest(DataSet dataset, String[] tableNames, TableRequestInfo[] tableRequests, WhereExpression[] whereClauses, Boolean applySchema, IList`1 tablesThatNeedSchema) in c:\CI\b\rofx\937\Data Abstract for .NET\Source\RemObjects.DataAbstract\DataAdapters\RemoteDataAdapter.pas:regel 494
bij RemObjects.DataAbstract.DataAdapter.InternalFill(DataSet dataset, String[] tableNames, TableRequestInfo[] tableRequestInfo, WhereExpression[] whereClauses, Boolean applySchema) in c:\CI\b\rofx\937\Data Abstract for .NET\Source\RemObjects.DataAbstract\DataAdapters\DataAdapter.pas:regel 286
bij RemObjects.DataAbstract.DataAdapter.Fill(DataSet dataset, String[] tableNames, TableRequestInfo[] tableRequestInfo) in c:\CI\b\rofx\937\Data Abstract for .NET\Source\RemObjects.DataAbstract\DataAdapters\DataAdapter.pas:regel 364

I’ve already tried to make some changes to make use of a HttpServerChannel en ClientChannel and then it seems to work without timeouts. Are there problems with the SuperTcpIP channels? Is something changed that I don’t know about?

Thank you so much for helping.



Can you launch server-side in debug mode and see that errors are raised on server-side, pls?


No exceptions are raised server-side… I have no idea what’s going.
I’ve changed my code already so that a RODL function is used to just return a count of the maximum 4 rows out of a database table. After some time (multiple calls made) the same timeout error is thrown:

2023-04-28 09:12:29.8809|ERROR|Adire.DataProxy.DataService|(GetCountPlanningControlesByPlanningPrimkey): Fout bij ophalen aantal planningcontroles
|System.Exception: Timeout waiting for a response
bij RemObjects.SDK.IpSuperTcpClientChannel.IntDispatch(Stream request, IMessage response)
bij RemObjects.SDK.ClientChannel.Dispatch(IMessage message)
bij Adire.Server.AdireServerService_Proxy.GetCountPlanningControlesByPlanningPrimkey(Int32 plnPrimkey) in C:\Dirmacom Projects\XLent Planning\Source\AdireServer\AdireServerLibrary_Intf.cs:regel 2794

Client side code:

public static int GetCountPlanningControlesByPlanningPrimkey(int plnPrimkey)
                IAdireServerService _service = CoAdireServerService.Create(_instance.binMessage, _instance.MyClientChannel);
                return _service.GetCountPlanningControlesByPlanningPrimkey(plnPrimkey);
            catch (Exception ex)
                LogException($"({nameof(GetCountPlanningControlesByPlanningPrimkey)}): Fout bij ophalen aantal planningcontroles\n", ex);

Serverside code:

public int GetCountPlanningControlesByPlanningPrimkey(int plnPrimkey)
                IDbCommand command = ServiceSchema.NewCommand(Connection, "CountPlanningControlesByPlanningPrimkey");
                ((IDataParameter)command.Parameters["@plnPrimkey"]).Value = plnPrimkey;

                return (int)command.ExecuteScalar();
            catch (Exception ex)
                throw new EXLSServerException("Server Exception (GetCountPlanningControlesByPlanningPrimkey): " + ex.Message);

The server, client and database are all running on my localhost development machine (i9, 32GB RAM) so that’s not an issue.

Some extra info (but I think you already know because of the log in previous message), but the ‘hang’ happens on the clientChannel.Dispatch(___localMessage):

public virtual int GetCountPlanningControlesByPlanningPrimkey(int plnPrimkey) {
            RemObjects.SDK.IMessage ___localMessage = this.___GetMessage();
            try {
                ___localMessage.InitializeRequestMessage(this.ClientChannel, "AdireServerLibrary", this.ActiveInterfaceName, "GetCountPlanningControlesByPlanningPrimkey");
                ___localMessage.WriteInt32("plnPrimkey", plnPrimkey);
                int _Result = ___localMessage.ReadInt32("Result");
                return _Result;
            finally {


this means that server’s response isn’t received by client-side
You can try to increase IpSuperTcpClientChannel.RequestTimeout

When I step over the breakpoint at ClientChannel.Dispatch here, the breakpoint serverside isn’t hit, so it’s like there’s a kink between client and server… I’m absolutely not an expert in this, so I hope you know what’s going on :slight_smile: .

It’s already on 60 seconds… Just to get a count, that’s too long.


can you check that server’s address:port is valid?

Can you create a simple testcase that reproduces this issue, pls?
You can drop email to support@ for keeping privacy

It’s certainly valid.

Why do you think no problem occurs when I change the code to work with HttpChannels?

I will try to create a testcase, but it won’t be easy. It’s a legacy app, so I’ll need to replicate the correct stuff for you to try out.


Plain channels work differently in comparing with super channels.

You can try to implement your method in new testcase from scratch. if it works as expected, try to compare channel settings.

Which channel is the best then for a ‘old-school’ client-server application with lots of clients requesting sometimes big chunks of data from one server?


I can suggest plain TCP or HTTP channels.

The TCP Channel uses a lightweight protocol over raw TCP, introducing basically zero traffic overhead on top of the transmitted message data.
HTTP channel can work through firewall or/and with proxy servers.

If you don’t use server-side events that should be delivered asap to clients, plain channels are good choice.

I’ve changed the channels to normal TCP Channels and like with the normal HTTP channel, I don’t have the timeout problem anymore. So it has something to do with the superChannel.
I have the feeling the normal TCP channel is a bit slower. Am I right, or is this a problem in my head :sweat_smile: ?

To be continued the coming weeks.


the last significant change on IpSuperTcpClientChannel was 4 years ago.

can you test SuperTCP Chat sample (.NET), pls?

You can use any channel. if your testing shows that HTTP channel a bit faster so use it instead of TCP.