Is this the correct way to think about the client/server socket relationship?

Question

I'm designing a distributed application, very basic for now. The idea is that once the application is active on all machines (about 5 vms), you can initiate a grep on all log files from all machines from any one machine.

Generally, the steps would be:

• Launch the application on all machines
• All applications pause in a wait condition of Press [Enter] to continue...
• Once [Enter] is pressed, that particular machine is the issuer of commands, so to speak
• You type your desired pattern, and it issues the commands to all machines, pulling down the results

At first, my plan was to do connection setup after the user pressed [Enter], setting up a client connection for the host issuing the commands, and server connections on the rest; but this seems not very scalable. My idea now is to just initiate all connections from the start, both a client and server, and just always be polling the server socket for incoming queries.

Is this standard practice, or should I be looking at a different way to monitor / setup connections? Are there any basic design principles or best practices for building distributed connections?

Answer 1

Having a number of client connections to numerous remote nodes is not that intensive so that should not be a problem in that respect. For the data rate that you can expect from a terminal, you might consider non-blocking I/O with callbacks and a single server with a thread per client or a thread pool to process the response messages. This should scale until you are processing bound with your connections.

You could then set up your connections either in advance or as needed. Working on an as needed basis will avoid a startup hit if there are no tight time requirements for getting the list of files at about the same time. If you want more details, provide a diagram and we can discuss.