Has this concept been considered? Instead of having all users connect and DL their own copies of security updates (which requires tremendous bandwidth), would it be possible to use multicast to 'broadcast' the updates. The thought is that updates could be distributed without saturating the server's link(s).
Assume (for discussion purposes) that users have 3Mbps DL speeds. A client/server program would be written that uses both multicast and TCP connections. The client connects to the server with a standard TCP connection and tunes into the multicast stream. The client records which chunks of each package it has received; more to the point, it records which chunks it misses. The client stays tuned into the mcast stream until it comes around again to where it first tuned in. In a perfect world, the client would now have all the security updates. But since the internet world isn't perfect, there may well be lost chunks, which will need to be re-transmitted. Hence the TCP connection. As the client notices missing chunks, it sends a request for retransmission to the server, which coordinates all these requests and retransmits the packet out the mcast stream. Perhaps it could be smart: if it has more than 50 requests for a missing chunk, it could mcast that chunk. Fewer than 50? It sends them through the TCP connection. Given a 3Mbps constraint, the mcast stream could be limited to 1.5Mbps, leaving reasonable room for re-transmitting chunks as needed. One could take the chunk concept one step further, such that each transmitted packet contains the current chunk and the previous chunk. To take the concept one step further, the server could source multiple mcast streams: 20Mb for well-connected servers, 3Mb for cable, and 1.5Mb for DSL. And maybe even a 40Kb stream for dialup. If one wanted to refine the process, the client could inform the server as to which packages it wants. The server would prioritize and aggregate all the requests. The package with the most requests would be broadcast next, unless the oldest request is more than, say, 20 minutes old. Or, multicasting could be used only for packages larger than some minimum size, or for the 'most popular' packages. I dreamed up this scheme as a means of minimizing the bandwidth required to distribute security updates. Overall, users should receive their updates in much less time even though some users might have to wait a little longer if they only need a few packages. This scheme could even be used to distribute packages on the main server(s), not just security updates. So what have I overlooked? Neal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
