Network Programming: to maintain sockets or not?

Question

I'm currently translating an API from C# to Java which has a network component.

The C# version seems to keep the input and output streams and the socket open for the duration of its classes being used.

Is this correct?

Bearing in mind that the application is sending commands and receiving events based on user input, is it more sensible to open a new socket stream for each "message"?

I'm maintaining a ServerSocket for listening to the server throwing events but I'm not so sure that maintaining a Socket and output stream for outbound comms is such a good idea.

I'm not really used to Socket programming. As with many developers I usually work at the application layer when I need to do networking and not at the socket layer, and it's been 5 or 6 years since I did this stuff at university.

Cheers for the help. I guess this is more asking for advice than for a definitive answer.

Cattier

I know this question is 2.5 years old, but I'd say this (as I think it's worth saying): connection pools. That's what you want to use (or implement if your app does not have access to one already built). – Sadler

Answer 1

There is a trade off between the cost of keeping the connections open and the cost of creating those connections.

Creating connections costs time and bandwidth. You have to do the 3-way TCP handshake, launch a new server thread, ...

Keeping connections open costs mainly memory and connections. Network connections are a resource limited by the OS. If you have too many clients connected, you might run out of available connections. It will cost memory as you will have one thread open for each connection, with its associated state.

The right balanced will be different based on the usage you expect. If you have a lot of clients connecting for short period of times, it's probably gonna be more efficient to close the connections. If you have few clients connecting for long period of time, you should probably keep the connections open ...

Anglin

Answer 2

If you've only got a single socket on the client and the server, you should keep it open for as long as possible.

Moro

Answer 3

If your application and the server it talks to are close, network-wise, it MAY be sensible to close the connection, but if they're distant, network-wise, you are probably better off letting the socket live for the duration.

Guillaume mentioned the 3-way handshake and that basically means that opening a socket will take a minimum of 3 times the shortest packet transit time. That can be approximated by "half the ping round-trip" and can easily reach 60-100 ms for long distances. If you end up with an additional 300 ms wait, for each command, will that impact the user experience?

Personally, I would leave the socket open, it's easier and doesn't cost time for every instance of "need to send something", the relative cost is small (one file descriptor, a bit of memory for the data structures in user-space and some extra storage in the kernel).

Aretha

Answer 4

It depends on how frequent you expect the user to type in commands. If it happens quite infrequently, you could perhaps close the sockets. If frequent, creating sockets repeatedly can be an expensive operation.

Now having said that, how expensive, in terms of machine resources, is it to have a socket connection open for infrequent data? Why exactly do you think that "maintaining a Socket and output stream for outbound comms is not such a good idea" (even though it seems the right thing to do)? On the other hand, this is different for file streams if you expect that other processes might want to use the same file. Closing the file stream quickly in this case would be the way to go.

How likely is it that you are going to run out of the many TCP connections you can create, which other processes making outbound connections might want to use? Or do you expect to have a large number of clients connecting to your server at a time?

Overblouse

You'll run out of connections long before you run out of port numbers. – Epistemology

one server one client So not going to run out of connections. port is specified as the API is a wrapper around a TCP based protocol. – Cattier

My bad, I guess I've forgotten my network programming as well – Overblouse

Answer 5

You can also look at DatagramSocket and DatagramPacket. The advantage is lower over-head, the disadvantage is the over-head that regular Socket provides.

Kerakerala

I don't have the option of changing protocol, I'm connecting to a vendor application. – Cattier

And require reliability to be implemented by the dev? No sir! – Teakwood

Answer 6

I suggest you look at using an existing messaging solution like ActiveMQ or Netty. This will handle lot of the issues you may find with messaging.

Vick

Answer 7

I am coming a bit late, but I didn't see anyone suggest that.

I think it will be wise to consider pooling your connections(doesn't matter if Socket or TCP), being able to maintain couple connections open and quickly reuse them in your code base would be optimal in case of performance.

In fact, Roslyn compiler extensively use this technique in a lot of places. https://github.com/dotnet/roslyn/search?l=C%23&q=pooled&type=&utf8=%E2%9C%93

Milliken