local multicast/MDNS for relay

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.

[takluyver]

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.

[warner]

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.