Designing and Implementing a Bandwidth Monitor in C#

Objectives

This guide provides a complete, production-grade example of how to design and implement a bandwidth monitoring system using C# and the .NET platform. By the end of this article, you will:

• Understand how operating systems expose network bandwidth data
• Be able to design a layered, extensible monitoring architecture
• Implement interface-level bandwidth monitoring in .NET
• Understand process-level monitoring approaches and their limitations
• Apply time-series sampling, aggregation, and smoothing techniques
• Visualise and persist bandwidth data efficiently
• Reason about performance, security, and cross-platform behaviour

1. Introduction

Bandwidth monitoring is the practice of measuring the volume and rate of data transmitted over a network. Unlike latency or connectivity checks, bandwidth monitoring focuses on throughput over time. This distinction is critical: bandwidth is not an instantaneous value, but a derived metric calculated from cumulative counters sampled across defined intervals.

In modern software systems, bandwidth monitoring serves multiple roles:

• Diagnosing performance networking issues
• Detecting abnormal or malicious traffic
• Capacity planning and scaling decisions
• Application-level optimisation
• User-facing transparency and reporting

The .NET platform provides a robust set of APIs that allow bandwidth monitoring to be implemented without resorting to kernel drivers or unsafe code, while still achieving high accuracy and performance.

2. Conceptual Model of Bandwidth

Bandwidth is defined as:

Bandwidth = DataTransferred / TimeInterval

Where:

• DataTransferred is measured in bytes
• TimeInterval is measured in seconds

2.1 Cumulative Counters vs Rates

Most operating systems expose cumulative byte counters, not bandwidth directly. These counters increase monotonically from system boot.

To derive bandwidth, we compute the delta between two samples.

Sample 1: 1,000,000 bytes at T1

Sample 2: 1,500,000 bytes at T2

Bandwidth = (1,500,000 – 1,000,000) / (T2 – T1)

This model underpins all monitoring implementations.

3. Architectural Overview

A bandwidth monitor should be designed as a layered system.

+——————————-+

| Presentation Layer |

| (UI, charts, CLI, dashboards) |

+——————————-+

| Aggregation & Analysis |

| (rates, smoothing, alerts) |

+——————————-+

| Data Collection Layer |

| (OS counters, APIs) |

+——————————-+

| Platform Abstraction |

| (Windows / Linux / macOS) |

+——————————-+

This separation of concerns ensures maintainability, testability, and portability.

4. Levels of Bandwidth Monitoring

4.1 Interface-Level Monitoring

Interface-level monitoring measures total inbound and outbound traffic per network adapter.

+——————-+

| Network Interface |

+——————-+

|

v

+——————-+

| Bytes Sent / Rx |

| Bytes Received Tx |

+——————-+

Use cases include:

• Server health monitoring
• Diagnosing saturated links
• Baseline traffic analysis

This is the most portable and lowest-overhead approach.

4.2 Process-Level Monitoring

Process-level monitoring attributes network usage to individual processes.

+———–+ +——————-+

| Process A | –> | Network Stack |

+———–+ +——————-+

+———–+ +——————-+

| Process B | –> | Network Stack |

+———–+ +——————-+

This approach is more complex and platform-specific. On Windows, it typically requires ETW (Event Tracing for Windows). On Linux, it may involve parsing /proc or using eBPF.

5. Data Sources in .NET

5.1 System.Net.NetworkInformation

The primary managed API for interface-level monitoring is provided by:

System.Net.NetworkInformation

Example:

foreach (varnicinNetworkInterface.GetAllNetworkInterfaces())

{

var stats = nic.GetIPv4Statistics();

long bytesSent = stats.BytesSent;

long bytesReceived = stats.BytesReceived;

}

These values are cumulative since system startup.

6. Sampling Strategy

6.1 Sampling Interval Selection

Common sampling intervals:

A one-second interval provides an effective balance for most systems.

6.2 Snapshot Model

A snapshot represents the state of an interface at a specific point in time.

publicsealedclassInterfaceSnapshot

{

public string Name { get; init; }

public long BytesSent { get; init; }

public long BytesReceived { get; init; }

public DateTime Timestamp { get; init; }

}

Snapshots should be immutable and timestamped.

7. Bandwidth Calculation

Bandwidth samples are derived by comparing successive snapshots.

+————-+ +————-+

| Snapshot T1 | —> | Snapshot T2 |

+————-+ +————-+

| |

+——– DELTA ——+

Bandwidth = (CurrentBytes – PreviousBytes) / TimeDelta

Resulting values are typically expressed in bytes per second or bits per second.

8. Aggregation and Time-Series Storage

Bandwidth monitoring inherently produces time-series data.

Time —>

|—-|—-|—-|—-|

s1 s2 s3 s4

Efficient handling requires:

• Rolling buffers
• Fixed-size collections
• Minimal allocations

ObservableCollection<BandwidthSample>

9. Smoothing and Noise Reduction

Raw bandwidth data is often noisy due to bursty traffic.

9.1 Moving Average

Smoothed = (x1 + x2 + x3 + … + xn) / n

9.2 Exponential Moving Average (EMA)

EMA = α * Current + (1 – α) * PreviousEMA

EMA is preferred for real-time displays because it reduces spikes without introducing excessive lag.

10. Process-Level Monitoring (Advanced)

On Windows, process-level monitoring can be implemented using ETW.

+————+ +——————-+

| Application| –> | ETW Kernel Events |

+————+ +——————-+

|

v

+——————-+

| Aggregation Logic |

+——————-+

This approach requires:

• Administrative privileges
• Event correlation logic
• Careful performance tuning

It is recommended as an optional extension rather than a default feature.

11. Visualisation Techniques

11.1 Line Charts

Bandwidth

^

| /\

| /\ / \

| / \_/ \_

+—————–> Time

Line charts are ideal for showing trends over time.

11.2 Desktop Dashboards

Common technologies:

• WPF
• WinUI
• Avalonia

Charts typically bind to observable collections of bandwidth samples.

12. Logging and Persistence

Bandwidth data can be stored as:

• CSV files
• JSON logs
• Time-series databases

Timestamp,Interface,Rx,Tx

12:00:01,Ethernet,102400,51200

Long-term storage enables historical analysis and reporting.

13. Alerts and Thresholds

Threshold-based alerts can be implemented as simple rules.

if (rxBytesPerSecond > threshold)

{

TriggerAlert();

}

Alerts may be visual, logged, or transmitted to external systems.

14. Performance Considerations

A bandwidth monitor must minimise its own impact.

Key principles:

• Avoid blocking threads
• Reuse objects
• Minimise allocations
• Avoid locking in hot paths
• Use async timers

15. Security and Permissions

• Interface-level monitoring is generally unrestricted
• Process-level monitoring may require elevated privileges
• ETW sessions require administrative access

Security requirements should be documented clearly.

16. Cross-Platform Considerations

.NET abstracts most interface-level differences.

17. Extensibility and Future Enhancements

A bandwidth monitor can be extended to include:

• Protocol classification
• Per-endpoint statistics
• Quality-of-Service analysis
• Traffic shaping
• Predictive analytics

18. Summary

Here I have demonstrated how to design and implement a bandwidth monitor using the .NET platform.

By understanding cumulative counters, time-based sampling, and layered architecture, developers can build monitors that are accurate, efficient, and extensible.

Bandwidth monitoring is a practical application of systems programming principles and a valuable component of modern observability strategies.

In the next chapter, these principles can be extended to latency measurement, packet inspection, or distributed tracing.