# Network topology Proper implementation of your network topology in the OneSite platform is a crucial part of the operation of any OneSite solution like Patch or Anywhere. To get the most our of OneSite's peer-to-peer content sharing, you will need to group clients into accurate Locations based on their network and IP ranges. Clients in the same Location will discover and download content from their peers in the local network rather than individually downloading content from the Internet. The goal of an optimized topology is: * Minimize WAN usage * Maximize local, LAN-based peer-to-peer sharing. * Ensure fast, reliable content delivery. * Reflect your physical network topology of your environment. This guide explains the key concepts, how topology influences content flow, and the built in features used by Location types. If you would like to import your network topology from a spreadsheet, please see our [Import your network topology](/platform-guide/platform-management/network-topology/network-topology-import.md) page. ## Locations Locations are the building blocks of defining your network topology. A Location is defined by one or more IP ranges intended to identify machines that are connected over a LAN. Locations should be defined for any IP ranges that are separated by a WAN link to ensure accurate content routing and optimal peer-to-peer behavior. There are three distinct Location types: * Default * WiFi * VPN For more information regarding Locations and their types, please see our [Locations](https://docs.adaptiva.com/platform-guide/platform-features/locations) page. ### Central location After installing your Adaptiva server, a Central Office will be automatically generated. This is the top-level Location and contains the Content Library, ensuring content is always available here. All devices ultimately fall back to the Central Office for content if no other peer or parent Location has it, which we'll discuss more in the [Content flow](#content-flow) section below. ### Auto locations When a client registers with the server for the first time, it is going to send its IP address and subnet mask. The server will then determine if it is a known IP range and add it to the appropriate Location. If the client IP is in an unknown IP range, Adaptiva automatically generates an Auto-Location named `Auto`. By default, these Auto locations will be under the Central Office. For more information regarding Auto Location setup please see our [Auto-Location](https://docs.adaptiva.com/platform-guide/platform-management/network-topology/on-premises-client-detection#enabling-auto-location-creation) page. ![](/files/h1jez0aZipLJGE9UW0D3) While functional, Auto-Locations often produce: * Too many small Locations that may actually be in the same physical location or LAN. * Inefficient content routing since it will always route back to the Central Office, even though another Location may be physically closer. To fix this we want to set up our network typology from both a physical network standpoint as well as a logical network standpoint. To do so, we can [create our own custom Locations](https://docs.adaptiva.com/platform-guide/platform-features/locations#creating-a-new-location) which should look more akin to the image below depending on your own physical network of each Location that you may have. ![](/files/2oS2T2JL2gOmA0wwqDZM) {% hint style="info" %} For SaaS customers, the network topology will be set up in much of the same way, however, you'll be able to access the Admin Portal from any device anywhere, as the Central Office and server will be located in the cloud. {% endhint %} ## Content flow The main goal of the network topology is to minimize WAN usage and maximize LAN-based peer-to-peer sharing. At each Location, elections are automatically held to choose a designated device per location that communicates and controls the flow of content. This ensures: * Content is only transferred once from a parent to a child office, reducing WAN traffic. * Clients detect and send content locally whenever possible. ### Rendezvous Points (RVPs) and elections During elections each client device self-evaluates things like: * CPU utilization * RAM * Operating system * Whether it is a desktop, laptop, or tablet The client then volunteers itself as the RVP (Rendezvous Point), and then all client devices are evaluated and the best candidate is chosen as the RVP. This entire process is automated and you can see which devices are RVPs from the Devices tab from **Assets** > **Devices** on the OneSite Admin Portal. ![](/files/xOUs73gN3xS9SVL3HAa9) RVPs are responsible for: * Managing content flow - essentially a traffic cop that dictates which clients can proceed with content downloads based on priority. * Communicating with RVPs in parent and child Locations - content discovery if content is not located in the RVP's subnet. * Coordinating peer discovery - finds new peers and adds to a table in memory. ### Content search Once the RVP is established and a client's policy requests content, the client will proceeds to search in a particular order. Below is a content search from the network topology diagram example above. 1. Local * The Client device checks itself to see if it has the specific content already. * Houston WiFi Location client. 2. Subnet * The Client then asks other peers on the same subnet to find the specific content. * Houston WiFi Location client. 3. Location * The client asks the RVP of its subnet to reach out to the other RVPs at the same Location. * RVP from Houston WiFi Location asks RVP from Houston Location. 4. Parent * The RVP then asks the Parent RVP to find the specific content. * RVP from Houston WiFi Location asks RVP from America DC. 5. Central Location * If it still not found, the RVP will ask the Central Office. * RVP fro Houston WiFi asks RVP from Central Office. ![](/files/6OGBo7KfY7Mw9SM297bV) {% hint style="info" %} Locations can be configured to download directly from the internet-based Content Delivery Network (CDN) if desired. This can be done during the creation or modification of a Location by toggling on **Allow Direct CDN Download**. Please see our [Location settings and actions](https://github.com/AdaptivaDocs/docs/blob/main/platform/user-guide/location-settings-actions.md) page. {% endhint %} ## OneSite protocols Adaptiva offers two proprietary protocols that optimize the delivery of content between Locations: * **Adaptive Background Transport** - Used **between** Locations * **Adaptive Foreground Transport protocol** - Used **within** Locations {% hint style="warning" %} Misconfigured offices can lead to: * Foreground protocol used over WAN which will result in WAN saturation. * Background protocol used over LAN which will cause slower distribution of content. {% endhint %} ### Background Adaptive Transport The Background Adaptive Transport protocol is going to ensure that we can get our content across quickly without impacting other business traffic. This protocol is going to be used every time you are transferring over a WAN link ***between*** Locations, both on-premises as well as over the internet. This mechanism is one of the core advantages of the OneSite Platform, enabling efficient and non-disruptive data transfers even on congested networks. #### Quality of Service (QoS) Considerations When using the OneSite platform, you'll want to optimize how the Background Adaptive Transport operates on your network. If QoS artificially prioritizes OneSite traffic (e.g., assigning it a high-priority or reserved class), it can interfere with the optimal functionality of this protocol. The following issues can occur: * Unintended congestion or latency for other critical applications. * Reduced performance of OneSite, as the protocol cannot respond accurately to network conditions. * Intelligent bandwidth control does not function properly. **Implementation best practices** If your organization mandates QoS controls across all network traffic, implement the following best practices: * Identify OneSite traffic via ports. The bandwidth harvesting and background protocol uses UDP port 34750, and the foreground protocol uses UDP port 34760. * Assign OneSite traffic to the lowest priority class (scavenger or default). * Ensure it is not marked with high-priority or reserved-bandwidth tags. This ensures that OneSite operates as expected, intelligently yielding more critical traffic while optimizing OneSite transfer rates in real time. ### Background Adaptive Transport Features Below are the features that are included with this protocol. #### Predictive Bandwidth Harvesting The Predictive Bandwidth Harvesting feature, predicts future network conditions to optimize software delivery without throttling the bandwidth. This speeds up or slows down the content delivery where appropriate to not interfere with normal business traffic. #### NetBoost NetBoost helps us guarantee network responsiveness when the cause for slowdowns is not related to bandwidth. #### Flow Equalizer This feature protects the WAN by proactively leveling out traffic when multiple downloads occur at once. ### Foreground Adaptive Transport The Foreground Adaptive Transport protocol is used whenever we are communicating ***within*** a Location of one or more subnets. It effectively transports data across the network in the fastest and most effective manner possible. ### Foreground Adaptive Transport Features Below are the features that are included with this protocol. #### Memory pipeline architecture This feature delivers data quickly to peer systems on the LAN without impacting the end users. ## Summary A well-designed network topology in the OneSite Platform ensures efficient, reliable, and LAN-optimized content delivery. By defining accurate Locations, establishing clear parent–child hierarchies, and relying on RVP-driven content flow supported by Adaptiva’s Adaptive Transport protocols, these components work together to significantly reduce WAN utilization and streamline high-performance, LAN-based peer-to-peer content delivery. ### Key takeaways * Build accurate Locations that reflect real network boundaries and consolidate unnecessary Auto-Locations * Define a logical parent–child hierarchy so content flows from the Central Office downward efficiently * RVPs coordinate peer discovery and content searches across subnet, Location, parent, and Central Office layers * Background and Foreground Adaptive Transport protocols optimize performance while protecting WAN and LAN traffic ## Related pages [Locations](/platform-guide/platform-features/locations.md) [Groups](/platform-guide/platform-features/assets/groups.md) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.adaptiva.com/platform-guide/platform-management/network-topology.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.