@jsulm Thanks a lot

@Kent-Dorfman
In which eventuality you'd like to send a out-of-band message, https://en.wikipedia.org/wiki/Out-of-band_data, or e.g. https://docs.microsoft.com/en-us/windows/desktop/winsock/protocol-independent-out-of-band-data-2. Which I have a feeling Qt doesn't support anyway.

@jsulm
thanks for you reply! it is work! thanks again!

@htmlboss
Hi,

let's call them "node" and "controller"

Let's not do that. Let's call them a server and a client - it's much better and easier to follow the accepted terminology. A server will serve the requests presented by the clients (see the analogy with a busy restaurant?).

There can only be one "controller", but the number of "nodes" may vary (eg. different clients).

So you have one server and a few clients. So far so good.

I want to have the "controller" initiate the connection to each client such that arbitrary data is sent back and forth as it is ready (readyRead() signal? ).

How data flows between the client and the server is completely independent of who initiated the connection. You can still have the server sending data to the clients (what http servers mostly do), and still the client initiates the connection (i.e. your browser).

I have implemented the Fortune Client/Server example with the "controller" as the Client (since it would initially ask for a connection), and the Fortune Server as a test (eventually it would be a "node" sending data). This is where I'm stuck. Ignoring less-than-critical performance issues, how would I modify the Fortune example (or perhaps roll my own) to allow the Server to accept data from the "controller" without the use of any buttons/etc, but to get it as it is "ready"? Ideally, this needs to scale up to a max of 15 "nodes".

Just write from the appropriate side (application). The server should stay the server, and the client should stay a client, don't switch their roles.

Kind regards.

@dflass

Does the if else statement not prevent a the null pointer?

Well, not really, no. QTcpServer::listen doesn't block, its return value just indicates whether or not your request to listen to a port was successful. This doesn't at all guarantee that you have pending connections for that server socket. As @koahnig pointed out, you should use signals and slots to connect to the interesting events generated by your server socket and handle them appropriately. Do follow his suggestion, and look at the server/client examples, which will give you a good overview on how to setup a TCP server/client application properly.

Kind regards.

Hi and welcome to devnet,

The only answer I see is: benchmark. You have to test your server under heavy load to see how well it's doing.