Beacons

Beacons are not to be confused with bacon.

The 2Pint Software StifleR Beacon service 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 location where clients obtain the bulk of their content. If using Configuration Manager, this would be a Distribution Point. If content is mostly downloaded from the Internet, and the Internet breakout is in a major datacenter, the Beacon server can be installed on any server in the same location. The StifleR Beacon Service may be installed on the StifleR Server if desired.

StifleR Beacon Installation

Beacon Service Logic

1. Service polls list of Beacon locations every 2 minutes, if MaxBW is configured on the server.

   1. NOTE: Server setting is different to the Location flag!!!

   2. Internal clock to bypass location poll unless 6 hours passed has a logical issue, so we poll every 2 minutes.

2. For each location we iterate over:

   1. If set to WellConnected, we bypass and don't check it.

   2. If server throttling and location throttling is enabled, we check the following in the order of;

      • “Not enough time has passed for a retest of the maximum bandwidth for {0}” where {0} is replaced with location GUID.

      • If LastBandwidthMeasurement time is set to nothing, we flag to measure.

      • If LastBandwidthMeasurement time is less than current time - 518400 seconds AND the Red Leader latency is equal or lower than the default latency we flag to measure.

      • If LastBandwidthMeasurement time is less than current time – 518400 * 2 we flag to measure.

      • If none of the above is true, we log the following super debug entry:

   3. If we are set to measure from the flag, we then add the location ID to the list of measurements to do.

3. For each measure flagged:

   1. If the location is linked to a parent, we do nothing.

      1. Likely cause to issue, as we check with “HasValue” which might return true for a Guid.Empty value.

   2. If the location has no beacon address, we do nothing.

   3. If the location does not have the correct flag (16 dec) we do nothing.

   4. We try to get the Red Leader for the location.

      1. We add the Red Leader to the list of ActiveMeasurement.

      2. GetBeaconIpDestination function on the client using SignalR. The following entry on the client is logged: Log.WriteDebug("iPERF", "DNS", "First DNS entry for iPerf beacon target {0} resolves to {1}", target, usedAddress).

      3. If the usedAddress is “N/A” that indicates an issue, and the client will not send up the right info but just exits.

      4. Client calls server function VerifyBeaconHostNotBusy.

      5. This adds the entry to the dnsToIps list which is required below.

4. Wait 5 seconds.

5. For each Active Measurement

   1. Get the valid entry for connection ID from “DNStoIP” list.

   2. Check to make sure we don't have a running test against that by checking busyTest list, ip being listed indicates test in action.

   3. If not in list, we add it to the list.

   4. We check the location beacon port and sends the resolved IP + port to the client.

6. Client calls the iPerf executable:

   1. If return code is 0, the following log entry is written; Log.WriteInfoE("iPERF", "Measure", "The speed to {0} is measured to a speed of:{1} bps ({2}) kilobits/s", 3267, ipEntry, bits_per_second, bandwidth).

   2. In case of a non 0 return code, the following entry is written: Log.WriteError("iPERF", "Component","Failed to measure, please review the iperf log").

7. Client returns the estimate to the server with the regular check-in intervals, which can take up to 15mins.

   1. After sending the updated speed, the value is replaced with “N/A” indicating that it has already been sent.