I stumbled across an interesting discussion from Feb-2008 about using QTcpSocket and QLocalSocket, which also suggested the design might be revisited post Qt5:
http://blog.qt.digia.com/2008/02/22/qlocalserver-qlocalsocket/ REVIEW: - QTcpSocket (derived from QAbstractSocket) is really a network-socket with a network-address - QLocalSocket (NOT derived from QAbstractSocket) is not really a network-socket (and does not have a network-address), but is implemented as a named-pipe on Windows, so you can communicate with all the Windows computers on the network. QUESTION: If you logically need a "network-socket" (LAN or WAN, but sometimes accidentally on the same-computer), is there a *performance* issue (or any reasonable design preference) where QLocalSocket would be "preferable" to a QTcpSocket? (...in the case where you detected you were on the "same-computer" or a "Windows-network" so you could use QLocalSocket, and you used QTcpSocket for other networks?) This email thread suggests one could write an abstraction to handle this, and I'm thinking about doing it, if it's not stupid: http://lists.qt.nokia.com/pipermail/qt-interest/2011-June/034175.html I'm thinking about writing this abstraction. My greatest design needs: - performance (many clients, single server, small packets) - can "keep" socket instances (since socket recycling on Win7 seems really expensive, and the OS doesn't free them up fast, so we've run out if you frequently setup/tear-down.) Does the "MyLocalSocketOrTcpSocket" class seem stupid, or should I just use "QTcpSocket" all the time? Is this something that will be re-visited post Qt5? Thanks! --charley _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development