What is the best way to implement a cross-platform, multi-threaded server in C/C++?

Question

Part of the development team I work with has been given the challenge of writing a server for integration with our product. We have some low-level sensor devices that provide a C SDK, and we want to share them over a network for use by people collecting data. Sounds simple, right? Someone would connect a sensor device to their machine in one part of the building and run our server, thus sharing the device(s) with the rest of the network. Then a client would connect to that server via our application and collect sensor readings from the device.

I created a simple, language-agnostic network protocol, and a reference implementation in Java. The problem is creating an implementation that will work with our devices that only provide an SDK written in C. We were thinking of doing the following:

1. Create polling threads that collect and store the most recent readings from each connected device.
2. Use a multi-threaded server to spin off each incoming connection to a worker thread.
3. When a worker thread receives a request for a sensor reading, the most recent value collected by the polling thread is sent back to the client.

That's a lot of threading, especially in C. So, to review, the general requirements are:

• Runs on Windows XP/Vista, Linux, and OS X machines
• Written in C or C++, to interact with the C SDK we have
• Accepts a variable number of simultaneous connections (worker threads)
• Must use threads, not forking (don't want to deal with another layer of IPC)

Can anyone suggest a library and preferably some example code to get use started?

Answer 1

I've used Boost.Thread & Boost.Asio to build a multi-threaded server on Windows & Linux systems. The tutorials made it easy to get started.

Answer 2

The best way to write such a server is not to write one, and to rearchitect your system so it is not necessary, and/or to reuse components that already exist. Because:

Someone would connect a sensor device to their machine in one part of the building and run our server, thus sharing the device(s) with the rest of the network.

This also has the potential to share the entire machine with rest of the network, if your code has a vulnerability (which it probably will, as you're writing it in C++ from scratch and inventing a new protocol).

So, do it the other way around. Install a simple client on the machine that has the sensor hardware, then run it either all the time, or periodically, and have it push (post) results to a central server. The central server could even be a standard web server. Or it could be a database. (Notice that both of these have been written already - no need to reinvent the wheel ;-)

Your application then works the same way you have in mind now, however it collects data from the database rather than the sensors. The part running on the machine with the sensor, however, has shrunk from a multi-threaded custom server nightmare, to a nice little single threaded command line client that only makes outgoing connections, and which can be run from cron (or equivalent on windows).

Even if you need real time data collection (and from your description it sounds like you do not) it still may be better for the sensor collector be a client and not a server. Let it open a long lived connection to a central collector (or a group of them) and await instructions to provide its data.

edit: ceretullis and pukku's answers suggest a nice variation on this using multicast - see this answer and the comments