dbinspect_mdns 0.1.0

Optional mDNS advertising and discovery for a dbinspect bridge, so a desktop client can find it on the LAN without being told a host and port.

dbinspect_mdns

Optional mDNS advertising for a dbinspect_bridge, so a desktop client can find a running bridge on the LAN without being told a host and a port.

final bridge = await startBridge(appName: 'my_app', adapters: [...]);
final advertiser =
    bridge == null ? null : await BridgeAdvertiser.start(port: bridge.port);

// ...
await advertiser?.stop();

Why this is a separate package

dbinspect_bridge is pure Dart on purpose — it is embedded in other people's applications, including server-side and CLI ones that have no Flutter SDK. Advertising a service needs an mDNS responder, and the one this uses (bonsoir) is a Flutter plugin. Keeping it here means adopting discovery is a decision, and skipping it costs nothing.

What is advertised

A random per-session instance name, the port, and proto=1. That is the whole record.

The application name, the runtime, the device model, the bridge version and the adapter list are answers to hello, after pairing — broadcasting them unauthenticated would hand every peer on the subnet a target list and a version number to look up. The instance name is random rather than derived from anything, because a stable name is itself an identifier a passive listener can follow between sessions.

A pairing code is never advertised. Discovery fills in a host and a port; the code still comes from the application's own log, which is what makes a discovered bridge a claim the developer can check rather than one they have to take.

This is the secondary path

adb forward tcp:PORT tcp:PORT and an SSH tunnel are the primary workflows, and they need no discovery at all — they also turn the whole question of LAN exposure into a loopback bridge. Reach for this when you want the device to appear in the client on its own.

On iOS, the mDNS path additionally needs the local-network permission and the multicast entitlement. With discovery off by default, most developers never meet that prompt.

Release builds

BridgeAdvertiser.start returns null behind the same compile-time bridgeEnabled guard the server uses, so a release build contains neither the socket nor the service type. The example app's tool/verify_release_apk.sh greps a real release APK for _dbinspect along with the JSON-RPC method names.

Apache-2.0.