Executive Summary

What Does It Do?

StifleR optimises WAN Bandwidth usage and ensures that your Users and Workstations obtain the content that they need from a source local to them in the most efficient way possible, while protecting network bandwidth, prioritizing traffic, and giving real-time visibility and control over your Software Distributions through the StifleR Dashboards.

Why Do You Need It?

‘StifleR – How to be the Network team’s best friend in 5 minutes or less’

Would you get onto an airplane knowing that Air Traffic Control Radar wasn’t working? Of course not! Without StifleR your WAN and LAN traffic is ‘flying blind’ with little control over speed or priority. Without monitoring or control, how do you know if your Users aren’t choking the corporate network, downloading or streaming mundane or personal content and blocking high priority business traffic such as your Point-of-Sale data or critical Windows Updates? StifleR delivers the ability to centrally monitor and dynamically control these data streams.

StifleR-assisted content delivery quickly decreases the bandwidth load on your network. The greater the number of StifleR enabled clients across an enterprise, the more efficient content delivery becomes.

How It Works – The Overview From 10,000 Feet

Microsoft clearly sees P2P as the future of content delivery and so should you!

StifleR has been built around the awesome Microsoft Content Distribution and Peer to Peer Caching technologies that are now an integral part of Microsoft’s preferred delivery solutions. BranchCache is the mature WAN Accelerator that’s been built into the Windows operating systems for over 7 years. In Windows 10, StifleR gives you the power to manage Delivery Optimization (DO) which is now the download and cache engine of choice for that platform and for Microsoft distributed content in general. SifleR also manages and enhances the performance of Microsoft Configuration Manager Client Peer Cache which is the solution specifically designed for CM content delivery. Now with Windows Server 2016, StifleR gives you control and visibility over Microsoft’s latency optimized, network congestion control provider called LEDBAT, which stands for Low Extra Delay Background Transfer. LEDBAT is designed to automatically yield bandwidth to users and applications, but is able to utilise the entire bandwidth available and allocate any extra to background services.

StifleR is built on Microsoft’s SignalR which is a massively scalable lightweight platform for real-time network wide communications which enables up to the moment monitoring and end point control between Servers and consumers.

By uniting and giving you control over these various technologies we built a solution that can pamper, whittle, slice and dice your content delivery from the CEO’s Surface Book all the way to the remotest of remote Locations. You have full control and visibility over Windows Updates, Applications, Office files, CM Content even your users personal content streaming, all in real time.

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.

Content Accelerator

StifleR accelerates content transfers by utilizing the various Microsoft P2P services, enabling caching, Deduplication and Peer-to-Peer distribution of content on local networks. By utilizing and improving the Microsoft P2P functionality, StifleR has a profound effect on where users actually source their content, the network bandwidth consumed in retrieving that content and the speed with which the content is delivered to consumers.

Bandwidth Control

StifleR gives you control over content transfers to Windows client computers by enabling granular configuration of the Background Intelligent Transfer (BITS) and/or Delivery Optimization (DO). Services not natively available.

Bandwidth Sharing

As the Red Leaders are continuously communicating download details back to the StifleR Server, the Server is aware of how many active subnets transferring data there are at any moment in time. At a remote location the allowed Bandwidth between the Location and the Datacentre is dynamically apportioned between the number of active Red Leaders (Subnets) at that Location allowing maximum bandwidth to be assigned to each at all times.

Visibility and Control Through the StifleR Dashboards

Real Time Monitoring Reporting and Visibility

Using StifleR you have complete visibility over WAN and LAN transfers globally through the Dashboards. The Dashboards update several times per second thus giving an up to the second view of content transfers. The SignalR architecture also allows you to have as many dashboards open as you like without putting a strain on the server infrastructure.

The dashboards allow real time monitoring of all content transfers within the enterprise, all from a single view. From the main dashboard you can then drill down from a multi subnet Site through individual subnets right down to single client data.

StifleR tracks all content being downloaded on the clients and reports this data back to the StifleR server. All this data is then made available for reporting on the StifleR server directly in WMI or graphically through the Dashboards interface. StifleR will give you a view of all active and queued downloads at a given Location. A BITS client only supports a single active download at a time and therefore it is on this that StifleR reports and sends data.

Administrative Control via the StifleR Dashboards

Server Configuration

Server settings can be configured through the ‘Server Settings’ dashboard

Subnet Configuration

Subnet level settings can be set via the Subnet dashboard, including TargetBandwidth/Well Connected/Address etc.

Locations Configuration

Further to the Subnet settings above, you can also set Delivery Optimization parameters such as GroupID and Download mode, LEDBAT Target Bandwidth and Well Connected Bandwidth limits

Job Management

Within the BITS and DO job dashboards, StifleR gives you the ability to Stop, Start, Pause or change the priority of individual job downloads with a simple click of the mouse. These controls are instant and can be used to control traffic at all levels of the infrastructure.

Administrators Security

Global Administrators have the ability to grant granular administrative control to Delegated Administrators over StifleR resources all through the Dashboard interface. A Deputy Administrator can be granted the ability to monitor and set controls for particular subnets only. They are granted security access to the WMI methods and controls for the subnet.

Automation and Efficiency

While the Dashboard interface can be used for small scale manual configuration and control, for serious, Enterprise wide automated administration StifleR can be configured via Microsoft PowerShell or WMIC scripting which interacts with the StifleR Windows Management Instrumentation (WMI) Namespace. There are limitless possibilities in this regard. For some examples and inspiration to get you started head over to the 2Pint Software KB site "StifleR - WMI, Scripts And Commands".

We also recommend that you read through the StifleRServerScriptingGuidance.ps1 script in the StifleR Server Installation folder which contains numerous handy code snippets to help with various administrative tasks.

Change Content Delivery Priorities

StifleR is designed to enable configuration and control over the static priority of different content types and allows you to change the priority of a job immediately using WMI. You can change the job priority in several different ways, depending on what you want to achieve:

1. Pause a running higher priority job in order to allow the next job in line to start. The original job can then be resumed once the other has completed.

2. Make changes centrally to the StifleR download job definition file (stiflerulez.xml) and push this to clients instantly via StifleR. e.g. change one type of BITS job to a higher priority to get certain content distributed ahead of existing traffic.

Changes to the bandwidth and priorities directly using WMI (or through the Dashboard) replicates settings within seconds, regardless of how many Locations you have targeted.

Multilane Transfer

Intelligent Bandwidth Sharing between active Devices

StifleR also allows for multilane transfers, i.e. multiple transfers at the same time. Using a combination of the locally cached BranchCache content and Data Deduplication, transfers can be allowed that put none, or very little, traffic on the WAN as most of the content is actually present already and it is only the balance of content that needs transferring. Here’s a scenario to help your understanding of how this works in the real world: -

A client at a remote location starts to download content. At the same time another peer at that same remote Location needs to download & install an updated version of the same content. Because of Windows Deduplication, a large percentage of the content is not required to be transferred over the WAN. Instead of waiting for the complete local data to become available the StifleR client on the second Peer will allow the download to go ahead, at the same priority as the existing download but at reduced bandwidth. This allows the peer to slowly download the content, which, due to De-Dupe, may be enough to get the installation started faster as most of the content will be sourced from the local caches and only a trivial amount coming over the WAN.

Summary

StifleR empowers you to re-prioritize content delivery quickly and non-destructively (without killing jobs). When you change content priorities, any paused content automatically resumes after the new higher priority content transfer completes, without retransmitting data already downloaded. You can specify job priority and also allow jobs to run side by side while using appropriate bandwidth in proportion to the job needs. StifleR also has the ability to monitor and adjust bandwidth usage up or down according to set limits. StifleR makes it easy to view, configure and manage all content priority changes and to monitor content transfer in real time.

Pause and Resume

An important function utilized by StifleR, which should already be healthy in your Software Distribution solution, is automatic pause and resume. This is the control that sets the ability to move something to the top of the queue, causing the currently active item to pause immediately. Later, when the urgent content finishes downloading, BITS will resume the interrupted download exactly where it left off without missing a byte and without re-transmitting data already downloaded. The healthy state of this function in the enterprise should be considered a pre-requisite for StifleR operation.

Stop and Resume

In some exceptional circumstances you may need to completely stop traffic from transmitting over the WAN.

Stopping every BITS job in the entire Enterprise is as easy as a click in the Dashboard or a single WMI command line:

-ArgumentList "Suspend", False, "*", 0, "ALL" 

StifleR uses the default BITS API commands so an administrator can just as easily Suspend, Resume, Cancel or Complete jobs.

By changing the argument list around a little, you can do some powerful stuff. If we change the “ALL” to an IP Network ID we can target resources in a more granular manner:

-ArgumentList "Suspend", False, "*", 0, "192.168.137.0"

If true pause/resume is important to your organization, then it’s important to understand why this is unique. You can instantly pause content transfer non-destructively (without killing jobs) anywhere in your enterprise, and later resume exactly where it left off. There is no limit to the scope:

• For delivery of a single piece of content

• For all content delivery to a single Location or subnet

• For all content delivery globally

By using PowerShell or any other WMI aware scripting language you can easily pipe objects to each other. For example, you can select a Location where bandwidth usage is too high and then suspend all jobs temporarily as required. Once again, refer to the scripting guide for examples and ideas in this regard.

BranchCache V2-V1 Auto Detection

StifleR is able to detect that you have a mixture of BranchCache V2 and V1 computers in your environment and automatically assign the V2 machines to become Red Leaders. V2 computers are able to generate hashed data for both V1 and V2 clients. Unlike V1 machines however, V2 machines are able to utilize deduplication on the download side which greatly speeds up the overall transfer time for the V1 clients. For more information on BranchCache version interoperation please visit the 2Pint website.

Inter VLAN P2P

At Locations with multiple VLANs or Subnets StifleR Blue Leaders are assigned. These clients are able to act as BranchCache communication proxies and allow P2P traffic to cross network boundaries. In larger locations with limited WAN connectivity back to the data centre this feature is invaluable in order to limit WAN usage as far as possible.

Command Line Execution

Using the command line execution feature you can easily run commands across many systems at one time.

PowerShell Everywhere!

Same as the Command Line execution, but with PowerShell scripts on Clients instead. Each script is distributed to the client and executed.

Create Your Own BITS Downloads

StifleR not only monitors BITS downloads, it can create them too. Here’s a couple of suggestions for usage of this feature:–

• Download the ‘top 10’ most accessed files from your corporate intranet into the BranchCache cache overnight

• Seed (pre stage) certain key systems in remote Locations with Software Updates that can then be shared via BranchCache

Wake-On-LAN

StifleR has Wake-on-LAN technology built in which may be used to power on systems in a Location that hold cached content that are needed by Peer clients. This saves bandwidth and time as the transfer becomes P2P instead of WAN based.

Server and Client

StifleR consists of two main parts. The StifleR server component and the StifleR clients.

Each StifleR client makes a lightweight connection to the StifleR server and sends up information about the current content download queue. This information is evaluated and the server (dynamically) assigns the most suitable system per Location to be the “Red Leader”. The Red Leader system is then responsible for downloading content and obeying the defined network bandwidth limits for that Location. Other clients at that same Location, that would otherwise also download the content from the remote source, will not download from the remote location but instead will throttle down, wait, and then copy the data locally from the Red Leader and other Peers using Microsoft P2P transfer functions. The end result is that rather than all clients downloading remote content, WAN traffic is limited to between the single Red Leader and the remote content server. Should the current Red Leader system become unavailable, a new Red Leader is automatically selected, which results in uninterrupted, efficient and dynamic workflow.

This functionality also extends to Windows 10 Delivery Optimization groups and respects the Bandwidth administrative settings present under any DO control policy that may be in place.

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 broadcast these messages onto their local segment 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 is downloaded only once over the WAN for an entire remote site with that content then shared directly between Peers on the well connected LAN.

Bandwidth Measurement - Beacon Server

The StifleR Beacon Server component is installed at your file server locations. These then act as known end points to allow the StifleR clients to benchmark bandwidth parameters and set and tune limits accordingly.

SignalR Communication

StifleR is a typical Client – Server application that uses bi-directional communication channels. The Server hosts an OWIN (Open Web Interface for .NET) implementation of Microsoft SignalR. All communication is based on the Microsoft the Microsoft SignalR protocol, a web-sockets based protocol that runs over UDP, initiated first through an HTTP connection which then steps things up to web sockets. StifleR server also uses SignalR to communicate with the endpoint clients and any connected dashboards. Understanding how SignalR works is not mandatory to use StifleR but is required if custom scripting or advanced configuration of StifleR is to be undertaken. Please refer to the 2PintSoftware Website for advanced information on the Microsoft SignalR platform including “SignalR and Connection Management” on the Knowledge Base and the companion document to this guide “Securing StifleR Operations Using SSL” which includes SignalR configuration.

StifleR Rules

The StifleR client checks through its queue of active downloads (both BITS and DO) and then prioritizes them according to a locally held XML configuration file (StifleRulez.xml) which contains a set of rules that are configured centrally by the administrator and automatically downloaded by the clients.

This file contains a simple rule set that defines the content download jobs and the priority that the administrator has assigned to each job type.

As an example, Microsoft Maps sync could be set to a low priority, while Windows Update patches would be set to high. Using this rule set, you can effectively control which downloads should be completed ahead of others. All of these configuration settings can be changed centrally at any time with any such changes automatically replicated to your clients in seconds.

Security

Communication Channels

In order to secure the SignalR communication channels in StifleR we recommend that you use SSL. A full explanation of this can be found in the companion document “Securing StifleR Operations Using SSL”

User Administrative Access

StifleR uses a delegated security model in both WMI and the Web portal. There are several basic security levels:

Global Administrators (Mandatory)

• Access to all locations and WMI regardless of location rights

• Only Global Administrators have rights and visibility over roaming clients

Delegated Access

• Granted by a Global Administrator on the individual Subnet level. Rights to WMI methods only on the allowed subnet or clients in that subnet

Global Read

• Gives read only rights to ALL locations and statistics. Including WMI

Dashboard Access

• Access to Dashboard and overview statistics only

Anonymous Read

• Allows anonymous access. Should be disabled in all but a test environment

Hardware

If the client hardware can run Windows, it can run the StifleR Client. CPU & Memory utilization is very low.

Software Requirements

Pre-requisite

• Windows 7 SP1 or later

• Supported are x86 or x64 versions of the operating systems

  • Professional, Enterprise or Ultimate versions

  • Newer Educational SKU is also supported

• Microsoft .NET 4.7.2 must be installed on the client

The client is a .NET 4.7.2 executable with some C++ helper DLLs. It will run on any operating system that is capable of running .NET 4.7.2 and BranchCache. This includes most operating systems from Windows 7 and above with the exceptions of Home and other consumer versions of Windows.

Hotfixes for Windows 7 - BITS might ignore the throttling policy and consume the WAN circuits in Windows 7 SP1 or Windows Server 2008 R2 SP1 (not required but fixes a bug within BITS that can cause it to ignore Bandwidth Policy)

Mode of Operation

The StifleR Client can be installed in one of three modes:

1. Windows Service Based Mode – always connected to the StifleR Server, running as a Windows Service

2. Event Triggered Mode – only starts & connects when a download job is created and running

3. Read Only Mode

Windows Service Based Mode

The benefit of Service Mode is that the Administrator can send configuration changes to the Client immediately at any time. This does not happen in the Event Driven mode as the client is only active when a download job is run and the client will only receive configuration changes at start up.

When running as a service, the StifleR client runs as a Windows Service and monitors job creation every few seconds according to the configured interval.

Event Triggered Mode (Advanced Only)

The client is not always running in this mode lowering utilization on both client and server. This however means that the server cannot reliably perform certain configuration tasks on the client in real time.

When the StifleR client is event driven it is triggered by the Windows ETW (Event Tracking for Windows) system using a Scheduled Task that launches the StifleR Client on BITS Event ID 3 (BITS Job created). Once all queued BITS jobs have completed, the Client exits out.

The reason that Event Driven mode was first written into the product was to cater for a situation where a customer may deploy your content in ’Maintenance Windows’ within set times during offpeak hours for instance and may not want the service running outside these hours. We have not seen any requirement for this in real world usage and accordingly this mode should be considered for advanced use only.

Read Only Mode

This mode requires separate licensing. It is a limited version only for network monitoring and dashboard visibility.

StifleR Client on Windows Server

The StifleR client can be run on a Windows Server system where, for example, you may want to monitor the Bandwidth performance of an SCCM Pull Distribution Point. In order to do this you must edit the following line into the StifleR.ClientApp.exe.config file and restart the StifleR service:

<add key="UseServerAsClient" value="1" />

Once the Service has been restarted, the server can be monitored like any other client. NB: It will not appear in the ‘Servers’ dashboard.

StifleR Ports

The following (client) ports are used for the InterVLAN feature (see later). An asterisk (*) indicates a dynamic Port number. BranchCache tries to use a random port among the dynamic port range (49152-65535) as specified in RFC6335 section 6. Port Number Ranges:

Server – Client Communication

• Source – dynamic

• Destination – Port 1414 TCP/IP & Port 1414 UDP for Web Sockets

Web Server - Dashboards

• Source - dynamic

• Port 9000 is used by server to host the dashboard/data API. Dashboard uses it to connect to the REST API to get data

• Port 80 - dashboards

Beacon Server Port

• For clients to send iperf packets – Server TCP 5201

Planning for integrating StifleR into your Content Distribution System is simple. Like most technical projects however, preparation and attention to details pays dividends.

Server

Location

Location of the StifleR server should be considered although it is not too critical unless you have multiple geographical locations etc. in which case you may consider having multiple StifleR servers at key hub locations. More important is the spec of the server and its Network connectivity. Bear in mind that the server will have incoming and outgoing connections to all StifleR clients – sometimes all at once during a large scheduled deployment.

Hardware

The following table can be used as a summarized view of the hardware requirements.

CPU

StifleR is CPU intensive. Since StifleR does not use that many threads, a higher frequency (Ghz) is recommended. We recommend at least a 2.4Ghz processor with 8 cores. Don’t forget that most CPU’s must also handle some of the Network connectivity management.

Memory

StifleR writes a lot of historical data to databases, as well as maintaining in-RAM memory objects. Since each connection and all connection data is stored in RAM a decent size of RAM is recommended but 32GB should be plenty for most installations.

Disk

StifleR saves a lot of information to ESENT databases, especially with the System Resource Tracking features enabled. Fast SSD disks are preferred for housing these Databases.

Network Connectivity

Each client has a non-managed SignalR client connection (web sockets) to the server, so if you want to run 100k clients to a single server you need to beef up the network connectivity.

If you are supporting a large number of clients, you probably want dual or quad 10Gb/s NIC’s for your StifleR server. This will ensure that the NIC’s have enough power to manage the large number of connections.

Software

StifleR server requires Windows Server 2012 with Microsoft .NET version 4.7.2 or higher. If you wish to run StifleR on Windows server 2008 contact us first for a chat.

There are also requirements around IIS settings. Please refer to the Dashboard installation section for important information in this regard.

Redundancy

Multiple StifleR servers can be configured for larger enterprises so that clients can fail-over to a second server should the primary server become unavailable.

Large Enterprise Considerations

For larger installations we recommend splitting the load across several StifleR servers. For example one server per geographical region.

Beacon Server

The server-side component (iperf3.exe) can run on any Windows OS (talk to us if you want to run it on Linux) It acts as the end point to which the StifleR Client Red Leaders send test packets. This allows the Red Leaders to accurately measure the maximum bandwidth available between the a Subnet/Location and the content source. Typically, you will install this component on a server in a central location (such as an SCCM Distribution Point) from which your clients obtain the bulk of their content. If you have a central datacenter for instance you can simply install the StifleR Beacon service onto any server at that location. The StifleR Beacon Service may be installed on the StifleR Server if required but there is no dependency on this configuration.

HTTP v HTTPS

We recommend that http communication channels only be used in your initial high level testing. In a production environment we strongly recommend that you configure StifleR communication to be secured over https. For more information on SSL configuration, and all things certificate related, please refer to the companion document “Securing StifleR operations using SSL” which gives an overview of not only the StifleR and SignalR configuration but also how to set up the underlying Configuration Manager security environment to get you started.

StifleRulez.xml

The StifleR client will check through its queue of active downloads (both BITS and DO) and will prioritize them according to a locally held XML configuration file containing a set of rules that are configured centrally by the administrator and automatically distributed to clients.

This file contains a simple rule set that defines the content download jobs and the priority that the administrator has assigned to each job type. The “StifleR Rules XML Guide” is available for download from 2Pint website on the StifleR Product Page which gives details on how to create and configure the rules file. There is a default rules file copied into the ProgramData location as part of the Client installation but this is static and should only be used for initial basic testing purposes.

The clients will download the rules definition XML from a configured URL. If you wish to configure your own rules definition file or your client do not have internet access then you need to create this URL on your internal IIS server. If not then the clients will default to use one which is stored on the 2Pint website.

IIS and Browser Requirements

SignalR can be used in a variety of client platforms. This section describes the system requirements for using SignalR in web browsers, Windows desktop applications, Silverlight applications, and mobile devices.

Supported Server IIS Versions

When StifleR’s SignalR driven Dashboards are hosted in IIS, the following versions and configurations are supported.

• IIS 10

• IIS 8, 8.5 or IIS 8 Express

• IIS must be running in integrated mode; classic mode is not supported. Message delays of up to 30 seconds may be experienced if IIS is run in classic mode using the Server-Sent Events transport

• The hosting application must be running in full trust mode

Web Browsers

SignalR can be used in a variety of web browsers, but typically, only the most recent two versions are supported.

Applications that use SignalR in browsers must use jQuery version 1.6.4 or major later versions (such as 1.7.2, 1.8.2, or 1.9.1).

SignalR can be used in the following browsers:

• Microsoft Internet Explorer versions 8, 9, 10, and 11. Modern, Desktop, and Mobile versions are supported

• Microsoft Edge

• Mozilla Firefox: current version - 1, both Windows and Mac versions

• Google Chrome: current version - 1, both Windows and Mac versions

• Safari: current version - 1, both Mac and iOS versions

• Opera: current version - 1, Windows only

• Android browser

In addition to requiring certain browsers, the various transports that SignalR uses have requirements of their own. The following transports are supported under the following configurations:

Web Browser Transport Requirements

*: 6+ required for full functionality.

Unsupported Browsers

While SignalR may run without major issues in older browser versions, we do not actively test SignalR in them and generally will not fix bugs that may appear in them.

Roaming Clients

StifleR uses the concept of 'Roaming Clients' and enables the ability to set bandwidth according to the client location and connectivity. A roaming client (in StifleR terms) is one that is not connected to the corporate network i.e. a known location/subnet or is non-domain joined and/or authenticated.

In these cases there are a couple of choices as to how these clients can be configured. These are determined by the StifleR Server setting DefaultRoamingBandwidth.

The default setting is 0 (disabled) which means that by default a StifleR client that roams will have all Bandwidth policies removed.

If, however, that parameter is set to anything other than zero Roaming policy will be applied (split between Delivery Optimization and BITS)

i.e. If a Default RoamingBandwidth of 50Mbs (51200) is set then the clients would get 25Mbs for BITS and 25Mbs for Delivery Optimization

There are two types of Roaming Client – Roaming and connected to a StifleR server: (possible if the client still has a route to the StifleR Server – via Azure for instance) and - Roaming but not connected to a StifleR server.

Well Connected Networks

Well Connected locations are networks where the bandwidth available to clients is fairly generous (>100Mb/s). In this scenario StifleR can still assist with improving Peer-to-Peer and caching efficiencies, which help to offload both network and memory/CPU load from source servers (Distribution Points etc.)

How it Works:

Instead of setting a 'Target Bandwidth', you can set the location to 'WellConnected' and then set DO and BITS (BranchCache) Bandwidth limits. A Red Leader will still be selected, but the bandwidth allocated to 'Non-Red Leaders' is the same. This allows for faster P2P transfers and faster deployments in general.

The Default Setting is False - (Not Well Connected)