We got multiple devices that communicate over different protocols (rs232, tcp, http, etc.) and we want be able to send requests from multiple interfaces (as well get responses from each device to multiple interfaces).

We are wondering how to properly manage the communication between interface clients and device clients. One solution is to make a server manager which will handle one connection to multiple interface clients and one connection to multiple modules. But, I'm not a fan of it due to multithreaded code that should be manage. Diagram: one server

So mine proposal is to make a manager which have got multiple servers, so each module and specified interface will be clients that communicate with concrete module server. Diagram:

multiple servers

Which one is better and why? In mine opinion the version with multiple servers will separate multithreaded logic for each module. On the other hand we will have multiple connections, but is it a thing to worry about it?

Thanks in advance.

  • It depends on the number of connections as well. Long life connections can be a problem. Feb 27, 2017 at 19:15

4 Answers 4


I don't know how big a project this is, but it seems to me this shouldn't be a matter of taste. There are design factors to consider. Your team should brainstorm on design factors and then rate them for risk, cost, and probability, then use some sort of objective scoring methodology to rank your options, both of which are perfectly viable for different situations.

Some questions for your group to consider:

How much risk is there that different inbound protocols will conflict with one another? You might want more process isolation if, say, your RS232 driver is leaky. Or maybe it is known to crash the box occasionally, in which case you'd want it to run on a separate machine entirely. Or maybe they're all completely stable, but you want their threads treated differently, e.g. different sized pools, shorter timeouts, or independent config.

Is there state? What is the impact of resetting any of the services? Do you have redundancy?

How fast are you going to grow? If you plan to grow fast, maybe you should try as hard as you can to get all the services running on a single box, so you can scale out more easily.

How complicated is the business logic? If your services are just sort of pass-through to the back end services, option 2 doesn't look so bad. If they are very complicated then option 1 is better.

What will be the release cycle? When you need to deploy bug fixes, is there any advantage to having separate services? Do you plan to synchronize feature releases, or will some channels get releases more often? Will the code be managed by different teams?

Also, be sure to engage your network engineering team, as it sounds like this solution is going to require a lot of plumbing and there may be connectivity concerns as well.

  • Ok, thanks! ad 1) You are right. Serial port class sometimes can hang out. ad 2) We got a state for each device/service. ad 3) Yes and no. If we make a standard for each device/service module then it will be faster to add it. ad4) Yes, the most time it is just a method that should be invoked ad5)Yes, it could be. ad last) yep, we have to do more tests
    – luk4ward
    Feb 28, 2017 at 14:05

Always multiple servers, as a server may get busy in serial communication unless it times out and during that period will not process other communications.

Use multiple communicating entities and create a telegram processing queue with buffers.


Solution one in batter, but you could split it in 2 or 3 micro-servers, that comunicate using some messaging protocol (there are a few, like zeromq).

A combination between 1 and 2 is also nice, have a server that hanles all clients and redistribute communication to each device.

And in general use real server apps, don't implement your own in comunication with desktop clients.

Proposed arhitecture

Issues with sol 2:

  • complexity on the client
  • dificult to change client interface
  • bad separation of concerns
  • Ok, thanks. What You mean by real server apps? In solution 2 the complexity is simpler than in solution1 because we got separate communication channel
    – luk4ward
    Feb 25, 2017 at 7:22
  • . If we got one connection to each user interface then we have to make an interpreter for each device or something like this. In solution2 we got all methods for specified device by one global device interface.
    – luk4ward
    Feb 25, 2017 at 7:40
  • real server apps - I was thinking about normal web servers, using rest service, for exemple: apache + php, python... + a rest web framework
    – Dragos Pop
    Feb 25, 2017 at 12:09
  • I put a diagram with my proposal. You can see that it is basically your solution plus an adaptor and a kind of router so the client interface will be in one place and the clients will be simple.
    – Dragos Pop
    Feb 25, 2017 at 12:26
  • Ok, thanks. There is a time limitation on rest server for the requests, right? Are You sure that time between request from interface and invoked action on the device is less than 200ms? Because this is the real time that user pushes the button.
    – luk4ward
    Feb 26, 2017 at 17:50

First, the benefit of the first architecture is that clients a single interface they are connecting to and using. The second architecture benefit is that it scales well and different connections are used to different resources - but now you lost the first architecture advantage.

I suggest a mixture of both: Have a single API in the server, and by use of a parameter decide how to handle different requests. This was not needed in the second architecture since different clients had different contact point within the server, so this adds a bit of complexity and changes.

Allow me to reiterate a major point: The server itself might be splited into more than one service, but it has a single API

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.