Summary


Windows imposes a limit on the number of concurrent connections on the Nomad share. The FanOut feature compensates for this limitation by enabling peers connected to the master to themselves allow connections to other peers requiring the download so that more peers can be updated at the same time.

On this page

To use FanOut, the Nomad SpecialNetShare registry value must be updated to include bit 6 (0x40 or 64 decimal) on all machines hosting Nomad .

By default, the Nomad cache share (NomadSHR) is limited to six concurrent connections by Windows. This means that up to six Nomad peers (machines that request the download) can obtain content from the master at any given time (the machine that wins the election on the subnet and becomes the central source for the download). Under normal circumstances, if a Nomad client tries to connect to the master and all six connections are in use, the client retries later.

The FanOut feature compensates for this limitation by enabling the client to ask for an alternative peer on the same subnet that has the content it needs – any other peer on the subnet can respond to this request but will only do so if it meets certain criteria (it must have more content that the client requesting it, it must have available connections on its own NomanSHR and it must not already be connected to a FanOut peer (a machine connected to the master share that responds to FanOut requests and allows other machines to connect to it).

The following illustrations demonstrates how FanOut works.

If a Nomad peer gets a Maximum connections limit when trying to connect to a master, it broadcasts a request who has more than a certain percentage of a package with a certain ID.

A device will respond to a FanOut request if the following conditions apply:

  • If it is currently active and downloading or it is idle and has downloaded part or all of the package from the master
  • It has a larger percentage of the package than the device broadcasting the request
  • If the broadcast request has not been received over a wireless link
  • Its version of the package is greater than or equal to the package version held by the device broadcasting the request
  • It has free connections to its Nomad share
  • Its election weighting is greater than zero – i.e. it is not set as a sensitive server
  • It is not a domain controller
  • It is not part of any inhibited subnets and sites
  • Its NomadSHR exists and P2PEnabled is turned on – i.e. it is not set to 0

The Nomad peer will attempt to connect to the first FanOut peer that responds to its request. In this way, rather than limiting the distribution to six Nomad peers, many more machines can be accessing the download from the master, speeding up the content deployment exponentially on large subnets.
 

Checking to see if FanOut is working

To observe FanOut on the clients when the connection to NomadSHR is reached on the elected master:

  1. Open NomadBranch.log on a client. This client must not be the master.
  2. Notice that the client has failed to connect to the master.
  3. It then polls for a FanOut peer.
  4. It receives a response and starts the download.

Limitations

Nomad FanOut cannot currently be used with the following Nomad features:

  • Nomad installed in WinPE is not capable of becoming a FanOut peer (i.e. a provider of package content) because file sharing is not supported. However, Nomad is capable of requesting content from and connecting to FanOut peers on the local subnet.
  • Nomad FanOut is not compatible with Nomad multicast. If multicast is enabled for a particular package, Nomad FanOut is not used, regardless of the value in SpecialNetShare
  • Nomad FanOut will not be used when Nomad is run in standalone mode
  • Nomad FanOut is disabled for computers using wireless connectivity