SLARTSock: SLART's Next Generation Communication Framework?

Update:

This page is now obsolete. SLART has been equipped with a new inter-process communcation, which has been named "Satellite". It's based upon TCP communication with a server that's started transparently if it's not available.

About:

Right now SLART uses UDP for sending messages from one application to another. While being very portable, the downside on this is, that every application needs an own port to listen on. The protocol run was orginally intended for bus architecture. SLARTSock is my second approach on setting up a robust communication framework. The main goals are:

Multiplatform using Qt.
No dedicated server process required.
Robust, the crash of an application should have no effect on the bus.
As light-weight as possible.
Intended for sending small messages, not a huge amount of data.
Messages are sent as QByteArrays. (This has been changed from QStrings.)

Using the QtDBus module is not an option. While the design is very nice, there's no way to get it running on Windows. Even on the Mac and most other Unicies, you'll need to install a dbus port. In the long run, SLART is also intended to run on every platform Qt supports.

Design:

When an application is run it tries to connect to a UNIX domain socket. If that socket is not available it instantiates a server on it's own and then connects to this server.

A message from a client is sent to the server, which just forwards the message to all other clients.

If the server quits or dies, the clients are aware that and try to connect to a new server which is created by one of them. And that's classic case where race conditions arise: all clients try to fire up the servers themselves simultaneously.

To circumvent this a locking mechanism is needed. I chose a dummy shared memory segment (via QSharedMemory) to accomplish this. This is no an easy task, since the Qt implementation differs a bit from system to system.

This design is not fixed in any way! If you've got any idea on how to improve the locking or replace the whole communication framework by something better, I'm open to suggestions. Feel free to drop me an email. The address is in the readme that comes with the demo code.

Test/Demo Application:

This is obsolete now, see conclusion below. If you're really interessted drop me an email, and I'll point you out to the sourcecode in question or put a new test/demo application here.

The demo client is the part I need help in. If you've got a platform that's not already been tested, but runs Qt 4.x please download the code, compile and test it. The application consists of three parts: debug output, an output list in the middle, and at the bottom there's an input line. What you enter on the input line should be displayed on the output list on all other clients. The debug output displays debug message from both, the server (starting with "s:") and the client (starting with "c:"). Here's the test scenario, that you should run:

Compile the code by just running "make". "qmake" will be run in the process automatically. All generated code will be written to a subdirectory named after the architecture.
(If you're using an embedded platform start another application with the "-qws"-option first.)
Fire up instances (about four to ten) of the application, the first one started should also run the server, all others should connect to this server.
Type in something like "Hello World" in one of the clients. After pressing enter it should appear in the output list on all other clients.
Kill that server with "kill -9 <pid>". One of the other clients should run the server now. Take a look if all other clients connect to this server.
Close this server normally. Again another client will take up the server role, and all other clients should connect to this server.
Continue this procedure until there's no client left.

Things I've already seen going wrong:

After killing the server, no client takes up the server role.
More than one application takes over the server role and the communication is split into two or more busses.

If you've run the test on an architecture not mentioned before or run into problems that are not mentioned, please send me an email containing the platform you're using and how the test worked out.

Thanks in advance for your help!

Conclusion:

The result of this research project has now been integrated into SLART. There has been a slight design change: the unix domain socket has been replaced with a TCP socket. With this all race conditions problems have vanished, the locking - originally implemented using QSharedMemory - is now done by the TCP server itself. And it runs like a charm.

News:

2010-02-14

There has some excessive testing has been done and the result is now integrated into SLART under the name of Satellite. A conclusion has been added to this page.

2009-10-20

Release 0.2.1

extended one Mac OS X workaround for all *BSDs

2009-10-16

Release 0.2

change to QByteArray instead of QString for messages
separated debug output from normal messages

2009-10-06

Release 0.1.1 fixing two typos.

2009-10-04

Initial release 0.1

This software is free software and distributed under the license terms of the GPL.

Enjoy,
SvOlli