How to configure peer-to-peer downloading in IT Management Suite? (Windows only)
search cancel

How to configure peer-to-peer downloading in IT Management Suite? (Windows only)

book

Article ID: 184990

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

How to configure peer-to-peer downloading in IT Management Suite? (Windows only)

Resolution

This article contains the following sub-topics:

 

About peer-to-peer downloading feature

The peer-to-peer downloading feature lets you download and distribute the software delivery and patch packages to Windows computers. It minimizes the software delivery time and provides you with a reliable software delivery to all endpoints. The peer-to-peer downloading feature significantly reduces the load on WAN and on the IT Management Suite infrastructure.

You can benefit from this feature when distributing the Windows cumulative updates and other software packages to your Windows client computers. You can also use this feature when managing the Windows 7, 8, and 10 devices at sites with low-bandwidth connections and no dedicated package servers.

Note:

The peer-to-peer downloading feature is not supported in Deployment Solution.

Note that peer-to-peer downloading is different from multicast downloading. The idea of multicast downloading is to temporarily use one regular client computer as a package server which downloads a package from Notification Server and then transmits it to the other client computers. In peer-to-peer downloading, the peer computers find each other, request the information about the packages, and download the package from the peer computer that has the required package available.

Note:

You cannot use multicast downloading and peer-to-peer downloading simultaneously.



The concept of peer-to-peer downloading is as follows:

Symantec Management Agent discovers the peers.

After you enable peer-to-peer downloading, Symantec Management Agents discover peers by sending broadcast or unicast HTTP messages and join the Distributed Hash Table (DHT) network.

HTTP server stores the list of packages.

The HTTP server is part of the Symantec Management Agent process. It starts automatically after you enable peer-to-peer downloading.

The HTTP server stores the list of package GUID-s with their associated states.

The Package Delivery component on Symantec Management Agent informs the HTTP server about the folder where the downloaded packages are stored and about the state of each package.

DHT provides the package information to the peers.

The DHT algorithm uses the list of packages from HTTP server to generate the information for the peers in the DHT network.

When the peers look for a specific package, they look for the state of the package and the location of the package in the DHT network.

Package Delivery downloads the packages.

When the Package Delivery must download a package, it first looks for the GUID of the required package in DHT. DHT responds with a list of peer computers where this package is being downloaded or already available.

If the package is being downloaded on one of the peer computers, the Package Delivery retries to download the package from this peer later.

If the package is already available on some peer computers, the Package Delivery attempts to download the package from one of these peers. Once the package is downloaded, the computer changes the state of this package in DHT to "ready".

When the Package Delivery cannot find the required package on the peer computers, it changes the state of this package in DHT to "downloading" and starts downloading the package from Package Server or Notification Server. When the download of this package finishes, its state is changed to "ready".

 

Configuring the settings for peer-to-peer downloading

You configure the peer-to-peer downloading settings in the Symantec Management Console, on the Targeted Agent Settings page, Software Delivery tab (prior to 8.6 release, on the Downloads tab).




Note:

To ensure that the peer-to-peer downloading works efficiently, Symantec recommends the following additional configuration:

Keep the packages on the client computer for at least one week.

Peer-to-peer downloading does not function or functions with limitations if you remove the package from the client computer immediately or after a few days.

To avoid this issue, you must configure the Package files will be deleted from the client computer if unused for option as required. The suggested minimum period for the package to be stored on the client computer is 1 week.

You can configure this option in the Symantec Management Console, on the Symantec Management Agent Package page.

To access this page, in the Symantec Management Console, on the Settings menu, click All Settings, and then in the left pane, expand Settings > Agents/Plug-ins > Symantec Management Agent > Windows.

Configure a schedule for the installation of the Windows 10 feature updates.

Peer-to-peer downloading does not work efficiently if you configure the Windows 10 feature updates to be installed ASAP. In this case, each computer would start installing the feature update right after the package download. During the update installation, the Symantec Management Agent is inactive and not able to distribute the downloaded feature update to its peers. As a result, numerous agents download the feature update directly from Package Server or Notification Server.
Symantec recommends setting specified time for the update installation to give computers enough time to distribute downloaded feature update to their peers.

You can configure this option in the Symantec Management Console, on the Default Software Update Plug-in Policy page.

To access this page, in the Symantec Management Console, on the Settings menu, click All Settings, and then in the left pane, expand Agents/Plug-ins > Software > Patch Management > Windows.

Alternatively, you can configure this option for the specific software update policy.


To configure the settings for peer-to-peer downloading

  1. In the Symantec Management Console, on the Settings menu, click Agents/Plug-ins > Targeted Agent Settings.
  2. In the left pane, select the policy for which you want to configure the peer-to-peer downloading settings.
  3. In the right pane, on Software Delivery tab (prior to 8.6 release, on the Downloads tab), under Peer-to-peer Downloading Configuration Settings, configure the settings.
    Note that the default settings are suitable for most of the environments. However, if you notice too many direct downloads or long package delivery period, you may need to customize the settings. The settings for peer-to-peer downloading are as follows:

    Allow Symantec Management Agents to download packages from peer computers

    Enables the peer-to-peer downloading functionality that allows the client computers to download packages from their peers.

    Note that only the peer computers that are managed by the same Notification Server can download packages from each other.

    TCP/UDP port

    HTTP server listens to the TCP port. Peer discovery engine listens to the UDP port. The same port number is used for both.

    HTTP request timeout

    The period that the HTTP server should wait for the peer commands or file download requests from peer computers to arrive. If the request is not completed in a specified time, it is canceled with a timeout error.

    Note that if the timeout period is short (5-10 seconds), the slower client computers may drop out of the DHT network.

    Maximum upload bandwidth

    The maximum upload speed that the uploading peer can share between downloading peers.

    Maximum download bandwidth

    The maximum download speed that the Symantec Management Agent can use when downloading a package from a peer computer.

    Note that this value is independent from the general throttling value. For example, if you set the general throttling to 500 KB/s and peer-to-peer downloading throttling to 10 MB/s, the bandwidth is limited to 500 KB/s while downloading from Notification Server or Package Server outside the subnet, but the peer-to-peer downloading traffic inside the subnet has 10 MB/s bandwidth.

    Maximum number of requests per core

    The maximum number of simultaneous requests from the peer computers that the HTTP server can process.

    Note that this setting is per CPU core. For example, if you enter 5 for this option, the computers with dual core processor will have a total limit of 10 requests.

    Maximum number of connections

    The maximum number of simultaneous connections that the HTTP server allows.

    This option lets you limit the number of the client computers that can simultaneously connect to a peer.

    Total log size

    Total size of HTTP log files. The size of a single log file is 1 MB.

    Peer announcement

    A period after which Symantec Management Agent sends out a broadcast packet to its peers.

    Unavailable peer timeout

    A period after which a peer computer is considered as unavailable since it sends no broadcasts and does not answer to the requests.

    Additional subnets to discover

    Additional network segments for peer engine to discover.

    Note that the peers try to connect directly to the added subnets. Add the subnets only if the communication between the network segments is expected. If you expect communication only between very specific set of subnets, create a dedicated Targeted Agent Settings policy with additional subnets and target it correspondingly.

    Maximum number of peers per download attempt

    The maximum number of peers from which the client computer tries to download the package.

    Symantec suggests increasing this number if the computers often go offline.

    Maximum download attempts per package

    The maximum number of attempts to download a package using peer-to-peer downloading. Each attempt consists of selecting the specified number of peers and then attempting to download the package from each peer.

    If all the attempts fail, the Package Delivery will download the package directly from the Package Server or Notification Server.

    Period between download attempts

    The period of time after which the peer tries to download the package from another group of peers.

     Note that the timeout period for peer downloading does not increase. When a client computer downloads a package from Notification Server or Package Server, the timeout period increases on each attempt.

    File block download progress on peer

    This option lets you configure how often a peer computer notifies its peers about the package download progress.

    A peer computer downloads a file block by block. The size of each block is 2MB by default. The peer computer sends notifications about the package download progress after a specified period of time. If download of a file block is completed, other peers can start downloading it.

    Don't use peer-to-peer downloading

    In certain cases, you can disable using the peer-to-peer downloading.

    For example, if the computers are outside of the internal network and use Cloud-enabled Management for communicating with Notification Server.
  4. Click Save changes.

 

Viewing peer-to-peer statistics

Each peer computer gathers the statistics related to peer-to-peer downloading and sends it to other peers.
You can view the statistics on a peer computer, in the Symantec Management Agent UI, on the Diagnostics page, on the Peer Downloading tab.

To enable the Diagnostics page in the Symantec Management Agent UI

  1. On the peer computer, open a command prompt window as an administrator and go to the following directory:
    install_path\Program Files\Altiris\Altiris Agent
  2. Run the following command:
    Aexnsagent /diags
  3. On the Symantec Management Agent toolbar, click Diagnostics.

On the Peer Downloading tab, the upper list provides you with the information about the peer computers. The lower list provides you with the information about the packages. On both lists, you can use the right-click menu to perform tasks on the selected items. The options on the toolbar let you perform global tasks. For more information about these tasks, press F1.

The statistics on the Peer Downloading tab is as follows:

Succeeded Download Requests The number of successful HTTP requests that the peer server has served.
This number shows only the file download requests. One request does not equal to downloading the entire file, because several requests are used to download a file. The number of requests depends on the file size. For example, during downloading a large file, more requests are made.
Failed Download Requests The number of failed HTTP requests.
Failure can occur because of the connection timeout, broken connection, etc. The reason for broken connections is usually a computer restart or a Symantec Management Agent restart.
Succeeded DHT Requests The number of successful DHT commands that the agent has sent and received.
The DHT commands are the HTTP requests that are needed to maintain the peer network and find the peers that have a package available for downloading.
Failed DHT Requests The number of failed DHT commands.
Usually, the DHT requests should not fail. However, if you have several Notification Servers in your environment, the number of Failed DHT Requests may include occasional requests from the computers that are managed by another Notification Server.
Failure can also occur because of the connection timeout or broken connection.
Data Sent The total sum of bytes that the peers have sent in all download requests.
Note that this number includes both the successful and the failed requests.
The client computers use this number to select the peer from which to download the package. The smaller the number, the higher the chance that the peer gets selected for package download.
This sum also shows the approximate number of bytes that the selected computer has provided to its peers.
Data Received The total sum of bytes that are received in all download requests.
DHT Data Sent The total sum of bytes that are sent in all DHT requests.
DHT Data Received The total sum of bytes that are received in all DHT requests.

 

Package delivery time using peer-to-peer downloading

The table below introduces the expected behaviour of package delivery when using peer-to-peer downloading vs using regular package downloading.

Table 2-1                     Package delivery using peer-to-peer (P2P) downloading vs using regular package downloading

        Peer-to-Peer Traditional (*calculated values)

SMA configuration

Network bandwidth in segment

Peers in segment

Package size

Direct downloads from NS/PS (WAN link)

 Traffic through WAN

Time to deliver to all peers (after initial download)

Overhead traffic

 Direct downloads from NS/PS (WAN link) Traffic through WAN Est. delivery time
(with 10Mbps WAN)

Default

1 Gb/s

150

100 MB

1

 100 MB

45 min

12-15 MB

 150 15 GB 200 min

Default

1 Gb/s

150

1 GB

1

 1 GB

65 min

12-15 MB

 150 150 GB 2000 min

Default

10 Mb/s

10

2.8 GB
(Win10 update)

1

 2.8 GB

345 min

 

 10 28 GB 375 min

 

Limitations of peer-to-peer downloading

Peer-to-peer downloading has the following limitations:

  • If you have any 3rd party firewall enabled in your environment that blocks traffic on port 56118, the peer-to-peer downloading feature does not work. To work around the issue, you must manually add the exceptions.
  • During the upgrade from ITMS 7.6 HF7 to 8.0 HF5, the peer-to-peer downloading settings are reset to default.
    If you are using peer-to-peer downloading feature in ITMS 7.6HF7 (enabled through a point-fix), you must save the changes that you have made to the settings and restore them manually after the upgrade.



Frequently Asked Questions

    • Does HTTP(s) package transfer use the BITS process?
      HTTP(s) package transfer does not use the BITS process.
    • Does peer-to-peer use HTTP or UNC package transfer?
      Peer-to-peer engine uses HTTP only. Peer computers share the content using HTTP.
    • Is the Maximum number of requests per core setting actually per CPU core of the file provider?
      Maximum number of requests per core is the number of HTTP requests that Symantec Management Agent's HTTP server processes. The rest of the requests are waiting.
    • If a peer-to-peer download is interrupted by the file provider going off-line, what does the file receiver's agent do regarding that package, how does it go about getting the file?
      The agent goes back to DHT and tries to find another file provider. However, note that Symantec Management Agent looks for all the peers just once during one download attempt.
    • How to keep agents from reaching outside their site for peer-to-peer packages? What is the expected behavior?
      In peer-to-peer downloading, the Symantec Management Agent does not use any information of the subnet/site tree that you can see in the Symantec Management Console. The agent only communicates to the peers that are available in the networks where computer's network adapters are connected to. The agent is not able to communicate to the computers located in the subnets that are not directly available.
    • Is there a way to limit the number of computers that contact a computer for a peer-to-peer download (is that what the setting #3 does)?
      There are two settings:
      1) Maximum number of connections is peer-to-peer “server” side. This option lets you limit the number of clients that can download a file from a peer or can perform peer-to-peer requests to that peer.
      2) Maximum number of peers per download attempt is peer-to-peer “client” side. This option lets you limit the number of peers the Symantec Management Agent tries to download the file from.
    • Is there a way to exclude a specific computer from being a peer-to-peer target for other computers within a site where peer-to-peer is enabled?
      The peer-to-peer feature does not have exclusion logic built in but one of the workarounds is to clone the Targeted Agent Settings, enable peer-to-peer and apply it only to the desired list of client computers.
    • Does peer-to-peer download feature use TCP or UDP during the downloads. Does the system switch based on if one is available or not?
      UDP is only used for the broadcast and for the creation of the DHT network. TCP is used for the rest of the communication and file transfer amongst peers.
    • There is an option for Peer Announcement.  Why wouldn’t the agent attempt to find all its peers immediately upon any change in networking?
      It does, but it does that in chunks to reduce the load on the network and prevent ARP storms that can happen under some conditions. If you turn off the announcement then the other discovery methods will work. However, with UDP packet announcements it is faster.
    • How to ensure that peer-to-peer is never used for agents on a VPN?
      Enable the option called "Over VPN connection" under the "Don't use peer-to-peer downloading"
    • If you have a 3rd party firewall enabled in your environment that blocks traffic on port 56118, the peer-to-peer downloading feature does not work. To work around the issue, you must manually add the exceptions. What are the exceptions/ports/protocols/directions that require configuring?
      You need to enable all inbound and outbound TCP and UDP traffic on port 56118.
    • How to block the DHT network on the computers in the VPN subnets?
      You must block all inbound and outbound TCP and UDP traffic on port 56118 for VPN network.
    • Does the client machine performs some sort of security verification before delivering patch updates to its peer?
      1. The patch update's digital signature is checked prior to its installation on client machines. If it doesn't match, we don't install it.
      2. The Symantec Management Agent/Altiris Agent checks if package is not corrupted using cryptography hashes. This happens during a package download regardless where a peer is downloading package from – SMP server, Package Server (PS) or peers. So if one peer is compromised for example and the package is tampered in that peer, then the other peers will fail package downloads from that peer.
      3. This security validation is built not into p2p process but into package download engine.
    • Is port 56118 the only port to be considered or if there is any other specific port used for P2P communication (in order to open the proper network exceptions)?
      Yes. The main port is 56118.
      iPort 56118 (or any other free custom port) is the only port used for p2p traffic. TCP and UDP should be enabled in both directions.As mentioned before in this article, If you have any 3rd party firewall enabled in the environment that blocks traffic on port 56118, the peer-to-peer downloading feature does not work. To work around the issue, you must manually add the exceptions.
    • Is this an encrypted communication between peers? Do they transfer encrypted files between them?
      P2P control traffic is encrypted, i.e:

      1. The traffic that peers use to find each other
      2. To find the packages
      3. and to maintain p2p network alive.

      Package download traffic between peers uses HTTP protocol. It is not encrypted, it's authenticated and hashed though. Hashing is used to validate package integrity during package downloads as for any other downloads from the Notification Server and Package Server.

    • P2P is between clients and if there is any virus infection in a client, will that get passed to another system? any mechanism to scan for viruses while transferring? What do we do to prevent if a file has been compromised?
      Package hashes are used to validate integrity. The hashes are actually chained, it's like a blockchain.

      The package files are divided into 2MB blocks, the first block is hashed and the block hash is stored, then the second block is hashed in the way where block hash depends on the first block hash, then 3rd block is hashed, etc. etc. until we get the whole package hash chain. These hashes are chained together and they are used to validate each 2MB block integrity during downloading. 

      If any block is invalid then the whole download terminates. HMAC, AES 256 and SHA256 algorithms are used for hashing. The main AES256 key is controlled by the server, i.e. different NS servers have different hash chains for the same package.

      So if any file is corrupted or replaced on a peer, if even a single byte is invalid then other peers will find out about that and stop downloading.

 

Powered by Wolken Software