IpSuperTcp channels: SuperChannel TimeOut or Actively refused

Hello RemObjects support team,

We use the IpSuperTcpSuperChannel and IpSuperTcpClientChannel in our .NET WinForms application (version 9.4.109.1377). We have one client where they get the ‘SuperChannel timeout’ or ‘Actively refused’ error at least once a day. The only solution then is restarting the application service. It’s our biggest client, so with lots of clients and many server calls.

What could be the problem here? There is no virus scanner on the server and the domain firewall is disabled (+ we made an exception in the firewall for the used port for when the firewall would be enabled again).

Thanks for the assistance.

Wouter

Hello

If you’ll consider that the questions below contain sensitive information then please send answers directly to support@

How many calls are performed by client and how many clients are there?
Do you actively use server-sent events?
Are the client channel instances recreated on every client->server call or they are reused within the client app?
Do you use TLS encryption?
Which platform/.NET version uses the host where the server application is run?
Please run netstat -a -o -n several hours after the server app has been started and once it stops to accept client requests

Hello Anton,

There are 87 clients. A lot of calls are made with the remotedataadapter (hundreds of calls a minute I presume spread over all the different clients) and quit a lot of calls are made with RODL functions (tens of calls a minute spread over all the different client pc’s).

We do not use server-sent events.
The clientchannel instance is reused.

No TLS encryption.

Server side .NET version: .NET 4.7 Framework running on a Windows Server 2012 R2.

We’ll run the netstat command and get back to you.

Thank you.

Hello Anton,

The TCP IP port we use is 8090.

As promised a netstat when the application was working:

And a netstat when it stopped accepting client requests:
netstat.txt (10.4 KB)

Thank you.

Ok, that’s not so good. The 2nd listing shows lot of hanged up connections from a single client host.

What is different with the host 10.197.25.6 ? Different app? Flaky connection (or just a connection via Internet rather than LAN)?

Thanks, logged as bugs://82853

It’s a pc that’s connected to their network with a VPN connection. It’s the same app.

We implemented the IpHttpServerChannel. And now we get the FIN_WAIT_2 state and a lot of ‘Connection was closed’ problems. Any idea’s? Please, the problem is getting very urgent…

Thanks.

Are FIN-WAIT-2 connections present on server or on client side? Are they present on all clients, or only on ones that are connected via VPN?

The FIN-WAIT-2 state means that connection was closed properly (remote side did not confirm that the connection is actually closed).

Possible solutions -

Ideal - to make VPN connection more reliable

If that is not possible then you can
a) Set client channel’s property KeepAlive to false and check if that helps.

b) If that did not help then adjust the FIN-WAIT-2 timeout after which such stalled sockets will be released by the system itself:


Set registry key:

Key : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value Type : REG_DWORD

Valid Range : 30–294,967,295
Default : 120

Recommended value : 30


Disable tcp protocol autotuning:

netsh int tcp set global autotuninglevel=disabled

Restart the host

They are present on servers side… And it’s not only the clients with VPN connections who are experiencing the problem but also some clients who work in the local network.

Did you try to adjust the settings?