2

I have a TCP server that gets data from one (and only one) client. When this client sends the data, it makes a connection to my server, sends one (logical) message and then does not send any more on that connection.

It will then make another connection to send the next message.

I have a co-worker who says that this is very bad from a resources point of view. He says that making a connection is resource intensive and takes a while. He says that I need to get this client to make a connection and then just keep using it for as long as we need to communicate (or until there is an error).

One benefit of using separate connections is that I can probably multi-thread them and get more throughput on the line. I mentioned this to my co-worker and he told me that having lots of sockets open will kill the server.

Is this true? Or can I just allow it to make a separate connection for each logical message that needs to be sent. (Note that by logical message I mean an xml file that is of variable length.)

Vaccano
  • 78,325
  • 149
  • 468
  • 850
  • Do you experience any issues with your current implementation? Don't create solutions more difficult than it is necessary. – zerkms Oct 21 '11 at 01:38

5 Answers5

1

The initiation sequence of a TCP connection is a very simple 3 way handshake which has very low overhead. No need to maintain a constant connection.

Also having many TCP connections won't kill your server so fast. modern hardware and operating systems can handle hundreds of concurrect TCP connections, unless you are afraid of Denial of service attacks which are out of the scope of this question obviously.

Variant
  • 17,279
  • 4
  • 40
  • 65
  • Does it change anything to know that I could have a peak of 500 logical messages per minute? Or does that not really matter? (I hope it does not.) – Vaccano Oct 21 '11 at 01:43
  • If 500 msgs per minute is only a peak and the average is something like 20 there is no real need to optimize. If 500 is a steady rate then keeping an open connection is probably logical. – Variant Oct 21 '11 at 01:47
  • Actually since all messages are from the same client and presumably are not sent in parallel, A not so fast round-trip time of 100ms will probably not allow a throughput of 500 msgs per sec. – Variant Oct 21 '11 at 02:04
  • That was 500 messages per Minute (not 500 per second). – Vaccano Oct 21 '11 at 02:06
1

If your server has only a single client, I can't imagine in practice there'd be any issues with opening a new TCP socket per message. Sounds like your co-worker likes to prematurely optimize.

However, if you're flooding the server with messages, it may become an issue. But still, with a single client, I wouldn't worry about it.

Just make sure you close the socket when you're done with it. No need to be rude to the server :)

rossipedia
  • 56,800
  • 10
  • 90
  • 93
1

In addition to what everyone said, consider UDP. It's perfect for small messages where no response is expected, and on a local network (as opposed to Internet) it's practically reliable.

Seva Alekseyev
  • 59,826
  • 25
  • 160
  • 281
1

From the servers perspective, it not a problem to have a very large number of connections open.

How many socket connections can a web server handle?

From the clients perspective, if measuring shows you need to avoid the time initiate connections and you want parallelism, you could create a connection pool. Multiple threads can re-use each of the connections and release them back into the pool when they're done. That does raise the complexity level so once again, make sure you need it. You could also have logic to shrink and grow the pool based on activity - it would be ashame to hold connections open to the server over night while the app is just sitting their idle.

Community
  • 1
  • 1
bryanmac
  • 38,941
  • 11
  • 91
  • 99
1

It depends entirely on the number of connections that you are intending to open and close and the rate at which you intend to open them.

Unless you go out of your way to avoid the TIME_WAIT state by aborting the connections rather than closing them gracefully you will accumulate sockets in TIME_WAIT state on either the client or the server. With a single client it doesn't actually matter where these accumulate as the issue will be the same. If the rate at which you use your connections is faster than the rate at which your TIME_WAIT connections close then you will eventually get to a point where you cannot open any new connections because you have no ephemeral ports left as all of them are in use with sockets that are in TIME_WAIT.

I write about this in much more detail here: http://www.serverframework.com/asynchronousevents/2011/01/time-wait-and-its-design-implications-for-protocols-and-scalable-servers.html

In general I would suggest that you keep a single connection and simply reopen it if it gets reset. The logic may appear to be a little more complex but the system will scale far better; you may only have one client now and the rate of connections may be such that you do not expect to suffer from TIME_WAIT issues but these facts may not stay the same for the life of your system...

Len Holgate
  • 21,282
  • 4
  • 45
  • 92