> For the complete documentation index, see [llms.txt](https://docs.adaptiva.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.adaptiva.com/platform/user-guide/locations.md).

# Locations

Locations define client communication behavior in the OneSite platform

A Location is defined by one or more IP ranges intended to identify machines that are connected over a LAN. Setting up Locations is the first step in designing your network topology.

Locations define how content, such as patches, flow through your network to your devices.

For more information regarding network topology, please see our [Network Topology](/platform/user-guide/platform-management/network-topology.md) page. This page covers additional information regarding:

* [Location hierarchy](/platform/user-guide/platform-management/network-topology.md#locations)
* [Content flow](/platform/user-guide/platform-management/network-topology.md#content-flow)
* [Transport protocols](/platform/user-guide/platform-management/network-topology.md#onesite-protocols)

You should also review the following topics:

* [Locations Settings and Actions](/platform/user-guide/locations/locations-settings-actions.md)
* [Location best practices](/platform/user-guide/locations/location-best-practices.md)

## Location types

Location types affects the behavior of how the Adaptiva Client communicates within a Location. There are three Location types: **Default, VPN, and WiFi.** Each location type is defined below.

{% hint style="info" %}
It is important to define Locations by their Location types accurately to the physical network. If not properly added to a correct location type, you may run into issues like:

* If a **Default** location is created for devices connected to a wireless network, those devices will attempt to communicate by broadcast. The wireless Access Point may block these transmissions, preventing peers from communicating effectively within the Location.
* A VPN client added to a **Default** Location will pull content in two WAN hops—first to the VPN gateway, then through the tunnel to the client—slowing delivery and increasing network load.

When a physical location includes both a wired and a wireless subnet, create a separate Location for each. Set the wireless location to WiFi and assign it as a child of the wired location. This setup ensures the wireless Location retrieves content from its parent.
{% endhint %}

### Default

* Defines a standard wired Local Area Network (LAN).
* ALL subnets at this physical location should be combined into a single Location.
* When a client needs a piece of content, it sends a broadcast request to the network. Any device with the requested content on the network responds directly to the client.
* Optimized for on-premises offices with wired LAN connections, offering a straightforward solution for content discovery and sharing in a secure and controlled network.
* **Example:** Central or regional headquarters office with wired connections.

### WiFi

* Defines a Location and IP range or ranges allocated to clients connected over WiFi.
* Uses unicast instead of broadcast to communicate between devices on the same subnet.
* When a client needs a piece of content, it sends out a direct unicast message to all known peers within the same WiFi office. Each peer that holds the requested content responds directly to the client.
* Particularly effective in on-premises offices with WiFi connectivity. It's an ideal choice in scenarios where broadcast traffic is inefficient or not permitted due to network policies.
* **Example:** Wireless network at an office which end-user devices will connect to. It is recommended that wireless networks be defined as a child Location to a wired network in the same physical location.

### VPN

* Defines a Location and IP range allocated to clients connecting with a VPN.
* Does not use peer-to-peer communication and only pulls content from the Parent Location.
* It is recommended that **ALL** VPN subnets from a given concentrator be combined in a single Location.
* Specifically intended for scenarios where clients are connecting from various locations, such as different cities or countries. By centralizing content requests to the parent office, it avoids the inefficiencies and potential impacts of attempting peer-to-peer transfers over long distances. This makes it particularly suitable for organizations with a distributed workforce, where direct content sharing between remote locations could lead to significant network load and latency issues.

  Can also be used to address other use cases where peer-to-peer data transfer between clients should be avoided.
* **Example:** Subnet devices are assigned addresses from when connected to the company VPN.

## Content Discovery Networks

When content is not available on any devices in your system, the content must be downloaded directly from the major Content Discovery Networks (CDNs) (Adaptiva, Microsoft, OEM vendors, etc.) via the internet.

This typically happens in the root Location, the **Central office**, but you can configure any Location with direct internet access to be able to download content directly from the CDNs by enabling the **Allow Direct CDN Download** setting.

## Location hierarchies

Setting up your location hierarchy properly is vital to ensure efficient communication and content distribution among devices.

When a device needs content, it attempts to find the content in the following order:

1. Ask other devices in the Location for the content. This does not apply to VPN Locations.
2. If the Location is configured for direct CDN downloads, attempt to download the content directly via the internet.
3. Request content from the parent Location.

This process repeats until the content is found. If no devices have the content, then eventually the request will reach the root location, the Central office, which will download the content directly from the CDNs.

The content is then distributed back down through the Location chain to the requesting device.

## Example scenario

The following scenario defines twelve office Locations: a Central Office and eleven additional offices A through K, as shown in the following image:

![Table view of office locations](https://1238239958-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FzBcNZqjCKqgdpA83eD4o%2Fuploads%2Fgit-blob-1684fc33303db7a4675cc4da4fd36becfa454ba3%2Flocation-table.png?alt=media)

Note that Office B and Office E include **CDN** in their **Type**. This means that those Locations have been configured to allow them to directly download content directly from the major CDNs via the internet, instead of requesting content from their parent Location.

### Flat hierarchy content flow

In a flat hierarchy, all offices are nested directly below the **Central office**, as seen in the following image:

![flat hierarchy](https://1238239958-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FzBcNZqjCKqgdpA83eD4o%2Fuploads%2Fgit-blob-34b76f22cebdaa7663278d3d8bdb5ca4577f3953%2Flocation-flat-hierarchy.png?alt=media)

Any office configured as **VPN** will obtain content directly from an elected device in the **Central office**.

Any office configured as **Default** or **WiFi** will first perform discovery within their local office. If the content is not found in that office, they obtain the content from the **Central office**.

If the content being requested is published to the Content Discovery Network (CDN) and is not available in their local office, any office that is enabled for direct CDN download (**Offices B** and **E**) will attempt to download the content directly from the CDN instead of requesting it from the **Central office**.

### Nested hierarchy content flow

In the following nested hierarchy, **Offices A, E, F, G,** and **H** are nested directly below the **Central office**. **Offices B, C,** and **D** are nested under **Office A,** and **Offices I, J,** and **K** are nested under **Office F:**

![nested hierarchy](https://1238239958-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FzBcNZqjCKqgdpA83eD4o%2Fuploads%2Fgit-blob-a0a3c5d1c026da81d878f98929cd4aa446714d11%2Flocation-nested-hierarchy.png?alt=media)

#### Office A

Content discovery is performed locally using the default LAN protocol. If content cannot be found, it will be downloaded from a source in the **Central office.**

#### Offices B and C

Content discovery is performed locally using the WiFi protocol. If content cannot be found, **Office C** will download from a source in **Office A,** while **Office B** will attempt to download the content from the CDN if available, otherwise **Office B** will also download from **Office A.** If no source is available in **Office A,** a client in **Office A** will be elected to download the content from the **Central office** and fan it out to two additional sources in the requesting office.

#### Office D

As this office is configured as **VPN,** no local discovery is performed. Content will be downloaded directly from a source in **Office A.** If no source is available in **Office A,** a client in **Office A** will be elected to download the content from the **Central office** and then provide it to the VPN client.

#### Office E

**Office E** is configured as a **Default** office with direct CDN download enabled. If the content being requested has been published to the CDN, it will be downloaded directly from the CDN. If the content is not CDN content, it will be downloaded from a source in the **Central office.**

#### Office F

Content discovery is performed locally using the default LAN protocol. If content cannot be found, it will be downloaded from a source in the **Central office.**

#### Office G

As this office is configured as **VPN**, no local discovery is performed. Content will be downloaded directly from a source in the **Central office.**

#### Office H

Content discovery is performed locally using the WiFi protocol. If content cannot be found, it will be downloaded from a source in the **Central office** and fanned out to two additional sources in **Office H.**

#### Offices I, J, and K

Content discovery is performed locally using the default LAN protocol. If content cannot be found, it will be downloaded from a source in **Office F.** If content cannot be found, it will be downloaded from a source in **Office F.** If no source is available in **Office F,** a client in **Office F** will be elected to download the content from the **Central office** and fan it out to two additional sources in the requesting office.