What is the best way to implement a cross-platform

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

Douglas Schmidt's ACE (Adaptive Communications Environment) is a mature, highly portable open-source framework for building high-performance multithreaded servers. It's mainly aimed at telecommunication applications, but has been used for a variety of projects. It also comes with an object request broker called TAO (if you're into CORBA)

One claim to fame of the framework is that it supports many threading models (thread pool, thread per request, asynchronous + threads etc.), so you can use its thread management in a way that's optimal for your application. This is actually the most interesting feature of the system - the server framework functionality comes out of the box. Most of the other libraries I've seen suggested here would still require you to implement much of this functionality yourself.

There is quite a bit of electronic documentation and also several books written about it. It's not the most warm and fluffy of systems and is really built for speed rather than comfort - but we are using C++. You will probably find that it's much less effort to get your head around ACE than try to rebuild the functionality and debug all the synchronisation.

Oh, and by the way, it's free as in speech - and as in beer. If you want to a commercial route there is also an ecosystem of consultants that will provide support and mentoring services for it. A tutorial with some code snippets can be found here.

Answer 3

I use libevent to multiplex network I/O. You should consider it as an alternative to Boost.Asio.

The libevent API provides a mechanism to execute a callback function when a specific event occurs on a file descriptor or after a timeout has been reached. Currently, libevent supports /dev/poll, kqueue, event ports, select, poll and epoll.

Answer 4

I would use QT. It has a cross-platform threading support. Good documentation:

QT Threading Documentation

Their signal/slot messaging mechanism works seamlessly between threads too.

Answer 5

Not really an answer to your question, but since it sounds like you are actually more familiar with Java than C/C++, why not continue with your reference implementation, and connect to the SDK using Java Native Interface. (I never really used it, but I figured it would be useful exactly for these kinds of situations.)

Alternatively, you could easily write a simple C program that employs the SDK, and then sends the data to your Java program, using socket-based streams for example. This way, you could again handle the more difficult stuff in Java.