The problem is that I never see the newConnection() signal emitted on the server, and so the waitForReadyRead( timeout ) always times out on the client. Before posting code, I wanted to find out if what I want to do is logical/possible or if there are other things to look at.

It is an old mfc application that connects to a remote server to receive some data before opening the application. I want to run the old service on the remote server alongside QTcpServer and the old client alongside QTcpSocket. I copied the Fortune Server/Fortune client example almost verbatim. The server "listens" successfully on its assigned port, the client connects successfully, returning the correct peer port and host, but readyRead() never gets called. When I attach to the running service on the localhost to debug the connection, I never hit a break point in any of the slots associated with accepting a client connection - even though the client's log file gets written to say it connected successfully. The connect function returns True, and signal/slots are working on other items in the same classes.

* The mfc/QApp main event loop will not be instantiated until after this process completes. It does get properly instantiated, and the event loop created. I *think* all I need is QObject for QTcpServer and QTcpSocket ... but maybe not?
* This is a service... which I don't *think* should make a difference, but maybe there is other scheduling going on that blocks the signals from ever running?
* It's running side/by/side with the old code, which makes use of sockets and overrides WMCOMMAND and some other low level stuff. I needed to make provision for passing Ctl-C, etc. to Qt in the GUI. So maybe there's something that can block or disconnect or whatever the signal/slot communication in Qt? And if so, what should I look for?

Thanks in advance for any help you can provide. If it all looks as if it should behave, I will post code and hopefully someone will have an 'ah-ha' moment.