If the download is stopped it will resume after following the same process on a different server, or directly from Apple. If it can and the update being requested is on that server then the client will pull the update from the server once the signature of the update is verified with Apple (after all, we wouldn’t want some funky cert getting in the way of our sucking). If there’s one on the same subnet, provided the subnet isn’t a Class B or higher, then the client will attempt to establish a connection to the caching service. In this case, the first device pulls the update down and each subsequent device uses the WAN address to determine where the nearest caching service is. Now, let’s say you have an OS X Server running the new Caching service.

For that matter, according to how fast your Internet pipe is, there’s a chance something smaller, like an update to Expensify will blow out that same network, leaving no room for important things, like updates to Angry Birds! Suck and suck and suck and it’ll probably melt enough to make it through that straw before you can pull it through. If you’re lucky enough to have eaten at the Varsity in Atlanta, just imagine trying to drink one of those dreamy orange goodnesses through a coffee stirrer. That’s 200 of the same update those devices are going to download over your Internet connection, at up to 2 to 3 gigs per download. Let’s say that you have 200 users with Mac Minis and an update is released.

Namely, the way that clients perform software update service location and distribution with absolutely no need (or ability) for centralized administration. “What makes it so cool” you might ask, given that Software Update Server has been around for awhile. This doesn’t replace Apple’s Software Update Server mind you, it supplements. OS X now has a Software Caching server built to make updates faster.

These days, new services get introduced in OS X Server during point releases.

Latest apple server os