DEV Community: Maksim Lanies

Stop Mixing Up Your RDP Sessions: Auto-Label Remote Desktop Windows

Maksim Lanies — Fri, 12 Dec 2025 07:57:46 +0000

The Problem Every SysAdmin Knows Too Well

You have 8 Remote Desktop windows open. One is PROD-DB, one is TEST-APP, another is your local dev box. They all look identical. You need to restart a service... and you click the wrong window.

Production is down.

Sound familiar? The native Windows MSTSC client doesn't give you visual cues. Sure, you can hover over the taskbar to see the hostname, but when you're moving fast, mistakes happen.

The "Old School" Workaround (And Why It Sucks)

Most admins resort to:

Editing the remote machine's hostname to include [PROD] or [TEST]
Using third-party RDP managers like mRemoteNG or RD Tabs
Just being really, really careful (spoiler: doesn't work)

But what if you could keep using the native MSTSC client and still get instant visual feedback?

Introducing: RDP Title Master

RDP Title Master is a tiny background utility that:

Monitors all your RDP windows in real-time
Matches window titles against your custom rules (IP addresses, hostnames)
Overlays a color-coded badge directly on the MSTSC toolbar

Note: I'd love to show you a screenshot, but ironically, I switched to macOS right after building this tool! If you try it out, please share a screenshot in the comments — I'd genuinely love to see it in action. 😅

Example Config (`settings.json`)

[
  {
    "Pattern": "prod",
    "Label": "🔥 PRODUCTION",
    "ColorHex": "#e74c3c"
  },
  {
    "Pattern": "192.168",
    "Label": "🏠 LOCAL",
    "ColorHex": "#2ecc71"
  },
  {
    "Pattern": "test",
    "Label": "🧪 TEST",
    "ColorHex": "#3498db"
  }
]

When you connect to prod-db-01.company.com, the toolbar instantly shows a red badge saying "PRODUCTION". No more guessing.

How It Works (Technical Deep Dive)

1. Window Detection

The tool uses EnumWindows to scan all top-level windows, looking for the RDP window class:

private static bool IsRdpWindow(IntPtr hwnd)
{
    string className = GetClassName(hwnd);
    return className == "TscShellContainerClass";
}

2. Title Matching

Once an RDP window is found, we grab its title (which usually contains the hostname or IP):

string title = GetWindowTitle(hwnd);
var rule = _configs.FirstOrDefault(c => 
    title.Contains(c.Pattern, StringComparison.OrdinalIgnoreCase)
);

3. GDI+ Overlay

We create a transparent bitmap with anti-aliased text and a rounded badge background, then apply it using UpdateLayeredWindow:

using (Graphics g = Graphics.FromImage(bmp))
{
    g.SmoothingMode = SmoothingMode.AntiAlias;
    g.TextRenderingHint = TextRenderingHint.AntiAliasGridFit;

    // Draw rounded rectangle badge
    FillRoundedRectangle(g, bgBrush, badgeRect, 10);

    // Draw text on top
    g.DrawString(text, font, textBrush, x, y);
}

4. Daemon Mode

The app runs in an infinite loop (every 3 seconds), checking for new RDP windows. This means you can start it once in the morning and forget about it.

Why C# and Not Python/PowerShell?

Short answer: Performance and distribution.

Single .exe: No runtime dependencies. Just download and run.
GDI+ Quality: Native access to Windows graphics APIs for smooth rendering.
Size: With trimming enabled, the final binary is ~50MB (self-contained .NET 8).

The original prototype was in Python (still available in the repo's legacy_python/ folder), but C# made it production-ready.

Installation & Usage

Quick Start

Download the latest release from GitHub
Edit settings.json with your server patterns
Run MstscTitleBar.exe
Open any RDP session and watch the magic happen

Building from Source

git clone https://github.com/mlanies/mstsc_title_bar.git
cd mstsc_title_bar/MstscTitleBar
dotnet run

To create a portable executable:

dotnet publish -c Release -r win-x64 --self-contained -p:PublishSingleFile=true

Real-World Use Cases

1. Multi-Environment Management

If you manage DEV/STAGE/PROD environments, color-code them:

🔴 Red = Production (danger zone)
🟡 Yellow = Staging (proceed with caution)
🟢 Green = Dev (break things freely)

2. Client Segregation

Consultants managing multiple clients can use patterns like:

{ "Pattern": "client-a", "Label": "Client A", "ColorHex": "#9b59b6" }
{ "Pattern": "client-b", "Label": "Client B", "ColorHex": "#f39c12" }

3. Datacenter Identification

Label servers by location:

{ "Pattern": "us-east", "Label": "🇺🇸 Virginia", "ColorHex": "#3498db" }
{ "Pattern": "eu-west", "Label": "🇪🇺 Ireland", "ColorHex": "#2ecc71" }

Known Limitations

Windowed Mode Only: Full-screen RDP hides the toolbar (by design).
Windows 10/11: Uses WinAPI calls specific to modern Windows.
Refresh Delay: 3-second polling interval (configurable in code).

Want to contribute? PRs welcome!

Conclusion

If you've ever typed rm -rf / in the wrong terminal or restarted the wrong server, you know the value of visual cues. RDP Title Master is a simple, zero-configuration tool that makes your daily workflow safer.

Try it out and let me know what you think in the comments!

GitHub: https://github.com/mlanies/mstsc_title_bar

Have you built tools to prevent "production accidents"? Share your stories below!

Quic-test: an open tool for testing QUIC, BBRv3, and FEC under real-world network conditions

Maksim Lanies — Thu, 11 Dec 2025 19:05:53 +0000

This article was prepared as part of the CloudBridge Research project focused on optimizing network protocols (BBRv3, MASQUE, FEC, QUIC).

Project: github.com/cloudbridge-research/quic-test

Video demo of quic-test

Why we built this

When we began studying the behavior of QUIC, BBRv3, and Forward Error Correction in real networks — from Wi-Fi to mobile networks and regional backbones — we ran into a simple problem: there were almost no tools capable of accurately reproducing real-world network conditions.

You can use iperf3, but it’s about TCP and basic UDP. You can take standalone QUIC libraries, but they lack visualization and load generation. You can write custom simulators, but they do not reflect real channel behavior. Want to test how BBRv3 performs between Moscow and Novosibirsk? Please: find three servers across different datacenters, configure netem, manually collect metrics and hope results will be reproducible.

There was no comprehensive QUIC tester with charts, channel profiles, FEC, BBRv3 support, TUI, and Prometheus metrics.
So we built quic-test — an open tool we use inside CloudBridge Research for all experiments. And now we share it with the community, universities, and engineers.

What is quic-test

A fully open laboratory environment for analyzing the behavior of QUIC, BBRv3, and FEC in real networks.
Not a simulator, but a real engineering instrument — all our research is based on measurements collected with it.

Who quic-test is for

Network engineers — compare TCP/QUIC/BBRv3 in your own networks and understand where QUIC provides real benefits.

SRE and DevOps teams — test service behavior under packet loss and high RTT, prepare for production issues before they appear.

Educators and students — run modern labs on transport protocols with real metrics and visualization.

Researchers — gather datasets for ML routing models, publish reproducible results.

Key capabilities

Protocols: QUIC (RFC 9000), HTTP/3, 0-RTT resumption.

Congestion Control: BBRv2 (stable), BBRv3 (experimental), CUBIC, Reno.

Forward Error Correction: XOR-FEC (working), RS-FEC (in development).

Network profiles: mobile (4G/LTE), Wi-Fi, lossy (3–5% loss), high-latency (regional routes).
All profiles are based on real measurements from our CloudBridge Edge PoPs.

Metrics: Prometheus, Grafana, TUI visualization (quic-bottom in Rust).

Comparison: TCP vs QUIC under identical conditions.

Quick Start

Docker

The simplest way to start is with ready Docker images:

# Run client (performance test)
docker run mlanies/quic-test:latest --mode=client --server=demo.quic.tech:4433

# Run server
docker run -p 4433:4433/udp mlanies/quic-test:latest --mode=server

Build from source

git clone https://github.com/twogc/quic-test
cd quic-test

# Build FEC library (requires clang)
cd internal/fec && make && cd ../..

# Build main tool (requires Go 1.21+)
go build -o quic-test cmd/quic-test/main.go

# Run
./quic-test --mode=client --server=demo.quic.tech:4433

First test: QUIC vs TCP

Server:

./quic-test --mode=server --listen=:4433

Client:

./quic-test --mode=client --server=127.0.0.1:4433 --duration=30s

QUIC vs TCP comparison:

./quic-test --mode=client --server=127.0.0.1:4433 --compare-tcp --duration=30s

TUI visualization:

quic-bottom --server=127.0.0.1:4433

The results include RTT, jitter, throughput, retransmissions, packet loss, FEC recovery, and fairness under parallel tests.
These are the exact metrics we used when achieving jitter <1 ms on PoP↔PoP.

Real network profiles

Profiles are based on actual measurements from CloudBridge Edge PoPs (Moscow, Frankfurt, Amsterdam).

Mobile (4G/LTE)

RTT 50–150 ms (avg ~80), throughput 5–50 Mbps (avg ~20), 0.1–2% loss, jitter 10–30 ms.
On this profile we tested FEC and achieved ~+10% goodput at 5% loss.

Wi-Fi

Burst losses and micro-drop behavior typical for office/home Wi-Fi.

Lossy

3–5% stable loss — ideal for testing FEC recovery efficiency.

High-latency

RTT 50–150 ms — typical interregional RU↔EU routes that we tested.

Usage:

./quic-test --mode=client --profile=mobile --compare-tcp --duration=60s

Custom profiles

./quic-test --mode=client --profile=custom \
  --rtt=100ms \
  --bandwidth=10mbps \
  --loss=1% \
  --jitter=20ms

Metrics & Grafana integration

Server with Prometheus:

./quic-test --mode=server --prometheus-port=9090

Available metrics

quic_rtt_ms
quic_jitter_ms
quic_loss_total
fec_recovered
tcp_goodput_mbps
quic_goodput_mbps
bbrv3_bandwidth_est
quic_datagram_rate
connection_drops
queue_delay_ms

We use these metrics in Grafana and in AI Routing Lab.

Research examples

Case 1: Mobile profile (5% loss)

Metric	Baseline QUIC	QUIC + FEC 10%	Gain
Goodput	3.628 Mbps	3.991 Mbps	+10%
Jitter	0.72 ms	0.72 ms	stable
RTT P50	51.25 ms	51.25 ms	stable

TCP CUBIC shows 4–6× degradation here.

Case 2: VPN tunnels with 10% loss

Metric	TCP	QUIC	QUIC + FEC 15%	Gain
Throughput	25 Mbps	45 Mbps	68 Mbps	+172%
Retransmissions	18,500	12,200	3,800	-79%
P99 RTT	450 ms	320 ms	210 ms	-53%

Other results

PoP↔PoP (Moscow—Frankfurt—Amsterdam): jitter <1 ms, connection time 9.20 ms
BBRv2 vs BBRv3 on satellite-like profiles: +16% throughput
Production profile: 9.258 Mbps goodput at 30 connections

Usage in universities

quic-test was originally designed as a teaching laboratory environment.

Available lab works

Lab #1: QUIC basics — RTT, jitter, handshake, 0-RTT, connection migration.
Lab #2: TCP vs QUIC — losses, HOL blocking, performance.
Lab #3: Losses & FEC — redundancy trade-offs.
Lab #4: BBRv3 vs CUBIC — congestion control comparison.
Lab #5: NAT traversal — ICE/STUN/TURN.
Lab #6: HTTP/3 performance — multiplexing vs HOL-blocked HTTP/2.

Materials are available in docs/labs/.

Architecture

Detailed scheme in docs/ARCHITECTURE.md. Summary:

Go core — transport, QUIC, measurements (quic-go v0.40, BBRv2 and experimental BBRv3).
Rust TUI — quic-bottom real-time visualization.
C++ FEC module — AVX2 SIMD optimized, stable XOR-FEC, experimental RS-FEC.
Metrics — Prometheus, HDR histograms.
Network emulation — token bucket, delay queue, random drop.

Project status

Stable — QUIC client/server, TCP vs QUIC comparison, profiles, Prometheus, TUI.
Experimental — BBRv3, RS-FEC, MASQUE CONNECT-IP, TCP-over-QUIC.
Planned — automatic plotting, eBPF latency inspector, mini-PoP container.

Why we opened the project

CloudBridge Research is an independent research center (ANO "Center for Network Technology Research and Development", founded in 2025).
Our goal is to create an open stack of tools for engineers and universities.
We believe that open research accelerates technological progress and makes it accessible to everyone.

Related projects

AI Routing Lab — uses quic-test metrics to train delay prediction models (>92% accuracy target).
masque-vpn — QUIC/MASQUE VPN load-tested with quic-test, including high-loss scenarios.

How to reproduce our results

All configs and commands are in the repo.

Production profile (0.1% loss, 20 ms RTT):

./quic-test --mode=server --listen=:4433 --prometheus-port=9090

./quic-test --mode=client \
  --server=<server-ip>:4433 \
  --connections=30 \
  --duration=60s \
  --congestion=bbrv3 \
  --profile=custom \
  --rtt=20ms \
  --loss=0.1%

Mobile profile (5% loss) with FEC:

./quic-test --mode=server \
  --listen=:4433 \
  --fec=true \
  --fec-redundancy=0.10

./quic-test --mode=client \
  --server=<server-ip>:4433 \
  --profile=mobile \
  --fec=true \
  --fec-redundancy=0.10 \
  --duration=60s

Other scenarios are described in scripts/ and docs/reports/.

Contributions & feedback

We welcome issues, PRs, test reports, feature proposals, and integrations into university courses.

GitHub: https://github.com/cloudbridge-research/quic-test
Email: info@cloudbridge-research.ru
Blog: https://cloudbridge-research.ru

Conclusion

If you need to honestly evaluate how QUIC, BBRv3, and FEC behave in real networks — from Wi-Fi to mobile to regional backbones — try quic-test.

All results are reproducible, all tools are open, and this is a living engineering project that evolves with the community.

Try it, reproduce our findings, share your results — together we make networks better.

Desktop UI for Cloudflare Tunnel: Making Remote Access Simple

Maksim Lanies — Fri, 05 Dec 2025 18:40:58 +0000

What is Cloudflare Tunnel?

Cloudflare Tunnel provides you with a secure way to connect your resources to Cloudflare without a publicly routable IP address.

Instead of sending traffic to an external IP, a lightweight daemon (cloudflared) in your infrastructure creates outbound-only connections to Cloudflare's global network. This means:

✅ No inbound ports to open - Your firewall stays closed
✅ No exposed origin IP - Your infrastructure stays hidden
✅ Bidirectional communication - Despite being outbound-only, traffic flows both ways
✅ Protection from bypass attacks - All traffic routes through Cloudflare's edge

What Can You Connect?

Cloudflare Tunnel can securely connect:

HTTP/HTTPS web servers - Expose web applications
SSH servers - Secure shell access (guide)
RDP (Remote Desktop) - Windows remote desktop (guide)
TCP services - Databases, custom applications, any TCP protocol
SMB file shares - Network file access
gRPC services - Modern API protocols

Learn more in the official documentation.

The Challenge

cloudflared is an amazing tool — lightweight, secure, and battle-tested by millions of connections daily.

But there's a common pain point:

For quick, ad-hoc connections, the CLI/YAML workflow can feel heavy.

If you want to:

Quickly RDP into a remote Windows machine
Open an SSH tunnel for a few minutes
Share a local dev server with a colleague

You typically need to:

Write or edit a YAML configuration file
Remember specific CLI flags and syntax
Manually manage tunnel processes
Track which ports are in use

For production deployments, this workflow makes sense. But for temporary, one-off connections, it can slow you down.

The Solution: A Desktop UI for cloudflared

What if you could:

Click "Connect to RDP" and get instant access?
See all your active tunnels in one place?
Never worry about port conflicts or process management?

I built exactly that:

https://github.com/mlanies/desktop-argo-tunnel

Dashboard

What the app does

The UI wraps cloudflared to make common tasks instant:

Core Features

One-Click Connections
- Launch RDP tunnels instantly
- Connect to SSH servers with a button click
- Forward any TCP service without typing commands
Zero Configuration
- App automatically downloads and installs cloudflared if needed
- No manual setup required
- Works out of the box
Intelligent Port Management
- Automatic port assignment (10000-60000 range)
- No port conflicts
- See exactly which local port each tunnel uses
Secure Credential Storage
- Built-in KeePass (.kdbx) integration
- AES-256 encrypted password storage
- Import/export existing KeePass databases
- Password quality analysis
Real-Time Monitoring
- View all active tunnels with their PIDs
- Monitor connection health
- Track recent activity
- Stop tunnels with one click

No YAML files.

No terminal commands.

Just "Connect" and "Disconnect".

Why build this?

The Use Case Gap

Cloudflare Tunnel documentation covers two main scenarios well:

Production deployments - Full YAML configs, ingress rules, DNS routing
Cloudflare Access integration - Zero Trust with identity policies

But there's a third scenario that's less documented:

Quick, temporary TCP tunneling - "I just need to RDP into that server right now"

This app fills that gap.

Who Benefits?

DevOps Engineers

Quick access to remote servers without VPN overhead

Support Teams

Non-technical staff can connect to services without CLI knowledge

Developers

Instant SSH/RDP access during debugging sessions

Small Teams

Simple remote access without complex Zero Trust setup

How it works

The app acts as a friendly wrapper around cloudflared:

Auto-Installation: Downloads and installs cloudflared if not present
Command Generation: Translates UI actions into correct cloudflared CLI arguments
Process Management: Starts, monitors, and stops cloudflared processes
Visual Feedback: Shows active connections, local ports, and process IDs

Under the hood, it's using cloudflared access tcp commands like:

cloudflared access tcp --hostname ssh.example.com --url localhost:12345

But you never have to type that.

Technical Architecture

Built with modern, performant technologies:

Rust + Tauri 2.0 - Lightweight native backend (~50MB total)
React 18 + TypeScript - Type-safe, responsive UI
KeePass integration - Secure credential storage
Cross-platform - Windows, macOS, and Linux

For technical details, see the Architecture Documentation.

Key Features in Detail

Zero Configuration

The app can automatically download and install cloudflared if it's not present on your system. No manual setup required.

Secure Credential Management

Built-in KeePass (.kdbx) database support:

Create and manage password containers
Store credentials with AES-256 encryption
Import/export existing KeePass databases
Password quality analysis and security scoring

Real-time Monitoring

View all active tunnels with local ports and PIDs
Monitor connection health and statistics
Track recent activity and connection history
Copy local ports to clipboard

Multi-language Support

Full internationalization with English and Russian support (more languages coming soon).

Comparison with Standard Workflow

Traditional CLI Approach

# 1. Remember the syntax
cloudflared access tcp --hostname rdp.example.com --url localhost:3389

# 2. Keep track of the process
# 3. Remember to kill it when done
# 4. Hope you didn't forget which port you used

With Desktop UI

Click server name
Click "Connect"
See local port displayed
Click "Disconnect" when done

Looking for feedback

I would love to hear your thoughts:

Does this fill a real need in your workflow?
What other features would make this more useful?
Should Cloudflare consider an official desktop UI?
Any UX suggestions or improvements?

I'm actively collecting feedback to shape the next iteration.

Repo: https://github.com/mlanies/desktop-argo-tunnel

Resources

Official Cloudflare Documentation

This Project

Note: This is a community project, not an official Cloudflare tool. It's designed to complement cloudflared for specific use cases, not replace it.

Thanks for reading and huge respect to the Cloudflare team for building an amazing tunneling ecosystem!

DEV Community: Maksim Lanies

Stop Mixing Up Your RDP Sessions: Auto-Label Remote Desktop Windows

The Problem Every SysAdmin Knows Too Well

The "Old School" Workaround (And Why It Sucks)

Introducing: RDP Title Master

Example Config (settings.json)

How It Works (Technical Deep Dive)

1. Window Detection

2. Title Matching

3. GDI+ Overlay

4. Daemon Mode

Why C# and Not Python/PowerShell?

Installation & Usage

Quick Start

Building from Source

Real-World Use Cases

1. Multi-Environment Management

2. Client Segregation

3. Datacenter Identification

Known Limitations

Conclusion

Quic-test: an open tool for testing QUIC, BBRv3, and FEC under real-world network conditions

Why we built this

What is quic-test

Who quic-test is for

Key capabilities

Quick Start

Docker

Build from source

First test: QUIC vs TCP

Real network profiles

Mobile (4G/LTE)

Wi-Fi

Lossy

High-latency

Custom profiles

Metrics & Grafana integration

Available metrics

Research examples

Case 1: Mobile profile (5% loss)

Case 2: VPN tunnels with 10% loss

Other results

Usage in universities

Available lab works

Architecture

Project status

Why we opened the project

Related projects

How to reproduce our results

Contributions & feedback

Conclusion

Desktop UI for Cloudflare Tunnel: Making Remote Access Simple

What is Cloudflare Tunnel?

What Can You Connect?

The Challenge

The Solution: A Desktop UI for cloudflared

Dashboard

What the app does

Core Features

Why build this?

The Use Case Gap

Who Benefits?

How it works

Technical Architecture

Key Features in Detail

Zero Configuration

Secure Credential Management

Real-time Monitoring

Multi-language Support

Comparison with Standard Workflow

Traditional CLI Approach

With Desktop UI

Looking for feedback

Resources

Official Cloudflare Documentation

This Project

Example Config (`settings.json`)