QLocalServer & QLocalSocket

Published Friday February 22nd, 2008
13 Comments on QLocalServer & QLocalSocket
Posted in KDE, Qt

Finishing off IPC features in 4.4, two small classes that have been added are QLocalServer and QLocalSocket. On Windows this is a named pipe and on Unix this is a local domain socket. The API is almost identical to QAbstractSocket so switching from a local socket to a tcp socket and vice versa is very easy if you want to. For those KDE applications that are currently using KLocalServer/KLocalSocket with minor function name changes most of them should be able to switch and then they will get another feature working on Windows. If you have a Qt 4.4 snapshot in the examples/ipc/ directory you will find two new examples that are ports of the fortune server and client.
qlocalserversocket.png

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in KDE, Qt

13 comments

Giovanni Bajo says:

Are you using a polling thread under Windows, just like qprocess_win.cpp does? If so, that’s a serious performance problem (just like QProcess has), because QProcess’ thread arbitrarily sleeps for 100ms between polls, and this kills speed (transferring data through a QProcess pipe is really slow today!).

Benjamin Meyer says:

Yes, under windows it shares some code with QProcess, so that same performance bottleneck might apply.

Darin Broady says:

If QLocalSocket is almost identical to QAbstractSocket, why doesn’t it just inherit from QAbstractSocket? That way you can deal with all “socket” type code the same, instead of having to branch based on QLocalSocket vs QAbstractSocket subclasses for function calls.

Andreas says:

Darin Broady: By inheriting that means a local socket “is a” network socket, which doesn’t make much sense. For example, a local socket doesn’t have a local and peer address and port, and you cannot connect to a host name and a port with a local socket. It could have made sense if both QAbstractSocket and QLocalSocket shared a common direct ancestor, but one inheriting the other isn’t the right design… πŸ™‚

Marco says:

@Andreas: Then this is a design failure of QAbstractSocket. Why there is no QAbstractNetworkSocket ?

Darin Broady says:

Andreas: If QAbstractSocket really is meant to only deal with network sockets, then the documentation should be more clear on this. In Qt-4.4 docs for QAbstractSocket, the first line is “The QAbstractSocket class provides the base functionality common to all socket types.” Note the all socket types. By this statement, I would assume that all socket types means all socket types, not just network sockets.

David Johnson says:

Could there be a proxy socket class, that uses QLocalSocket or QTcpSocket, depending on whether the server is local or not? Maybe as an example program.

Erik says:

@Marco: I agree here. It would be great to have an abstract socket class which abstracts from local or network sockets and just provides similar functionality (connect/disconnect/state information/timeout handling).

Erik says:

@David Johnson: a QLocalSocket is not a “localhost QTcpSocket”, it is a named socket/pipe. Therefore your application has to provide connection information (host:post for QTcpSocket and server-name for QLocalSocket) – the framework cannot guess it.

Helmut says:

Named pipes on Windows are not limited to the local computer.They can be accessed from other computers running Windows in the network. They are a real substitute for TCP sockets as long as you only communicate with other Windows computers. For me it doesn’t make sense to use them for a QLocalSocket class. Neither they are sockets nor they limited to the local host.
I agree it would be nice to have a more common “QDataChannel” base class, which could be implemented as QTcpSocket, QNamePipe, QSerialPort or whatever else.

Thiago Macieira says:

@David: Erik is right: the two kinds of sockets are very different from one another. Having one class that does both is not a very common case.

KDE used to have that for a long while in the form of KStreamSocket. But there was almost never code that needed to use both cases, depending on some configuration or another.

That was KDE 3. Interestingly, in KDE 4 one case appeared, which was cross-platform code: KLocalSocket does not support Windows, so some people had to use QTcpSocket. Now with QLocalSocket, there will be no need for platform-specific code.

Thiago Macieira says:

@Marco, @Erik: a common base class is an interesting idea. But it’s a moot point since we have to maintain binary compatibility until Qt 5. So QAbstractSocket cannot change.

We’ll revisit the issue when Qt 5 development starts, but that’s a long way in the future.

The Baldguy says:

while true:
print “thank you!”

Seriously, the lack of ability to use domain sockets has been the single largest glaring hole to me in Qt’s networking (guess where most of programs are deployed πŸ˜‰ ).

I do agree with the idea that a common base class should be (highly) considered in QT5.

Commenting closed.

Get started today with Qt Download now