Actually, that's similar to what I did in a prior project. That one had an authenticating checksum in the first packet, as it was used to set up a file transfer session. It would spin off up to 10 file sync sessions.

Since this app integrates with WSUS and our system service that manages WSUS updates, even with 500 servers, with a 60 minute check-in cycle (more common is 2-4 hour and up to 12 hour), the concurrent load is pretty small, and packets are small - request payloads are <20 bytes, and responses are < 60 bytes. Timing isn't critical for this app - basically the client says "HOSTNAME:WHEN?" and the server does a lookup and replies "3,6,22:00" (Third Saturday at 10pm). The point of this is to not use INI or REG entries on each system to define when updates are installed. It can request/send other settings, but those are for startup (DEBUG Returns 0/1), VERSION (returns a version string and Update Path - the largest at about 120 bytes typ.)

This is one of our low/mid end products that currently supports per-server config files, allowing a simple WSUS server to be used to target MS Updates to a specific monthly change window. Changes start precisely (+0/-1 second) at the defined time, install repeatedly until all updates are applied or the change window expires, rebooting as many times as needed. With central management and configuration, smaller organizations can have a low cost version of systems like Tivoli/Big-Fix with much less training and management overhead.

The release I'm working on will use an INI file on the server for up to 100 managed servers, and will pave the way for a larger, SQL-based system. Leveraging our SWDIST technology, we can deploy multiple management servers and allow the client to located the closest server using DNS SRV Records.

So - thanks for the ideas.. (I had to think about "kthanxbye" for a bit, though! ;\) ) One question.. I had thought about
 Code:
Client > Server : hi, host here, Connect?
Server > Client : hi, server Ack, use port 10400
Client > Server:104000 - Host, Request XXXX, CSum
and so on...
This would end when the Client sent a "Host,EOT" message, or no communication was received for 90 seconds or so. Your example shows the host replying via the spawned channel on the secondary port. I'm not sure how that would work.

Thanks,

Glenn
_________________________
Actually I am a Rocket Scientist! \:D