Nomad FanOut

Windows imposes a limit on the number of concurrent connections on the Nomad share. The Nomad FanOut feature compensates for this limitation by enabling any peer that has more content than the requester to respond to the FanOut request. It is not limited to peers that have an active connection to the master.

How FanOut works

To use FanOut, the Nomad SpecialNetShare registry value must be updated to include bit 6 (0x40or 64 decimal) on all devices 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 (devices that request the download) can obtain content from the master at any given time (the device 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 Nomad client retries later.

The FanOut feature compensates for this limitation by enabling the Nomad 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 than the Nomad client requesting it.
Have available connections on its own NomanSHR.
Not already be connected to a FanOut peer (a device connected to the master share that responds to FanOut requests and allows other devices to connect to it).

Refer to Using FanOut for large subnets for an example scenario about deploying software in a large network and how you can monitor those deployments using the Content Distribution app.The following illustrations demonstrate how FanOut works.

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

A device responds 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. Refer to Election weighting.
It is not a domain controller.
It is not part of any inhibited subnets and sites - please refer to Inhibiting subnets and sites.
Its NomadSHR exists and P2PEnabled is turned on, 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 devices can be accessing the download from the master, exponentially speeding up content deployment on large subnets.

Checking to see if FanOut is working

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

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

Limitations

Nomad FanOut cannot currently be used with the following features:

Nomad is 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.