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!).

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.

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…

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

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.

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.

@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).

@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.

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.

@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.

@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.

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.