Hello Bruce and all...
The NetSimple-project I am working on runs well. It is a SimpleServer with quite some SimpleClients, which stay connected permanently.
To keep that connection alive, I set ThisClient.InActiveTimeout = 900,000 (! 900 seconds = 15 minutes) and send a HeartBeat every 5 Minutes.
On the serverside I maintain an InMemory-table with all connented clients, holding IP-Address, SockID, Socket, time of last connect / Heartbeat etc.
Once in a while, the server will send out a message to all connected clients, forcing them to open a window.
I learned now, that this project will have to address 2,000 clients now.
A Windows Server OS should be capable for that amount of parallel connenctions. My concern is the timing of the Heartbeats.
With 2,000 clients sending a Heartbeat every 5 minutes, the server will get an average of 6 requests per second.
That will mean, that in a phase of sending a message to all stations, the IMDD-table will get LOOPed through, SET() NEXT() sending a message, but every 1/6th second the record-buffer will be touched from the incoming Heartbeat. I expect the LOOP to stumble then and not work properly, sending that message to each connected client, because this happens all on the same THREAD.
Making the client to send just a .PING() will not neccessarily keep the connection open, right.It simply says, that the machine that gets sent a PING responding, therefore it is reachable, but it says nothing about any connection.
So...... I thought of changing places.... Not the clients will send heartbeats, but once the server has noted the connection, it will be the server that sends a HeartBeat to all 2,000 stations.
If a proper resonse returns, the clients record in the IMDD-table can be updated.
ELSE
If no response comes back, the client can be purged from the list or maybe gets set to "not connected" inside .ErrorTrap().
That means, I have no permanent chatter on the line, it is reduced to the absolute necessary.
If the client itself does feel disconnected, it will auto-reconnect and listed again.
If clients get (re-)connected during that LOOP of Heartbeat or LOOP of Message, it is a rare occurance and I can maintain a temporary Queue, that can be parsed and integrated into the IMDD-table soon after such a LOOP has been finished.
Does that sound reasonable?
Thanks for any advice,
Wolfgang