[tahoe-dev] Advertised invalid node port

[Brian Warner]

On 6/15/10 8:52 PM, Zooko O'Whielacronx wrote:
>
> Wait, what? You wanted a node which wasn't a server to receive
> connections from other nodes that weren't servers? Or you wanted a
> node which wasn't a server to receive connections from servers and for
> some reason the servers weren't opening connections to it?

The latter:

 * node A is a server, living in my parents' house, behind an old NAT
   box on which it's infeasible to set up a portmapping, which gets a
   dynamic IP address from their ISP. Not the best environment for a
   server, but it's out of the SF earthquake zone and has few
   common-mode failures with my other servers.

 * node B is a client, living in my apartment, behind a newer NAT box on
   which it was fairly easy to set up a portmapping, which gets a static
   IP address because I believe in connecting to the Internet, not just
   the "intarweb". This node uploads my digital photo archive to the
   grid.

 * I want node B to use node A. This requires B to establish a
   connection to A (specifically to it's external IP address which then
   gets forwarded to the internal client node).

> Oh! Okay, so storage servers do not currently subscribe to the
> introducer and ask to be informed about storage clients. I
> misremembered.

Right. Clients subscribe to hear about servers, but not vice versa. I
had to mark my node-B as a server (even though I don't want it to hold
shares) in order to trick node-A to making an outbound connection.

We switched to this "half-mesh" behavior from the previous "full-mesh"
(i.e. where all nodes connect to all other nodes, regardless of
client/server distinctions) in the "storage broker" refactoring, on
01-Jun-2009 (look for the bunch of patches in which
src/allmydata/storage_client.py was created).

> Do storage clients send announcements of their own existence to the
> introducer?

> src/allmydata/client.py:            # we publish an empty object so
> that the introducer can count how
> src/allmydata/client.py:
> self.introducer_client.publish(furl, "stub_client", ri_name)

The purpose of the "stub_client" record is explained in that client.py
comment:

 # we publish an empty object so that the introducer can count how many
 # clients are connected and see what versions they're running.

In my 466-introducer work, the stub_client announcement goes away
altogether. It is replaced by a "subscriber_info" dictionary that is
passed into the remote subscribe() call (along with information about
what they're subscribing to, and the object to be notified when matching
announcements are seen).

> Hm, they publish under the service name "stub_client". I'm not sure,
> but I *think* that a server could subscribe to the introducer's
> notifications about "stub_clients" and then try to open connections to
> the things that they learn about thereby, thus solving the problem
> that Brian had of a client not automatically getting a connection
> established to every server. This is now ticket #1086.

I'd rather see a different sort of announcement that clients publish to
indicate that they want servers to connect back to them, maybe called
"client_callback" or something. Servers would be configured to subscribe
to these announcements, and would establish connections to the objects
described therein, but would not attempt to use any services on those
objects.

I'll add notes to those tickets.

Incidentally, I'm slowly starting to work on the "Foolscap Relay
Service", which would provide an easier-to-set-up but
more-bandwidth-consuming solution to the NAT-bound-server problem. If I
had relays, I'd probably use them instead of the pseudo-server trick.

cheers,
 -Brian