[tahoe-dev] Advertised invalid node port

[Zooko O'Whielacronx]

On Tue, Jun 15, 2010 at 5:15 PM, Brian Warner <warner at lothar.com> wrote:
> You should probably also be aware that tahoe nodes will only initiate
> connections to nodes that advertise themselves as servers. If node A has
> their [storage]enabled config set to False, then other nodes won't try
> to connect to them. (this bit me when I had one client node
> port-forwarded but a second NATed server node was not forwarded, and I
> wanted to take advantage of tahoe's bidirectional connectivity to let
> everybody see the server: I had to mark my client as a server, with
> 'readonly=true' to keep it from accumulating shares, to get all the
> connections to stick around).

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?

I thought the introduction scheme made it so that each server would
attempt to open a connection to each client, in addition to each
client trying to open a connection to each server.

<Zooko checks...>

Hm, let's see, here is the code that gets called when we receive an
announcement of a node:

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/introducer/client.py?rev=3931#L163

(Oh, I just opened ticket #1085.)

It winds up by invoking a callback:

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/introducer/client.py?rev=3931#L210

Which callback was earlier passed as an argument to subscribe_to():

http://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/src/allmydata/introducer/client.py?rev=3931#L109

So, who calls subscribe_to()?

tahoe-lafs/trunk$ grep -r subscribe_to !(_darcs) | grep -v
"^src/allmydata/test/"
misc/awesome_weird_stuff/boodlegrid.tac:
publisher.callRemote("subscribe_to_all", b)
src/allmydata/introducer/client.py:    def subscribe_to(self,
service_name, cb, *args, **kwargs):
src/allmydata/introducer/interfaces.py:    def
subscribe_to(service_name, callback, *args, **kwargs):
src/allmydata/storage_client.py:# IntroducerClient.subscribe_to .
ServerFarm hides descriptors, passes rrefs
src/allmydata/storage_client.py:        ic.subscribe_to("storage",
self._got_announcement)

Oh! Okay, so storage servers do not currently subscribe to the
introducer and ask to be informed about storage clients. I
misremembered. Do storage clients send announcements of their own
existence to the introducer?

$ find src/allmydata -name '*.py' -print0 | xargs -0 grep
publish[^A-Za-z0-9_-] | grep
-vEe"^src/allmydata/(test|mutable|introducer)/"
src/allmydata/client.py:        # should we run a storage server (and
publish it for others to use)?
src/allmydata/client.py:        def _publish(res):
src/allmydata/client.py:
self.introducer_client.publish(furl, "storage", ri_name)
src/allmydata/client.py:        d.addCallback(_publish)
src/allmydata/client.py:        def _publish(res):
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)
src/allmydata/client.py:        d.addCallback(_publish)
src/allmydata/client.py:        def _publish(res):
src/allmydata/client.py:        d.addCallback(_publish)
src/allmydata/client.py:        def _publish(self):
src/allmydata/client.py:        d.addCallback(_publish)
src/allmydata/frontends/sftpd.py:        # open until the previous
upload/publish has completed. This is necessary
src/allmydata/history.py:    def notify_publish(self, p, size):
src/allmydata/interfaces.py:        publish has completed. I will
update the servermap in-place with the
src/allmydata/storage/crawler.py:        update self.state to publish
information to status displays.
src/allmydata/web/status.py:            ctx.fillSlots("type", "publish")
src/allmydata/web/status.py:        if stype == "publish":


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.

Oh, it would be nice if Tahoe-LAFS didn't send a "stub_client"
announcement (and, in fact, didn't instantiate an
allmydata.client.Client object at all, or at least not most of one)
unless the "web gateway" configuration setting is turned on. If you
aren't serving as a web gateway then you are not going to act as a
Tahoe-LAFS storage client -- only as a storage server (or upload
helper or introducer), so you shouldn't elicit connections from
storage servers.

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1085# we shouldn't use
"assert" to validate incoming data in introducer client
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/1086# servers should
attempt to open connections to clients