Best practice: Keep TCP/IP connection open or close it after each transfer?

Question

My Server-App uses a TIdTCPServer, several Client apps use TIdTCPClients to connect to the server (all computers are in the same LAN).

Some of the clients only need to contact the server every couple of minutes, others once every second and one will do this about 20 times a second.

If I keep the connection between a Client and the Server open, I'll save the re-connect, but have to check if the connection is lost.

If I close the connection after each transfer, it has to re-connect every time, but there's no need to check if the connection is still there.

What is the best way to do this?

At which frequency of data transfers should I keep the connection open in general?

What are other advantages / disadvantages for both scenarios?

Semiliterate

The overhead of making a new TCP connection is mainly a few roundtrips. And those are pretty fast on LAN. So I'd close the connection after a few seconds of not using it. – Difficulty

But I'd write it in the simples way(most likely instant closing) first and then check if the performance is satisfactory. – Difficulty

See my answer to this question: #4873300 – Eogene

Answer 1

I would suggest a mix of the two. When a new connection is opened, start an idle timer for it. Whenever data is exchanged, reset the timer. If the timer elapses, close the connection (or send a command to the client asking if it wants the connection to remain open). If the connection has been closed when data needs to be sent, open a new connection and repeat. This way, less-often-used connections can be closed periodically, while more-often-used connections can stay open.

Cashbox

Remy, nice work on Indy over the last few years ;-) I use the TCP components of Indy extensively, and I mean extensively, as an intrinsic part of my distributed application framework. You may want to take a look at it. – Billiton

@Remy Lebau how do you close the connection? I'm new to Indy. – Bernt

@JonathanElkins use the connection's Disconnect() method. It is available on both client (TIdTCPClient.Disconnect()) and server (AContext.Connection.Disconnect() inside a server event). – Cashbox

Answer 2

Two Cents from experiment...

My first TCP/IP client/server application was using a new connection and a new thread for each request... years ago...

Then I discovered (using ProcessExplorer) that it consummed some network resources because all closed connection are indeed not destroyed, but remain in a particular state for some time. A lot of threads were created...

I even had some connection problems with a lot of concurent requests: I didn't have enough ports on my server!

So I rewrote it, following the HTTP/1.1 scheme, and the KeepAlive feature. It's much more efficient, use a small number of threads, and ProcessExplorer likes my new server. And I never run out of port again. :)

If the client has to be shutdown, I'll use a ThreadPool to, at least, don't create a thread per client...

In short: if you can, keep your client connections alive for some minutes.

Ellswerth

Answer 3

While it may be fine to connect and disconnect for an application that is active once every few minutes, the application that is communicating several times a second will see a performance boost by leaving the connection open.

Additionally, your code will be much simple if you aren't trying to constantly open, close, or diagnose an open connection. With the proper open and close logic, and SEH around your read and writes, there's no reason to test if the socket is still connected before using, just use it. It will tell you when there is a problem.

I'd lean towards keeping a single connection open in most enterprise applications. It generally will lead to cleaner code, that is easier to maintain.

/twocents

Rummy

Answer 4

I guess it all depends on your goal and the amount of requests made on the server in a given time not to mention the available bandwidth and the hardware on the server.

You need to think for the future as well, is there any chance that in the future you will need connections to be left open? if so, then you've answered your own question.

I've implemented a chat system for a project in which ~50 people(the number is growing with each 2 months) are always connected and besides chatting it also includes data transfer, database manipulation using certain commands, etc. My implementation is keeping the connection to the server open from the application startup until the application is closed, no issues so far, however if a connection is lost for some reason it is automatically reestablished and everything continues flawlessly.

Overall I suggest you try both(keeping the connection open and closing it after it's being used) and see which fits your needs best.

Casi

Answer 5

Unless you are scaling to many hundreds of concurrent connections I would definitely keep it open - this is by far the better of the two options. Once you scale past hundreds into thousands of concurrent connections you may have to drop and reconnect. I have architected my entire framework around this (http://www.csinnovations.com/framework_overview.htm) since it allows me to "push" data to the client from the server whenever required. You need to write a fair bit of code to ensure that the connection is up and working (network drop-outs, timed pings, etc), but if you do this in your "framework" then your application code can be written in such a way that you can assume that the connection is always "up".

Billiton

Answer 6

The problem is the limit of threads per application, around 1400 threads. So max 1300 clients connected at the same time +-.

Whitewood

Although OS thread pool I would rather see implemented in Indy servers (rather than per client thread), what you claim here is not correct - see e.g. blogs.msdn.microsoft.com/oldnewthing/20050729-14/?p=34773 – Learnt

Answer 7

When closing connections as a client the port you used will be unavailable for a while. So at high volume you’re using loads of different ports. For anything repetitive i’d keep it open.

Porphyrin