If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#15
|
|||
|
|||
I just had a radical idea
Char Jackson wrote:
Thanks for the detailed reply. As for the possibility of corrupt updates being shared within the LAN, I assume each update package is signed so that a host knows if it can be trusted. However, if MS isn't taking advantage of the other hosts on the LAN in this way, then I might as well just disable the whole thing. The scary part, even omitting the possibility of malicious tampering, is that updates are not delivered whole from host to host using WUDO. Instead pieces of the update file are delivered and the pieces can come from different hosts through different routes. It was bad enough when you'd get an update (in whole) from Microsoft's WSUS server and had problems getting it installed. With WUDO, rebuilding the update file from pieces adds another potential instability, and you haven't a clue from where the bad update piece originated. The piecemeal approach is to permit resume of the update retrieval (from multiple sending hosts). https://www.deviousweb.com/2015/08/0...-optimization/ "WUDO works a lot like bittorrent. Your computer is used as part of a global peer-to-peer network to allow the distributed delivery of software updates with each person distributing a little bit of the files across multiple computers and helping everyone download updates more quickly." https://thehackernews.com/2015/08/wi...10-update.html "our computer running Windows 10 is used as part of a peer-to-peer network to deliver software updates faster to others, each person distributing a little bit of the files across multiple computers and helping everyone download updates quickly." So, to speed up the download, the P2P client (WUDO) grabs pieces of the file across multiple hosts while retrieving them in parallel streams over the network to rebuild them locally. I'd rather get one complete file and from a known source (Microsoft's WSUS server). There also seem to be a plethora of conditions that will prevent the use of WUDO, so your host ends up using WSUS instead. https://cmma.org/cmma-blog/the-pros-...-optimization/ "No control over content" That point concerns me. While WUDO builds a local cache for P2P distribution of the update (in pieces), it seems it will add more to the local cache for a host than the updates only needed by that particular host. BITS was a known network traffic manager, plus any process can utilize BITS to manage their downloads, like updates to a program and not just for Windows (I've yet, however, to see anyone other than Microsoft using it, but then I'm not knowledgeable about the inner workings of all software regarding their updates). WUDO doesn't use BITS, and why users have been reporting their network getting choked by WUDO. With the problems with WUDO choking your network, its efficiency and parallelism is lost with slow delivery. All because Microsoft, as with everything Windows 10, thinks your computer is their property, so they're going to steal a portion of your PC to use as their distributed server farm. I don't run any variant of Bittorrent or its ilk on my hosts. I certainly don't want a variant from Microsoft. I'd rather schedule a run of WSUSoffline which connects to *Microsoft's* WSUS server. It definitely impacts the usability of the host where it runs and generates lots of traffic (and why I schedule it), and I can tote or FTP its update store to my other hosts over my local network WHEN *I* choose. Just as with Windows 10 updates not being under your control of when and preparing for the update(s) (by closing all your work and saving a backup image since System Restore has proven unreliable), I don't want some other backgrounded update distribution scheme employed to distribute updates to other hosts when I'm not going to apply them there anyway at the time of piecemeal delivery (I disable the BITS and WU services to enforce when *I* want to do the updates). More FM (****ing magic) to go wrong, harder to troubleshoot, doesn't save on network bandwidth (since even in paralleled piecemeal fashion the entire file still has to get sent) and isn't as well backgrounded as BITS, and all under the guise of getting you the updates quicker (which I've yet to see any benchmarking to prove so) but is really to offline some of the update network off Microsoft's servers. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|