On Thu, Dec 28, 2000 at 06:08:16PM -0500, Matt Zimmerman wrote: > On Thu, Dec 28, 2000 at 08:22:52AM -0600, Vince Mulhollon wrote: > > > My point being, that yes I already use squid as a proxy server for a whole > > network of apt-geting debian boxes and after only a little work it works > > OK, but something using IP multicast would be better due to lower network > > utilization. True, doing multiple simultaneous upgrades means eventually > > an upgrade would kill all the machines simultaneously, and my high end > > pentiums are going to decompress the gzip parts much faster than my old > > 386s, although there are probably ways around that, just because all the > > .debs are distributed all at once in one multicast burst doesn't mean they > > have to be installed all at once. Anyway, squid does not do IP multicast > > to multiple simultaneous clients, last time I checked. Another cool > > ability of an integrated cache would be that the "fetching" machine could > > maintain a list of all the machines it pushed the new .deb to, and when all > > the "client" machines have a copy of the new .deb, clear it from the cache. > > With a squid solution, squid has to guess if its OK to clear the cached > > .deb based upon access time, size, etc. Even worse, my squid only caches > > files less than 8 megs, thus each machine downloads its own copy of emacs, > > etc. A cache for general web use "works", but a cache designed > > specifically for .deb packages would work better. > > There is very little tuning you could do for a general-purpose web cache in > order to support .debs that would not be generally applicable to other > situations. Rather than creating a new caching proxy for .debs, why not > improve squid to do what you want? That way, other applications (which may or > may not exist yet) can also benefit. Squid does in fact use multicast, but > only for ICP (and thus only for very small objects). I think you will find > that IP multicast is not particularly suited to this task. In order to avoid > overflowing socket buffers on the client, the server would have to multicast > its data only as fast as the slowest client. Not only does this cause a > performance bottleneck, but it is tricky to detect how fast the client can > receive data, and adjust accordingly. If the systems are not all on the same > LAN, the server must take into account network congestion, etc. This is what > protocols like RTSP try to do. Where real-time content delivery is not an > issue, TCP does a much better job of responding to changing network conditions. > Of course, if all of the systems are on the same LAN, you could use real link > layer broadcast instead of IP multicast. > > The issue of maximum object size is a configuration issue. The ability to be > smarter about particular object types sounds like a good idea for a squid > enhancement. > Why not look at this from a different perspective? I don't know if it may be useful or not for upgrading machines, but the multicast server would be a very nice thing for mass installations. Image large computer rooms at a lan with (usually) uniform hardware. If there was a package (say apt-getd) that could be installed on one, already running box, which lets you make a special boot disk. The machine that runs apt-getd has a way to get to a debian archive (be it local mirror, a set of cdroms - this would probably be a bit harder with cd swapping - or a mirror on the larger network that it is connected to). You boot with the floppy that configures the network, apt-getd starts spawning multicast packets, the workstations pick them up and install them. Voilà! You just installed an entire network! This would be especially useful for universities/colleges. In fact, a friend of mine is doing a similar thing for his thesis - only he uses a 'Ghost' approach - the 'mother server' has an installed disk which gets multicast to the clients. This *was* on request of the college he's studying at - currently they have to take an installed harddrive, open the pc case and install it that way (the commercial 'Ghost' program seems to have a problem with their hardware). Regards, Filip -- "The nice thing about Windows is - It does not just crash, it displays a dialog box and lets you press 'OK' first." -- Arno Schaefer
Attachment:
pgp2boPpipooG.pgp
Description: PGP signature