question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

local multicast/MDNS for relay

See original GitHub issue

A friend and I were able to transfer a file directly, when both of us were normally using a VPN (which means the data has to go through the relay, very slow), by switching to a local ad-hoc network. (on OS-X, this is done by choosing “Create Network…” from the wifi menu). To accomplish this, I had to run a relay locally, and he had to use --relay-url=ws://MY-IP-ADDR:4000/v1. Neither of us were connected to the real internet while on the ad-hoc network, so the normal relay wasn’t available.

It’d be slick to have a mode that does this without running a local relay. MCT and I were thinking about this a while ago. I’m imagining something like this:

  • use --relay-url=multicast, or --relay-multicast, or MDNS, or some flag to say “use the local network instead of the default relay server”
  • replace the rendezvous protocol client with one that joins a multicast group, sends periodic messages to the group until the other client responds, then sends messages directly to the other client

There might be a cheaper/easier/less-coding way to go, like by having a distinguished side (maybe the sender) run a full rendezvous server (with an in-memory database instead of relay.sqlite on disk), then register it on a well-known MDNS/zeroconf/bonjour name. The receiver could repeatedly try to connect to a relay at that well-known name, and then speak the normal relay protocol.

Issue Analytics

  • State:open
  • Created 7 years ago
  • Comments:10

github_iconTop GitHub Comments

1reaction
takluyvercommented, Jun 27, 2016

For reference, zget is a similar CLI tool to transfer files, which currently works only over the local network and without encryption (though encryption is being worked on). The sender uses zeroconf MDNS to advertise the file, and the recipient waits for the advertisement to tell it where to connect.

Cross-pinging @nils-werner, author of zget. It looks like these two tools are gradually converging.

For the CLI, it would be good to name the option something like --local or --nointernet that matches what the user wants to do, rather than something based on the technical details of how it works.

0reactions
warnercommented, Feb 2, 2017

How are channels allocated on the rendezvous server? Just pick the lowest available one?

Pretty close. The allocation code chooses a random single-digit code, if any are available. If not, it chooses a random two-digit code. If those are all used up, it does the same for three-digit codes. If those are used up too, it just starts picking randomly from 1000-1000000 for a thousand trials and hopes one of them is free.

I wanted to make it slightly more random than “always lowest available”, so that people didn’t get into the habit of assuming that codes always started with 1-.

Could you just use a random function to pick any MDNS channel from 0-20?

Yeah, that would probably work. (we treat “0” as special, for an unauthenticated no-code-necessary throw-caution-to-the-wind mode). If we know that we’re being asked to allocate a code (e.g. wormhole send without the explicit --code= argument), then it’d be nice to use MDNS to query for which channels are already in use, to reduce the chance of collisions somewhat (not entirely, because of races). But if the range we’re picking from is large enough, and the rate at which people are using them is low enough (on a given broadcast domain), then it probably doesn’t matter.

In any case, it would be trivially easy for somebody to just DoS the broadcast domain and force a fallback to the rendezvous server by squatting all service names.

The same DoS attack is easy to do against the rendezvous server, so no real change there.

Read more comments on GitHub >

github_iconTop Results From Across the Web

Multicast DNS - Wikipedia
In computer networking, the multicast DNS (mDNS) protocol resolves hostnames to IP addresses within small networks that do not include a local name...
Read more >
Multicast DNS Discovery Relay - IETF Tools
A network service which relays mDNS messages received on a local link to a Client, and on behalf of that Client can transmit...
Read more >
Overview of mDNS Relay - IP Service - Huawei Support
The mDNS relay is responsible for forwarding mDNS packets exchanged ... multicast address of 224.0.0.251 to request available services on local networks.
Read more >
Multicast DNS Discovery Relay - WaterSprings.ORG
This document extends the Discovery Proxy for Multicast DNS-Based Service Discovery specification. It describes a lightweight relay ...
Read more >
5353/UDP Multicast DNS (mDNS) and DNS-SD - HackTricks
Devices use mDNS when the local network lacks a conventional unicast DNS server. To resolve a domain name for a local address using...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found