Consider a software which runs on a dedicated system (basically a Linux box), and controls some machinery. The system has all the required hardware interfaces for the task. The software also has a GUI for controlling said machinery.

However, this system should later be able to be used from external devices, so other software, using the same or similar GUI will be running on various PCs, smartphones, etc. The central SW will contain a TCP server through which the external devices will connect. The central device with its software is to be developed first, and the controlability from external devices will be a later add-on.

My proposal for the "central" software would be to split it into two separate programs. One would be a server without any GUI at all, which will handle all the controlling and hardware interfacing stuff, and a separate software would fulfill solely the roles of the GUI.

Of course, a good MVC separation is possible even within a single program, but the main advantage I see for splitting the program is that the GUI part will be much more easily portable to other systems. Actually, in case of a PC as an external device, the same software can be re-used 100%. For other systems, I guess it would be much easier to port a program 1 to 1, than to port only the GUI part of a more complex program.

The main disadvantage of this solution is that the initial system will be a more complicated, as the GUI needs to communicate via TCP with the controlling part, instead of directly inside the same program.

Are there other major advantages and disadvantages of splitting the application in two separate programs communicating over TCP?

The scope of the project is up to 2 years for a small, 2-3 person team.

  • What kind of system? What operating system and hardware (and machinery: a sewing machine is not the same as a nuclear reactor)? What approximate size of code (e.g. a month's work for a single hobbyst, so a few thousand lines, or a project for 3 years and a team of several dozens developers?)? What programming language? Please edit your question to give more specific details! Jan 26, 2016 at 8:38
  • What kind of machinery, please edit your question again to explain that! Also explain in a few sentences what should your software do? Jan 26, 2016 at 8:48
  • The scope of the project is around 2 years for a small, 2-3 person team. I didn't want to make the question too localized.
    – vsz
    Jan 26, 2016 at 8:50
  • You really should. A nuclear power plant is not the same as sewing machine (and I imagine your machinery is neither a nuclear device nor a sewing machine). And you should edit your question again not comment it Jan 26, 2016 at 8:51
  • 1
    I finally downvoted your question because you don't tell anything about the machinery and the application and its end-user Jan 26, 2016 at 9:27

3 Answers 3


Yes, this separation of layers is always a good thing, even if its not going to be written for a distributed system. Many systems work by making UI or DB components as isolated as possible to allow for easier maintenance or replacement in the future.

Other system write the main program as a command line app and then write a GUI to drive that. That allows it to be scripted and used in a UI environment too. Its not excessively complicated to do this, you just write your program and then write a UI program later.

For your needs, I'd recommend an embedded HTTP webserver. There are many and they're very lightweight. You lose nothing by using one instead of a custom TCP server (as you still need to implement security etc) but gain all the standard features of the protocol. You also gain the ability to write your client in the server as a HTML website and control it via a web browser.

  • Very similar recommendation to mine: make your software some specialized web server. Jan 26, 2016 at 8:36
  • @BasileStarynkevitch I stuck an embedded webserver (civetweb) into an existing app, it was so easy to use and get working I now recommend that approach to everyone :-)
    – gbjbaanb
    Jan 26, 2016 at 8:41

Your question might be too broad and is quite abstract (not enough implementation details are given: which operating system? which hardware: an Arduino like embedded processor is not the same as an ARM motherboard running some real-time variant of Linux; what machinery ? : a sewing machine is not the same as a nuclear power plant). Also, what kind of users? Are they all internal to a corporation or can they be "general public"?

However, did you consider making your software some specialized web server, using some HTTP server library like libonion or perhaps Wt ? (Of course HTTP is above TCP); then you would still split your software in two parts: one providing HTTP service, the other being some code (e.g. Javascript, AJAX, ...) running in browsers.

Then your GUI part would be mostly replaced by browsers (on variety of devices: desktops, smartphones, etc...) speaking HTTP (or HTTPS).

Of course, if you design your application as a specialized web server, you should take very early into account all the implications (notably security, DDOS attacks, ...) and you should be aware of web technologies. Of course, things could be different if all users are inside some small corporate intranet (then, you probably care a bit less about DDOS)

But on the client side, most end-user devices (desktops or laptops running Windows, Linux, MacOSX, tablets, smartphones) -those with a display at least- have already sophisticated HTML5 browsers, on which you could leverage.

You might consider other approaches, e.g. remote procedure calls using JSONRPC, using FastCGI to interface to some external existing web server, etc....

If you split your software in several parts, you need to define how they communicate and synchronize, and that is probably operating system and implementation specific (but you'l need some inter-process communication probably provided by some operating system, but you might have some unikernel approach). Without telling more about your software & system & machinery (i.e. physical purpose), you won't get really meaningful help.

  • The TCP (or maybe even HTTP) will be there, no matter what. The question is whether it makes sense to split the main software into two parts which also communicate over TCP or not to split it.
    – vsz
    Jan 26, 2016 at 8:28
  • Your question is too broad to be answered. What operating system, what kind and approximate size of software. If you have two parts, they would need to communicate, so some IPC is involved. Jan 26, 2016 at 8:29

A few pitfalls you need to be aware of:

  1. Authentication. Unless you want anyone in the world to operate your machine, you need to make sure only authorized people connect to your hardware controller. A good way to do this might be to use TLS with client- and server certificate. As a bonus this also gives you encryption to protect from eavesdroppers and man-in-the-middle attackers.
  2. The client can not be trusted. You can not assume that the user (authorized or unauthorized) will use your unmodified client software. So make sure your protocol implementation on the server does not allow anything the user interface is not supposed to allow. All client-inputs need to be sanity-checked.
  3. TCP/IP is not very real-time capable. Packets can be suddenly delayed for a whole bunch of reasons. UDP/IP has slightly better real-time capabilities, but has a whole bunch of even nastier surprises, like packets arriving in the wrong order or not at all. When it is important for your use-case that the machine executes commands with exact timing, you can not assume that the commands arrive at the server with the same time-differences between them as they left the client. For example: If you want the machine to run for exactly 5.637 seconds, then sending the on-message and 5.637 seconds later sending the off-message might not work because both messages will need a different time to arrive at the server. You would need to send a "Switch on, wait 5.637 seconds, switch off, now do it" command in one message.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.