Enables Single-Site Download (SSD).


Registry valueDefault valueNotesInstaller property
SSDEnabled0

You can set more than one option at the same time by combining the bit values. For example, to enable clients to fetch downloads using SSD and provide them to peers, set the value to 3 (decimal value 1+2 or 0x3).

To enable clients to fetch downloads using site and local SSD and provide them to peers, set the value to 7.

If you want to enable SSD as a provider after installation, then you also need to configure the registry values for SSDEnabled, PlatformURL and ContentRegistration.

To enable SSD when you install Nomad, you must specify both the MODULE.NOMAD.SSDENABLED and NOMAD.MODULE.PLATFORMURL installer properties. If MODULE.NOMAD.SSDENABLED is configured as a provider then the registry value of ContentRegistration is automatically set to 1 during installation.

If your network is running over a WLAN or have devices on a wireless network you want to be content providers, set ContentProviderOnWifi =1.

MODULE.NOMAD.SSDENABLED


BitHexDecimalDescription
 0x00SSD is disabled, the Nomad client takes no part in the SSD on the site.
00x11SSD is enabled and the Nomad client fetches downloads using SSD. This setting on its own (without provider mode set) should be used with sensitive server weighting. Provider mode is where a peer gets content from another peer but cannot serve it (it cannot act as a master).
10x22SSD is enabled and the Nomad client provides downloads to peers. Enabling this bit causes Nomad to register content with ActiveEfficiency. In practice, this is unlikely to be used on its own. This is automatically disabled for WinPE installations (because cached content is only temporary).
2
0x44

Local SSD is enabled and the Nomad client fetches downloads from a local client (also known as a subnet peer master - the term used for local devices which have content but cannot be located during the normal election process because network broadcasts have been disabled) within the subnet.

In version 6.1.100 the local SSD feature was introduced to supplement site SSD for clients on networks such as wireless where broadcasts are disabled, to prevent each client becoming its own master and downloading direct from the DP. In a SSD enabled environment, a master queries ActiveEfficiency to get a list of devices on other subnets within the site that have content. With local SSD enabled, the master also queries for devices having content within local subnet. If any local peers with content are available, then the master downloads from them, otherwise it attempts to download from Site peers (other subnets in the site), and if the master still cannot find any peers, it downloads the content direct from the DP.

In version 7.0 and later, a master skips using local SSD if it sees broadcast messages from peers. This means clients in mixed network environments can be configured with the same SSDEnabled setting (with Local SSD enabled) and clients can move seamlessly between networks. When on a wireless network (where broadcasts are typically disabled) local SSD can be used. On LAN networks (where broadcasts are typically allowed) local SSD would be skipped because a master is elected and sees broadcast activity from peers.

This setting should only be used if networks have broadcasts being disabled (for example wireless networks) and clients are forced to download from the DP as they can't participate in an election.

Local SSD requires that a peer on the local subnet be configured to provide downloads to peers, that is at least one client on the subnet must be configured with Bit 1 enabled. To maintain consistency with typical Nomad peer sharing behavior where local SSD is not required, configure all clients with SSDEnabled=7. You'll also want to set ContentProviderOnWifi=1.

When enabled, the elected master:

  1. Queries ActiveEfficiency to get list of local devices having the content.
  2. Queries each of those devices to check if they are available and have the content. The list is ordered by percentage of content the device holds.
  3. Repeats the same process for devices on other subnets (existing SSD feature).
  4. Stores a list of subnets as well as site devices in memory.
  5. Cycles through the list in the following order:
    1. Subnet peer master (fetched from list of local devices from ActiveEfficiency)
    2. Site master
    3. DP

To distinguish between a master derived from ActiveEfficiency and an election, the log records: Connection::SetDownloadSource = SubnetPeer (an elected peer) instead of Connection::SetDownloadSource = Peer (an SSD peer master).