Do QLocalSockets need a QLocalServer to work?
-
Hi,
Sorry if this is a simple question...
I want to implement local sockets for IPC on embedded Linux. I could use the POSIX API and local domain sockets, but thought it would be easier to use the Qt API.
From the examples I have seen, it appears you need to use a QLocalServer, a QLocalSocket on the server side, and a QLocalSocket on the client side.
Is is not possible to have a single socket connect to another socket? Is the server required? It seems unnecessary to have a server if I am only establishing a single connection? I do see that QLocalSocket only has a call to connectToServer(name)...
Hope that makes sense. If anyone can clear this up or point me in the right direction would be grateful.
Dan
-
@DannySW
QLocalServer
is what has the calls to listen for and accept a client connection. If you only had 2QLocalSocket
s, how would you connect one to the other? I assume " the POSIX API and local domain sockets" have a concept of one side is the server and the other is the client? -
@DannySW
I'm not sure that they aren't sill "peer to peer" though. In Unix both sides just use asocket()
, they simply call different functions on it for server/client at the connection/disconnection phase. I haven't looked at the Qt sources, but I think they have just separated them into two classes so that you know which side you are using, and you can only call client vs server functionality in the respective one, but otherwise similar.The QLocalSocket docs do say:
On Windows this is a named pipe and on Unix this is a local domain socket.
UPDATE
OK, I looked at the docs of what each do. The key is QLocalSocket *QLocalServer::nextPendingConnection()Returns the next pending connection as a connected
QLocalSocket
object.So that's the connected
socket
(afteraccept()
) at the server side, to read/write on like at the client side, aQLocalSocket
on both sides.QServerSocket
encapsulates just the connections part of what you do with the listeningsocket
in Unix.