Our company has started to design a system where many (typically 4 or 6) force-sensitive platforms, containing load-cells, would stream data to the PC via TCP.

Each platform and the PC shall be connected by network cable to a network switch acting as a hub.

Each platform will be running a microcontrolled device, with a firmware to be developed by our supplier.

So my questions are:

What is the recommended client/server relationship between the software application and each one of the peripherals?

Should the application establish one connection for each platform?

At first I would think the platform should be the server (listener), so that it stays continuously in "standby" (listening) when turned on, waiting for the PC to ask to connect to it (I wonder how to specify the correct IP, though...).

But since the PC is only one and the platforms are many, maybe the PC should be the "server", with each peripheral being one of many "clients"? That got me confused...

  • This seems odd, but I had an accepted answer and it just... disappeared?? Aug 7, 2015 at 17:04

2 Answers 2


Broadcast: The simplest approach


Each platform and the PC shall be connected by network cable to a network switch acting as a hub.

It should be safe to assume that the devices are all on the same network. Have each of device toss its data into the broadcast for the network and don't worry about it. You don't need to configure where the server is, or even if its up at the time (or down, and need to reconnect). The devices just toss their data and continue on with collecting.

The server is also similarly simple. It listens for packets that are broadcast to the network, when it gets one, it processes it and continues on with listening for packets.

This is really the simplest thing that you can do, and it will work if everything is on the same network (can get noisy for other things on the network if there are many sensors providing data).

Message queues

If you are willing to invest a bit of time into the devices and what data they are sending out, the use of a message queue can make the architecture easier. In particular, ZeroMQ which allows for a more formalized structure.

Again, the devices write to a feed and the server reads from it. Thats the basics of it. Its a rather flexible approach and there are many architectures that can be applied here depending on the specifics of the need.

If you want to go with something that has guaranteed delivery, look to one that has a more robust message broker. This then allows for structures that you can reason a bit more about including doing things like having multiple workers/consumers off of the message queue to process the data if the load starts having an issue (but you want to make sure each message only goes to one worker).


From consumer point of view, I want a) easy setup and optionally b) things to be connected to the internet.

For point a) the devices should be able to auto discover the server, either on local network (e.g. Zeroconf) or on the internet.

As for b) as you're already planning to use TCP, going for HTTP probably won't add much effort. It can probably help in designing since you won't need to think about protocol to use, how to add security, etc. Especially helpful because the server part would be very easy.

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.