-1

We have started to design a Java server/client program, there will be 1 server with potentially 100 clients, and the clients might be in another country connecting to server through VPN, so network bandwidth might not be ideal. Typical usage is, server to dispatch jobs to clients and clients return results back to server, there won't be too much data need to be transferred between server and client though, maybe around 10s KB per job, and each job needs about 5-10 minutes to run on client.

There are two options we have for the design:

1, Client start the request for socket connection when it is trying register on server, then we keep all the socket connections for communication.

2, Client start the socket connection for registration then close the connection. Server maintain the list of clients, server will start a connection when dispatching job and then close. Client will start a connection again to report results and then close.

The question is, which option will be a better design, in terms of performance and code complexity.

user2324836
  • 3
  • 1

2 Answers2

0

I've made a similar application and I finally decided to go with the second approach, it's much easier to design and maintain in terms of broken connections and the like. Also with this method you don't need to maintain 100 open sockets on the server. Every time a client connects you start a new thread to attend it, once the data is received and dispatched the thread terminates.

This is what I did:

  1. Server will listen on a port (i.e. 5051) for clients to register. We required a random encrypted password that is generated base on the date and hour they connect this, of course, is optional and depends on your security needs.

  2. Clients will listen on a port (i.e. 5052) for jobs to be processed. They only accept jobs from the same server (IP address) they have registered (again this is optional)

  3. Server will listen on a port (i.e. 5053) for clients to communicate results. It only accepts results from registered clients.

And that’s it. The server maintains a list of registered clients; the list of clients will have the client's attributes: IP address, port number they are listening (if it's not fixed), kind of jobs they are able to perform (in case you need it), etc.

ja_mesa
  • 1,971
  • 1
  • 11
  • 7
-1

You will not see a lot of difference. The reason is if the network has troubles transferring ICMP packets (or TCP SYN/ACK) the overall performance will be terrible.

If there is no such issue, then overhead of new connection setup is negligible. Even if new connection requires 15 seconds (which is really bad), the overall time loss will be:

100% * 15 sec / 10 min * 60 sec = 2,5%

But if few small packets require 15 seconds, then using even existing connection will not give you benefit.

Another aspect, is security. If you have a security protocol, that uses some kind of SSL (or another negotiation) with verification of client identity etc, it might worth to keep the connection.

However keeping long connections on Internet (not local network) is a pretty unreliable thing. So you can try to use combined approach: try to keep the connection, but if it dies (or when it dies), reconnect/recover.

Valeri Atamaniouk
  • 5,125
  • 2
  • 16
  • 18