A Windows XP help forum. PCbanter

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.

Go Back   Home » PCbanter forum » Windows 10 » Windows 10 Help Forum
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

I just had a radical idea



 
 
Thread Tools Rate Thread Display Modes
  #31  
Old March 17th 19, 10:39 PM posted to alt.comp.os.windows-10
VanguardLH[_2_]
external usenet poster
 
Posts: 9,991
Default 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.
Ads
  #32  
Old March 17th 19, 10:47 PM posted to alt.comp.os.windows-10
Rene Lamontagne
external usenet poster
 
Posts: 1,800
Default I just had a radical idea

On 03/17/2019 5:39 PM, VanguardLH wrote:
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.


Yeah, It stinks like bittorrent, so they can shove both of them where
the Sun don't shine.

Rene

  #33  
Old March 18th 19, 04:28 AM posted to alt.comp.os.windows-10
Char Jackson
external usenet poster
 
Posts: 9,827
Default I just had a radical idea

On Sun, 17 Mar 2019 17:39:10 -0500, VanguardLH wrote:

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).


I'm perfectly comfortable with what you call the scary part because it
works just like bittorrent, which you mention in the next paragraph
below.


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.


Good points, thanks.

  #34  
Old March 18th 19, 05:12 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 8,832
Default 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.


They're signed. Doesn't matter how they're sliced and diced,
a package cannot be installed without the signature working.
Change 1 bit of content, the signature will fail.

Even when materials come straight from a Windows Update
server, we have to assume the delivery method could be
compromised in flight. The signing step, is the ultimate
protection for that path. That covers MITM attacks.

Paul
  #35  
Old March 18th 19, 05:26 AM posted to alt.comp.os.windows-10
Char Jackson
external usenet poster
 
Posts: 9,827
Default I just had a radical idea

On Mon, 18 Mar 2019 01:12:19 -0400, Paul wrote:

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.


They're signed. Doesn't matter how they're sliced and diced,
a package cannot be installed without the signature working.
Change 1 bit of content, the signature will fail.

Even when materials come straight from a Windows Update
server, we have to assume the delivery method could be
compromised in flight. The signing step, is the ultimate
protection for that path. That covers MITM attacks.


Then, as I suspected, it doesn't matter where update chunks come from.
Could be MS, another PC on the LAN, or another PC on the Internet. It's
all the same.

However, if as you said earlier, the feature doesn't really work, then
it's pointless. I might as well disable the feature and get updates from
MS.

The reason I asked in the first place is that I have about two dozen
Win10 VMs, and counting, and it seemed a shame to get updates for each
of them separately. I guess that's how it needs to be, though.

  #36  
Old March 18th 19, 05:39 AM posted to alt.comp.os.windows-10
VanguardLH[_2_]
external usenet poster
 
Posts: 9,991
Default I just had a radical idea

Char Jackson wrote:

The reason I asked in the first place is that I have about two dozen
Win10 VMs, and counting, and it seemed a shame to get updates for each
of them separately. I guess that's how it needs to be, though.


That's what I use WSUSoffline for. I run it to create a repository that
I could network to or tote around on a USB flash drive (to, say, mount
in your VMs). I have WSUS offline retrieve updates for several
products. Looks like the W100_x64 is for Windows 10 x64 and it's about
9 GB in size.
  #37  
Old March 18th 19, 06:47 AM posted to alt.comp.os.windows-10
Paul[_32_]
external usenet poster
 
Posts: 8,832
Default I just had a radical idea

Char Jackson wrote:

Then, as I suspected, it doesn't matter where update chunks come from.
Could be MS, another PC on the LAN, or another PC on the Internet. It's
all the same.

However, if as you said earlier, the feature doesn't really work, then
it's pointless. I might as well disable the feature and get updates from
MS.

The reason I asked in the first place is that I have about two dozen
Win10 VMs, and counting, and it seemed a shame to get updates for each
of them separately. I guess that's how it needs to be, though.


If I knew what the magic recipe was to get DoSvc to
work, I'd tell ya :-) I was just annoyed it lay there
like a dead fish and didn't do anything. I probably
made a mistake somewhere setting it up. Not enough
disk space or the like.

I prefer software that tells you instantly you
fouled up. I don't like experiments with long
baselines, where it takes three months to get
a budge out of them. I'm just not that patient.

In theory, setting up one VM, switching on local
DoSvc, then issuing commands to do Windows Update,
should be populating its DoSvc cache. Then,
installing a second VM, should "listen" to its buddy
on the LAN. You then need a recorder on the first
VM, to log the amount of traffic that results (to
prove that's where the update came from).

Due to the "noise level" on Windows 10, it's pretty hard
to isolate behaviors and prove they're the exact source
of traffic. Win10 could start randomly pulling in
cat pictures, while I'm monitoring for DoSvc. It
does that for background images for the lock screen.
It does that for "Apps" and "App Updates" which are
done randomly, and outside the normal Windows Update
path. And that sort of **** happens the moment I
try to do an HDTune run.

We really need service designs, where DoSvc says:

"Won't serve content because: Bad mood"

"Serving KB123456 to 192.168.1.2"

"Saving recently obtained KB123457 to cache"

"Discarding KB123456 because: superseded"

Paul
 




Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off






All times are GMT +1. The time now is 09:39 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
Copyright 2004-2019 PCbanter.
The comments are property of their posters.