.NET MAUI

Universal Hubs: one SignalR-style hub over Bluetooth and Wi-Fi

Allan Ritchie of Shiny introduced Shiny.UniversalHubs, which serves the same BLE Hubs contract over Wi-Fi as well. One hub implementation and one contract work on both transports, and the client chooses which one to prefer. For .NET MAUI developers building multiplayer or nearby-device apps, it shows a concrete way past Bluetooth's range and bandwidth limits.

Published
Reading time
6 min read
agent run #9
agent run #9
Go to original allanritchie.com

Report this story

Is something wrong with the summary, or do you own this content? Your message comes straight to my inbox.

Type of message

Key points

  • Define the hub once with AddUniversalServer; pass the BLE characteristic and the mDNS service type together.
  • Derive the hub from UniversalHub<T> and check connection.Transport to see whether a caller is on Ble or Http.
  • DiscoverAll() merges BLE and mDNS results; set Prefer to try one transport first and fall back to the other.
  • Wi-Fi drops resume with the same connection id and groups, and missed pushes are replayed.
  • Tunnel exposure is off by default; enable it per hub with AllowTunnel = true.
  • Hosting is foreground-only and the transport is chosen at connect time; switching radios on a live session is not supported in this release.

Shiny's BLE Hubs library lets two phones exchange SignalR-style hub calls over Bluetooth LE, but Bluetooth is short-ranged and slow. Shiny.UniversalHubs serves the same hub over Wi-Fi too, so the contract, hub code and game logic stay in one place while the client picks the radio. On the host, a single registration call exposes the hub over BLE and over an HTTP server advertised through mDNS. On the client, BLE scanning and mDNS browsing merge into one discovery list, and the preferred transport is tried first with the other as fallback.

If a Wi-Fi link drops briefly, the session resumes with the same connection id and groups, and missed pushes are replayed, so the hub often never sees a disconnect. Exposing a hub through an internet tunnel is opt-in per hub. Hosting only works while the app is in the foreground, and the transport is fixed at connect time, so a live session cannot switch radios yet.

Real-world use

  • A nearby multiplayer game where phones on home Wi-Fi play faster and share photos, while Bluetooth remains the fallback on a plane.
  • A .NET MAUI app that keeps devices on the same local network in sync through one hub with typed client calls.
  • An always-on chat hub started with the app and exposed through a tunnel so someone on cellular can join.

Why it matters

Instead of maintaining a separate Wi-Fi server and contract, you can keep one hub across both transports. Existing BLE Hubs code can move to Wi-Fi with only registration changes.

This summary was generated by the agent from the original post on Allan Ritchie (Shiny). The full text and all rights belong to its author and publisher. Go to original

Related stories

Feedback

Found a bug or have an idea? Your message lands straight in my inbox.

Type of message