On Tue, Jun 15, 2010 at 5:15 PM, Brian Warner <[email protected]> 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 _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
