# Large number of TCP connections with Time\_Wait status
**URL:** https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680
**Category:** Remoting SDK
**Tags:** delphi
**Created:** [July 29, 2014, 8:55am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680 "2014-07-29T08:55:16Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@impet](https://talk.remobjects.com/u/impet)
#### Post date: [July 29, 2014, 8:55am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/1 "2014-07-29T08:55:17Z")
Hello support.
We develop a server on Delphi, using TROIndyTCPServer component, and a client on .NET, using IpTcpClientChannel component.
Large load on the server leads to large number of TCP connections with Time\_Wait status. Number of such connection may grow and
exceed system resources which results in errors when connecting to the server.
Another concern that such behavior will lead to DOS attack vulnerability when server is accessible via internet.
To reproduce:
1. Run (on different computers in a local network) MegoDemo client from .NET examples and MegoDemoServer from
Delphi examples.
2. Activate Indy TCP server in MegoDemoServer.
3. Select the TCP Channel option in MegaDemo client and click the Run Multiple Tests button.
4. Using NetStat or TCPView tools you can see tcp connections in time\_wait state.
Advise how to resolve this problem?
---
### Author:  [@impet](https://talk.remobjects.com/u/impet)
#### Post date: [July 31, 2014, 10:31am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/2 "2014-07-31T10:31:35Z")
Can anybody from RemObjects support help me with this issue ?
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [August 1, 2014, 1:25pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/3 "2014-08-01T13:25:33Z")
sorry for delay, we are working with it
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [August 4, 2014, 7:30am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/4 "2014-08-04T07:30:09Z")
according to [TCP](http://en.wikipedia.org/wiki/Transmission_Control_Protocol), this state is valid tcp state and it is equal to 4 min by default.
please read [msdn](http://msdn.microsoft.com/en-us/library/aa560610%28v=bts.20%29.aspx) how to reduce this value.
---
### Author:  [@impet](https://talk.remobjects.com/u/impet)
#### Post date: [August 5, 2014, 9:43am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/5 "2014-08-05T09:43:56Z")
Of course, I am aware that TIME\_WAIT is a valid connection state. But it does not mean that accumulation of such connections is a valid behaviour of server application! In my opinion, server application should never initiate disconnection, so TIME\_WAIT connections will accumulate on the client side (which is obviously less critical).
Just want to repeat once more, uncontrolled accumulation of TIME\_WAIT connections on the server side might be a serious problem (used for DOS-attacks on publicly available servers, for instance).
So, I would like to get some recommendations how to build such servers in a reliable way, or get official confirmation from RemObjects that RemObjects SDK can not be used to build such servers.
P.S. I am interested in using TCP Indy channel because of performance reasons. We got best performance results using TCP Indy on the server side.
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [August 5, 2014, 11:19am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/6 "2014-08-05T11:19:56Z")
in general, better to ask about TIME\_WAIT connections in Indy community, because TROIndyTCPServer is layer over TIdTCPServer.
direct access to TIdTCPServer can be received via [IndyServer](http://wiki.remobjects.com/wiki/TROIndyTCPServer_Class#IndyServer) property.
---
### Author:  [@impet](https://talk.remobjects.com/u/impet)
#### Post date: [August 5, 2014, 11:35am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/7 "2014-08-05T11:35:49Z")
I was hoping that this will be looked by RemObjects as providers of SDK. Of course I can look into this myself, I even can write server without using RemObjects SDK at all.
What is purpose of support from RemObjects SDK is this case ? Just say some obvious things ?
I bought product from RemObjects. So I need answer from RemObjects how this problem should be handled.
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [August 5, 2014, 12:41pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/8 "2014-08-05T12:41:35Z")
TIME\_WAIT is a common problem with tcp and its outside the scope of RO SDK.
See [this](http://stackoverflow.com/questions/337115/setting-time-wait-tcp) post for more details.
Also [Avoiding the TCP TIME\_WAIT state at Busy Servers](http://tools.ietf.org/html/draft-faber-time-wait-avoidance-00) article can be useful for you.
---
### Author:  [@impet](https://talk.remobjects.com/u/impet)
#### Post date: [August 5, 2014, 1:06pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/9 "2014-08-05T13:06:33Z")
I KNOW IT IS COMMON PROBLEM. You can stop repeating this.
Thats why I ask - how RemObjects handle it in THEIR product (RemObject SDK)?
I bought RemOBject SDK to build publicly accessible application servers.
How you propose me to make them reliable using RemObjects SDK ?
Are you telling me that it is not possible (outside scope of RemObjects SDK) ?
Well, in this case you should mention it more clear on product description page.
---
### Author:  [@mikeo](https://talk.remobjects.com/u/mikeo)
#### Post date: [August 5, 2014, 1:31pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/10 "2014-08-05T13:31:46Z")
I’m not sure what you expect us to do. You have been told the common way of fixing it and you are the first that I remember asking for this.
You are testing an extreme condition and, imo, the setting of a lower value of Time\_Wait should solve it.
Regards,
Mike Orriss
CFO, RemObjects Software
---
### Author:  [@impet](https://talk.remobjects.com/u/impet)
#### Post date: [August 5, 2014, 2:38pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/11 "2014-08-05T14:38:57Z")
> [@mikeo](#):
>
> I’m not sure what you expect us to do
Ok, will try to explain my expectation.
I expect that when I use tool designed to build servers, this tools will handle all “common” problem itself.
For example, when I use Microsoft IIS, or Apache - I am not willing to resolve problems like TIME\_WAIT connections. it is all handled internally.
> [@mikeo](#):
>
> I’m not sure what you expect us to do. You have been told the common way of fixing it and you are the first that I remember asking for this.
Could you please repeat for me this “common way of fixing” ? What exactly you have told me to do?
I will
---
### Author:  [@Will\_Honor](https://talk.remobjects.com/u/Will_Honor)
#### Post date: [August 5, 2014, 8:39pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/12 "2014-08-05T20:39:21Z")
Personally, I use keep alive connections with the nagle algorithm switched off. Then you won’t have an issue with time\_wait.
Are your tests real world? do they represent actual usage of your application? if you will have a small number of users creating a lot of requests over a long period then use keep alive connections. If you will have a very high number of users creating only a small number of requests then read on…
You are testing the application on a lan so can exhaust the available connections easily. On a windows server 2003 with default configuration you will get about 33 connections per second before running into trouble. On newer servers and after reconfigurig the tcp time\_wait to wait for less time, and increasing the available pool of ports, you can push this up to 500+ connections per second.
This really is an operating system configuration issue rather than something specific to RO. Your argument that apache and IIS handle this for you does not appear to be correct as there are plenty of people asking the same questions about those.
good luck.
Will.
---
### Author:  [@Will\_Honor](https://talk.remobjects.com/u/Will_Honor)
#### Post date: [August 5, 2014, 9:00pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/13 "2014-08-05T21:00:04Z")
> [@mikeo](#):
>
> I’m not sure what you expect us to do. You have been told the common way of fixing it and you are the first that I remember asking for this.
Mike,
I think the knub of the issue is that the OP feels that a TCP server should not acquire time\_wait connections. The side of the connection which initiates the disconnect is left with the time\_wait port. The client should initiate the disconnect and so the client should have the port in time\_wait.
This is different from http connections in that the server often responds and then disconnects.
The OP appears to be saying that the RO server is initiating the disconnect. Which it appears is correct as the following code exists in the uROIndyTCPServer
if not KeepAlive then
AThread.Connection.Disconnect
This is the issue. It should be the client calling disconnect to stop the server from accumulating time\_wait sockets.
Regards,
Will.
---
### Author:  [@impet](https://talk.remobjects.com/u/impet)
#### Post date: [August 8, 2014, 7:31am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/14 "2014-08-08T07:31:54Z")
Thank you Will. KeepAlive in conjunction with disabling Nagle algorithm is that it was necessary.
I think that the component TROIndyTCPServer must be initialized with KeepAlive = True and DisableNagle = True by default.
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [August 8, 2014, 8:14am UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/15 "2014-08-08T08:14:33Z")
I’m sorry, but changing of default values can break logic of existing projects…
---
### Author:  [@Marcos\_Cunha\_Lima](https://talk.remobjects.com/u/Marcos_Cunha_Lima)
#### Post date: [October 22, 2025, 4:06pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/16 "2025-10-22T16:06:20Z")
Sorry to bring this up again but in a heavy loaded server, is there something in the TROHTTPServer we have to change or verify in order to keep the qunatity of those time\_wait connections low?
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [October 22, 2025, 4:23pm UTC](https://talk.remobjects.com/t/large-number-of-tcp-connections-with-time-wait-status/4680/17 "2025-10-22T16:23:06Z")
Hi,
> [@Marcos\_Cunha\_Lima](#):
>
> Sorry to bring this up again but in a heavy loaded server, is there something in the TROHTTPServer we have to change or verify in order to keep the qunatity of those time\_wait connections low?
try to set [TROHTTPServer.KeepAlive](https://docs.remotingsdk.com/API/Delphi/Classes/TROHTTPServer/#KeepAlive) to **False**.
It may decrease overall performance but will close incoming connections after they were processed.
Note: connections may still have CLOSE\_WAIT and other similar statuses.