StifleR
2.6
2.6
  • Start Here - StifleR 2.6
  • StifleR 2.6.x.x
    • StifleR - Release Notes
    • What's New
    • QuickStart Guide
      • Installation
        • Manual Server Installation
        • StifleR Client Installation
        • StifleR Network Locations
        • Example StifleR Rules Definition
    • Planning & Deployment Guide
      • TL;DR version
      • StifleR Overview
        • The StifleR Solution
      • Features Overview
        • Other Features
      • Technical Overview
        • StifleR Standard Features
        • StifleR Enterprise Features
      • Planning Your StifleR Implementation
        • Firewall Ports
        • Supported Clients
        • Networks in StifleR
        • Permissions
      • Installation
        • StifleR Server Installation
        • Dashboards, Client and Beacon Server Installation
        • Post Installation Checks
        • Testing Quick Start Guide
      • Troubleshooting
        • BranchCache across Subnets
      • StifleR Generic Concepts
        • Red Leader
        • Enterprise Environment - Blue Leader
      • Bandwidth Management
        • Bandwidth Tuning Monitoring and Control
      • StifleR WMI Provider
      • StifleR Feature Details
        • StifleR Enterprise Edition Features
      • Further Reading
    • StifleR Operations
      • Maintenance tasks
      • Backup and Recovery
        • Moving the StifleR Server Databases to a New Drive on the Same Server
    • StifleRulez.xml Configuration Guide
      • The Match – TypeData
        • When the Job Title Isn’t Suitable
        • ConfigMgr Specific Rules
      • The Setting - DownloadTypes
        • Delivery Optimization Jobs
      • Sample StifleRulez.xml
    • Securing StifleR Operations with SSL
      • Pre-Requisites
      • Securing the StifleR SignalR Endpoint
        • Binding certificates to SSL Ports for SignalR/StifleR
      • Running SignalR with SSL
      • IIS Configuration
      • Appendix A: Certificates
        • Using IIS to create a self-signed Certificate
        • Using a full IIS Certificate
      • Appendix B:Finding the CertHash
Powered by GitBook
On this page
Export as PDF
  1. StifleR 2.6.x.x
  2. Planning & Deployment Guide
  3. StifleR Overview

The StifleR Solution

How we work alongside Microsoft P2P, Downloading and Caching Technology

At 2Pint Software we noticed that although the various P2P technologies are awesome at what they do, there were some obvious areas for improvement. Firstly, the manner in which the content is downloaded (bandwidth control) and secondly, how many machines actually need to download that content from remote data sources onto the local site or subnet before sharing it at the local level. (Single Site Download)

Bandwidth Control

Microsoft P2P solutions use several delivery protocols which by default are difficult to control at a granular level. Taking BITS (BranchCache) as an example: An Administrator can set maximum bandwidth usage for various BITS job priorities but those priorities can only to be set at a very high level and over a wide variety of distribution types which may not necessarily align with your Network or Management requirements. In the case of User initiated Configuration Manager Jobs, control is virtually removed entirely and these are automatically set to Foreground Priority (use all available bandwidth) which has no respect for Bandwidth Limits and will push other (possibly more important) jobs down the queue. The StifleR client agent returns control and allows an Administrator to set priority levels for content download down to specific job types and delivers the ability to centrally adjust and tweak those settings down to an individual job level.

But Job Priority is just half the challenge. The Job Priority settings only enable an Administrator to set a maximum bandwidth level for a download (which unmanaged clients will use if unchecked). If all clients are trying to download content from a remote data centre over a low bandwidth connection, it doesn’t take long for the expensive WAN link to become congested and for your users to start suffering a loss of production data.

StifleR to the rescue! Not only does StifleR allow you to set the priority, and therefore the bandwidth available to a certain content transfer, it also monitors latency during a download and will dynamically adjust the download transfer rate up or down in order to keep the bandwidth usage within configurable QoS limits and allow business critical data to flow without interruption.

Single Site Download

Controlling the bandwidth consumed by your individual clients when they are downloading content is fine to a point but if there are a large number of clients that all need to download content at same time then the sheer weight of numbers can quickly overwhelm a highly utilised link.

StifleR provides a solution to this problem through the concept of the Red and Blue leaders. There’s a lot more about this later on in this document but, in a nutshell, it works by the most suitable client in a subnet being dynamically appointed to be the only client for that location to download the content from the remote source. This “Leader” client alone is allowed to make full use of the priority bandwidth for the download thus delivering the content to the local network in the quickest time. The other clients will throttle down and wait for the content to be available. Once the content has been downloaded to the “Red Leader” client on the local network, Microsoft P2P bandwidth accelerating caching technologies enable that content to be shared efficiently with other clients on the LAN, leaving the WAN link clear for your business critical production traffic.

In StifleR Enterprise, this concept is further enhanced and expanded to the Site level with the introduction of Blue Leaders. Blue Leaders communicate with each other over Subnet boundaries. They pick up local broadcast discovery requests and pass these on to other Blue Leaders which can then rebroadcast those messages onto their local network thus allowing the sharing of content with and between all the clients at a multi subnet location. The end result of this infrastructure is that content may be downloaded once over the WAN for an entire remote site with that content then shared directly between Peers on the well connected LAN.

PreviousStifleR OverviewNextFeatures Overview

Last updated 2 years ago