2008-06-18 19:24:16 +00:00
|
|
|
|
2013-03-20 22:10:47 +00:00
|
|
|
import time, os.path, textwrap
|
2017-02-27 17:56:49 +00:00
|
|
|
from zope.interface import implementer
|
2008-06-18 19:24:16 +00:00
|
|
|
from twisted.application import service
|
2018-01-28 06:13:50 +00:00
|
|
|
from twisted.internet import defer
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
from foolscap.api import Referenceable
|
2008-11-22 00:43:52 +00:00
|
|
|
import allmydata
|
2008-06-18 19:24:16 +00:00
|
|
|
from allmydata import node
|
2017-09-06 01:08:35 +00:00
|
|
|
from allmydata.util import log, rrefutil
|
2018-01-30 06:51:49 +00:00
|
|
|
from allmydata.util.i2p_provider import create as create_i2p_provider
|
|
|
|
from allmydata.util.tor_provider import create as create_tor_provider
|
2008-06-19 00:04:41 +00:00
|
|
|
from allmydata.introducer.interfaces import \
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
RIIntroducerPublisherAndSubscriberService_v2
|
2016-05-11 03:19:55 +00:00
|
|
|
from allmydata.introducer.common import unsign_from_foolscap, \
|
2016-06-30 05:58:14 +00:00
|
|
|
SubscriberDescriptor, AnnouncementDescriptor
|
2018-01-30 07:00:17 +00:00
|
|
|
from allmydata.node import read_config
|
2018-03-04 21:29:17 +00:00
|
|
|
from allmydata.node import create_node_dir
|
2018-01-30 07:00:17 +00:00
|
|
|
from allmydata.node import create_connection_handlers
|
|
|
|
from allmydata.node import create_control_tub
|
|
|
|
from allmydata.node import create_tub_options
|
|
|
|
from allmydata.node import create_main_tub
|
|
|
|
|
2008-06-18 19:24:16 +00:00
|
|
|
|
2018-01-29 05:48:18 +00:00
|
|
|
# this is put into README in new node-directories
|
|
|
|
INTRODUCER_README = """
|
|
|
|
This directory contains files which contain private data for the Tahoe node,
|
|
|
|
such as private keys. On Unix-like systems, the permissions on this directory
|
|
|
|
are set to disallow users other than its owner from reading the contents of
|
|
|
|
the files. See the 'configuration.rst' documentation file for details.
|
|
|
|
"""
|
|
|
|
|
|
|
|
|
2016-09-05 22:34:17 +00:00
|
|
|
def _valid_config_sections():
|
|
|
|
return node._common_config_sections()
|
|
|
|
|
|
|
|
|
2013-03-20 22:10:47 +00:00
|
|
|
class FurlFileConflictError(Exception):
|
|
|
|
pass
|
|
|
|
|
2018-01-28 06:13:50 +00:00
|
|
|
# this is/can-be async
|
|
|
|
# @defer.inlineCallbacks
|
2017-09-06 01:08:35 +00:00
|
|
|
def create_introducer(basedir=u"."):
|
2018-01-28 06:13:50 +00:00
|
|
|
# ideally we would pass in reactor
|
|
|
|
from twisted.internet import reactor
|
|
|
|
|
2018-02-27 22:00:31 +00:00
|
|
|
if not os.path.exists(basedir):
|
2018-01-28 06:13:50 +00:00
|
|
|
create_node_dir(basedir, INTRODUCER_README)
|
2018-01-29 05:48:18 +00:00
|
|
|
|
2018-01-28 06:13:50 +00:00
|
|
|
config = read_config(
|
2018-01-29 05:48:18 +00:00
|
|
|
basedir, u"client.port",
|
|
|
|
generated_files=["introducer.furl"],
|
2018-02-22 22:42:44 +00:00
|
|
|
_valid_config_sections=_valid_config_sections,
|
2018-01-29 05:48:18 +00:00
|
|
|
)
|
2018-01-28 06:13:50 +00:00
|
|
|
|
2018-01-31 18:30:46 +00:00
|
|
|
i2p_provider = create_i2p_provider(reactor, config)
|
|
|
|
tor_provider = create_tor_provider(reactor, config)
|
2018-01-28 08:27:25 +00:00
|
|
|
|
2018-01-31 18:30:46 +00:00
|
|
|
default_connection_handlers, foolscap_connection_handlers = create_connection_handlers(reactor, config, i2p_provider, tor_provider)
|
2018-01-28 06:13:50 +00:00
|
|
|
tub_options = create_tub_options(config)
|
|
|
|
|
2018-01-31 01:04:08 +00:00
|
|
|
# we don't remember these because the Introducer doesn't make
|
|
|
|
# outbound connections.
|
2018-01-28 06:13:50 +00:00
|
|
|
i2p_provider = None
|
|
|
|
tor_provider = None
|
|
|
|
main_tub, is_listening = create_main_tub(
|
2018-01-31 18:30:46 +00:00
|
|
|
config, tub_options, default_connection_handlers,
|
2018-01-28 08:27:25 +00:00
|
|
|
foolscap_connection_handlers, i2p_provider, tor_provider,
|
2018-01-28 06:13:50 +00:00
|
|
|
)
|
|
|
|
control_tub = create_control_tub()
|
|
|
|
|
2018-01-29 04:49:05 +00:00
|
|
|
node = _IntroducerNode(
|
|
|
|
config,
|
|
|
|
main_tub,
|
|
|
|
control_tub,
|
|
|
|
i2p_provider,
|
|
|
|
tor_provider,
|
|
|
|
tub_is_listening=is_listening,
|
2018-01-28 06:13:50 +00:00
|
|
|
)
|
2018-01-29 04:49:05 +00:00
|
|
|
return defer.succeed(node)
|
2017-09-06 01:08:35 +00:00
|
|
|
|
|
|
|
|
|
|
|
class _IntroducerNode(node.Node):
|
2008-06-18 19:24:16 +00:00
|
|
|
NODETYPE = "introducer"
|
|
|
|
|
2018-01-28 06:13:50 +00:00
|
|
|
def __init__(self, config, main_tub, control_tub, i2p_provider, tor_provider, tub_is_listening):
|
|
|
|
node.Node.__init__(self, config, main_tub, control_tub, i2p_provider, tor_provider, tub_is_listening)
|
2008-06-18 19:24:16 +00:00
|
|
|
self.init_introducer()
|
2008-09-30 23:21:49 +00:00
|
|
|
webport = self.get_config("node", "web.port", None)
|
2008-06-18 19:24:16 +00:00
|
|
|
if webport:
|
|
|
|
self.init_web(webport) # strports string
|
|
|
|
|
|
|
|
def init_introducer(self):
|
2016-08-30 01:49:20 +00:00
|
|
|
if not self._tub_is_listening:
|
|
|
|
raise ValueError("config error: we are Introducer, but tub "
|
|
|
|
"is not listening ('tub.port=' is empty)")
|
2018-01-31 18:30:46 +00:00
|
|
|
introducerservice = IntroducerService()
|
2018-01-31 20:03:05 +00:00
|
|
|
introducerservice.setServiceParent(self)
|
2008-06-18 19:24:16 +00:00
|
|
|
|
2018-01-31 18:30:46 +00:00
|
|
|
old_public_fn = self.config.get_config_path(u"introducer.furl")
|
|
|
|
private_fn = self.config.get_private_path(u"introducer.furl")
|
2013-03-20 22:10:47 +00:00
|
|
|
|
|
|
|
if os.path.exists(old_public_fn):
|
|
|
|
if os.path.exists(private_fn):
|
|
|
|
msg = """This directory (%s) contains both an old public
|
|
|
|
'introducer.furl' file, and a new-style
|
|
|
|
'private/introducer.furl', so I cannot safely remove the old
|
|
|
|
one. Please make sure your desired FURL is in
|
|
|
|
private/introducer.furl, and remove the public file. If this
|
|
|
|
causes your Introducer's FURL to change, you need to inform
|
|
|
|
all grid members so they can update their tahoe.cfg.
|
|
|
|
"""
|
|
|
|
raise FurlFileConflictError(textwrap.dedent(msg))
|
|
|
|
os.rename(old_public_fn, private_fn)
|
2016-04-27 04:54:45 +00:00
|
|
|
furl = self.tub.registerReference(introducerservice,
|
|
|
|
furlFile=private_fn)
|
|
|
|
self.log(" introducer is at %s" % furl, umid="qF2L9A")
|
|
|
|
self.introducer_url = furl # for tests
|
2008-06-18 19:24:16 +00:00
|
|
|
|
|
|
|
def init_web(self, webport):
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
self.log("init_web(webport=%s)", args=(webport,), umid="2bUygA")
|
2008-06-18 19:24:16 +00:00
|
|
|
|
|
|
|
from allmydata.webish import IntroducerWebishServer
|
2018-01-31 18:30:46 +00:00
|
|
|
nodeurl_path = self.config.get_config_path(u"node.url")
|
2015-01-30 00:50:18 +00:00
|
|
|
config_staticdir = self.get_config("node", "web.static", "public_html").decode('utf-8')
|
2018-01-31 18:30:46 +00:00
|
|
|
staticdir = self.config.get_config_path(config_staticdir)
|
2012-03-07 02:25:05 +00:00
|
|
|
ws = IntroducerWebishServer(self, webport, nodeurl_path, staticdir)
|
2018-01-31 20:03:05 +00:00
|
|
|
ws.setServiceParent(self)
|
2008-06-18 19:24:16 +00:00
|
|
|
|
2017-02-27 17:56:49 +00:00
|
|
|
@implementer(RIIntroducerPublisherAndSubscriberService_v2)
|
2008-06-18 19:24:16 +00:00
|
|
|
class IntroducerService(service.MultiService, Referenceable):
|
|
|
|
name = "introducer"
|
2016-06-30 05:58:14 +00:00
|
|
|
# v1 is the original protocol, added in 1.0 (but only advertised starting
|
|
|
|
# in 1.3), removed in 1.12. v2 is the new signed protocol, added in 1.10
|
|
|
|
VERSION = { #"http://allmydata.org/tahoe/protocols/introducer/v1": { },
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
"http://allmydata.org/tahoe/protocols/introducer/v2": { },
|
versioning: include an "appname" in the application version string in the versioning protocol, and make that appname be controlled by setup.py
It is currently hardcoded in setup.py to be 'allmydata-tahoe'. Ticket #556 is to make it configurable by a runtime command-line argument to setup.py: "--appname=foo", but I suddenly wondered if we really wanted that and at the same time realized that we don't need that for tahoe-1.3.0 release, so this patch just hardcodes it in setup.py.
setup.py inspects a file named 'src/allmydata/_appname.py' and assert that it contains the string "__appname__ = 'allmydata-tahoe'", and creates it if it isn't already present. src/allmydata/__init__.py import _appname and reads __appname__ from it. The rest of the Python code imports allmydata and inspects "allmydata.__appname__", although actually every use it uses "allmydata.__full_version__" instead, where "allmydata.__full_version__" is created in src/allmydata/__init__.py to be:
__full_version__ = __appname + '-' + str(__version__).
All the code that emits an "application version string" when describing what version of a protocol it supports (introducer server, storage server, upload helper), or when describing itself in general (introducer client), usese allmydata.__full_version__.
This fixes ticket #556 at least well enough for tahoe-1.3.0 release.
2009-02-12 00:18:16 +00:00
|
|
|
"application-version": str(allmydata.__full_version__),
|
2008-11-22 00:43:52 +00:00
|
|
|
}
|
2008-06-18 19:24:16 +00:00
|
|
|
|
2018-01-31 18:30:46 +00:00
|
|
|
def __init__(self):
|
2008-06-18 19:24:16 +00:00
|
|
|
service.MultiService.__init__(self)
|
|
|
|
self.introducer_url = None
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
# 'index' is (service_name, key_s, tubid), where key_s or tubid is
|
|
|
|
# None
|
|
|
|
self._announcements = {} # dict of index ->
|
|
|
|
# (ann_t, canary, ann, timestamp)
|
|
|
|
|
|
|
|
# ann (the announcement dictionary) is cleaned up: nickname is always
|
|
|
|
# unicode, servicename is always ascii, etc, even though
|
|
|
|
# simplejson.loads sometimes returns either
|
|
|
|
|
|
|
|
# self._subscribers is a dict mapping servicename to subscriptions
|
|
|
|
# 'subscriptions' is a dict mapping rref to a subscription
|
|
|
|
# 'subscription' is a tuple of (subscriber_info, timestamp)
|
2016-06-30 05:58:14 +00:00
|
|
|
# 'subscriber_info' is a dict, provided directly by v2 clients. The
|
|
|
|
# expected keys are: version, nickname, app-versions, my-version,
|
|
|
|
# oldest-supported
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
self._subscribers = {}
|
|
|
|
|
2009-06-23 02:10:47 +00:00
|
|
|
self._debug_counts = {"inbound_message": 0,
|
|
|
|
"inbound_duplicate": 0,
|
2012-06-11 02:10:22 +00:00
|
|
|
"inbound_no_seqnum": 0,
|
|
|
|
"inbound_old_replay": 0,
|
2009-06-23 02:10:47 +00:00
|
|
|
"inbound_update": 0,
|
|
|
|
"outbound_message": 0,
|
|
|
|
"outbound_announcements": 0,
|
|
|
|
"inbound_subscribe": 0}
|
2016-06-30 05:58:14 +00:00
|
|
|
self._debug_outstanding = 0
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
|
|
|
|
def _debug_retired(self, res):
|
|
|
|
self._debug_outstanding -= 1
|
|
|
|
return res
|
2008-06-18 19:24:16 +00:00
|
|
|
|
|
|
|
def log(self, *args, **kwargs):
|
|
|
|
if "facility" not in kwargs:
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
kwargs["facility"] = "tahoe.introducer.server"
|
2008-06-18 19:24:16 +00:00
|
|
|
return log.msg(*args, **kwargs)
|
|
|
|
|
2016-06-30 05:58:14 +00:00
|
|
|
def get_announcements(self):
|
2012-04-23 22:02:22 +00:00
|
|
|
"""Return a list of AnnouncementDescriptor for all announcements"""
|
|
|
|
announcements = []
|
|
|
|
for (index, (_, canary, ann, when)) in self._announcements.items():
|
|
|
|
ad = AnnouncementDescriptor(when, index, canary, ann)
|
|
|
|
announcements.append(ad)
|
|
|
|
return announcements
|
|
|
|
|
2008-06-18 19:24:16 +00:00
|
|
|
def get_subscribers(self):
|
2012-04-23 22:02:22 +00:00
|
|
|
"""Return a list of SubscriberDescriptor objects for all subscribers"""
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
s = []
|
|
|
|
for service_name, subscriptions in self._subscribers.items():
|
|
|
|
for rref,(subscriber_info,when) in subscriptions.items():
|
2012-04-23 22:02:22 +00:00
|
|
|
# note that if the subscriber didn't do Tub.setLocation,
|
|
|
|
# tubid will be None. Also, subscribers do not tell us which
|
|
|
|
# pubkey they use; only publishers do that.
|
|
|
|
tubid = rref.getRemoteTubID() or "?"
|
|
|
|
remote_address = rrefutil.stringify_remote_address(rref)
|
|
|
|
# these three assume subscriber_info["version"]==0, but
|
|
|
|
# should tolerate other versions
|
|
|
|
nickname = subscriber_info.get("nickname", u"?")
|
|
|
|
version = subscriber_info.get("my-version", u"?")
|
|
|
|
app_versions = subscriber_info.get("app-versions", {})
|
|
|
|
# 'when' is the time they subscribed
|
|
|
|
sd = SubscriberDescriptor(service_name, when,
|
|
|
|
nickname, version, app_versions,
|
2015-09-22 23:29:34 +00:00
|
|
|
remote_address, tubid)
|
2012-04-23 22:02:22 +00:00
|
|
|
s.append(sd)
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
return s
|
2008-06-18 19:24:16 +00:00
|
|
|
|
2008-11-22 00:43:52 +00:00
|
|
|
def remote_get_version(self):
|
|
|
|
return self.VERSION
|
|
|
|
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
def remote_publish_v2(self, ann_t, canary):
|
|
|
|
lp = self.log("introducer: announcement (v2) published", umid="L2QXkQ")
|
|
|
|
return self.publish(ann_t, canary, lp)
|
|
|
|
|
|
|
|
def publish(self, ann_t, canary, lp):
|
2009-06-23 02:10:47 +00:00
|
|
|
try:
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
self._publish(ann_t, canary, lp)
|
2009-06-23 02:10:47 +00:00
|
|
|
except:
|
|
|
|
log.err(format="Introducer.remote_publish failed on %(ann)s",
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
ann=ann_t,
|
|
|
|
level=log.UNUSUAL, parent=lp, umid="620rWA")
|
2009-06-23 02:10:47 +00:00
|
|
|
raise
|
|
|
|
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
def _publish(self, ann_t, canary, lp):
|
2009-06-23 02:10:47 +00:00
|
|
|
self._debug_counts["inbound_message"] += 1
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
self.log("introducer: announcement published: %s" % (ann_t,),
|
|
|
|
umid="wKHgCw")
|
|
|
|
ann, key = unsign_from_foolscap(ann_t) # might raise BadSignatureError
|
|
|
|
service_name = str(ann["service-name"])
|
2009-06-23 02:10:47 +00:00
|
|
|
|
2016-05-11 03:19:55 +00:00
|
|
|
index = (service_name, key)
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
old = self._announcements.get(index)
|
|
|
|
if old:
|
|
|
|
(old_ann_t, canary, old_ann, timestamp) = old
|
|
|
|
if old_ann == ann:
|
|
|
|
self.log("but we already knew it, ignoring", level=log.NOISY,
|
|
|
|
umid="myxzLw")
|
2009-06-23 02:10:47 +00:00
|
|
|
self._debug_counts["inbound_duplicate"] += 1
|
2008-06-18 19:24:16 +00:00
|
|
|
return
|
|
|
|
else:
|
2012-06-11 02:10:22 +00:00
|
|
|
if "seqnum" in old_ann:
|
|
|
|
# must beat previous sequence number to replace
|
2013-03-19 00:40:56 +00:00
|
|
|
if ("seqnum" not in ann
|
|
|
|
or not isinstance(ann["seqnum"], (int,long))):
|
|
|
|
self.log("not replacing old ann, no valid seqnum",
|
2012-06-11 02:10:22 +00:00
|
|
|
level=log.NOISY, umid="ySbaVw")
|
|
|
|
self._debug_counts["inbound_no_seqnum"] += 1
|
|
|
|
return
|
|
|
|
if ann["seqnum"] <= old_ann["seqnum"]:
|
|
|
|
self.log("not replacing old ann, new seqnum is too old"
|
|
|
|
" (%s <= %s) (replay attack?)"
|
|
|
|
% (ann["seqnum"], old_ann["seqnum"]),
|
|
|
|
level=log.UNUSUAL, umid="sX7yqQ")
|
|
|
|
self._debug_counts["inbound_old_replay"] += 1
|
|
|
|
return
|
|
|
|
# ok, seqnum is newer, allow replacement
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
self.log("old announcement being updated", level=log.NOISY,
|
|
|
|
umid="304r9g")
|
2009-06-23 02:10:47 +00:00
|
|
|
self._debug_counts["inbound_update"] += 1
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
self._announcements[index] = (ann_t, canary, ann, time.time())
|
|
|
|
#if canary:
|
|
|
|
# canary.notifyOnDisconnect ...
|
|
|
|
# use a CanaryWatcher? with cw.is_connected()?
|
|
|
|
# actually we just want foolscap to give rref.is_connected(), since
|
|
|
|
# this is only for the status display
|
2009-06-23 02:10:47 +00:00
|
|
|
|
2008-06-18 19:24:16 +00:00
|
|
|
for s in self._subscribers.get(service_name, []):
|
2009-06-23 02:10:47 +00:00
|
|
|
self._debug_counts["outbound_message"] += 1
|
|
|
|
self._debug_counts["outbound_announcements"] += 1
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
self._debug_outstanding += 1
|
|
|
|
d = s.callRemote("announce_v2", set([ann_t]))
|
|
|
|
d.addBoth(self._debug_retired)
|
2009-06-23 02:10:47 +00:00
|
|
|
d.addErrback(log.err,
|
|
|
|
format="subscriber errored on announcement %(ann)s",
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
ann=ann_t, facility="tahoe.introducer",
|
2009-06-23 02:10:47 +00:00
|
|
|
level=log.UNUSUAL, umid="jfGMXQ")
|
2008-06-18 19:24:16 +00:00
|
|
|
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
def remote_subscribe_v2(self, subscriber, service_name, subscriber_info):
|
|
|
|
self.log("introducer: subscription[%s] request at %s"
|
|
|
|
% (service_name, subscriber), umid="U3uzLg")
|
|
|
|
return self.add_subscriber(subscriber, service_name, subscriber_info)
|
|
|
|
|
|
|
|
def add_subscriber(self, subscriber, service_name, subscriber_info):
|
2009-06-23 02:10:47 +00:00
|
|
|
self._debug_counts["inbound_subscribe"] += 1
|
2008-06-18 19:24:16 +00:00
|
|
|
if service_name not in self._subscribers:
|
|
|
|
self._subscribers[service_name] = {}
|
|
|
|
subscribers = self._subscribers[service_name]
|
|
|
|
if subscriber in subscribers:
|
|
|
|
self.log("but they're already subscribed, ignoring",
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
level=log.UNUSUAL, umid="Sy9EfA")
|
2008-06-18 19:24:16 +00:00
|
|
|
return
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
|
2016-06-30 05:58:14 +00:00
|
|
|
assert subscriber_info
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
|
|
|
|
subscribers[subscriber] = (subscriber_info, time.time())
|
2008-06-18 19:24:16 +00:00
|
|
|
def _remove():
|
|
|
|
self.log("introducer: unsubscribing[%s] %s" % (service_name,
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
subscriber),
|
|
|
|
umid="vYGcJg")
|
2008-06-18 19:24:16 +00:00
|
|
|
subscribers.pop(subscriber, None)
|
|
|
|
subscriber.notifyOnDisconnect(_remove)
|
|
|
|
|
new introducer: signed extensible dictionary-based messages! refs #466
This introduces new client and server halves to the Introducer (renaming the
old one with a _V1 suffix). Both have fallbacks to accomodate talking to a
different version: the publishing client switches on whether the server's
.get_version() advertises V2 support, the server switches on which
subscription method was invoked by the subscribing client.
The V2 protocol sends a three-tuple of (serialized announcement dictionary,
signature, pubkey) for each announcement. The V2 server dispatches messages
to subscribers according to the service-name, and throws errors for invalid
signatures, but does not otherwise examine the messages. The V2 receiver's
subscription callback will receive a (serverid, ann_dict) pair. The
'serverid' will be equal to the pubkey if all of the following are true:
the originating client is V2, and was told a privkey to use
the announcement went through a V2 server
the signature is valid
If not, 'serverid' will be equal to the tubid portion of the announced FURL,
as was the case for V1 receivers.
Servers will create a keypair if one does not exist yet, stored in
private/server.privkey .
The signed announcement dictionary puts the server FURL in a key named
"anonymous-storage-FURL", which anticipates upcoming Accounting-related
changes in the server advertisements. It also provides a key named
"permutation-seed-base32" to tell clients what permutation seed to use. This
is computed at startup, using tubid if there are existing shares, otherwise
the pubkey, to retain share-order compatibility for existing servers.
2011-11-20 10:21:32 +00:00
|
|
|
# now tell them about any announcements they're interested in
|
|
|
|
announcements = set( [ ann_t
|
|
|
|
for idx,(ann_t,canary,ann,when)
|
|
|
|
in self._announcements.items()
|
|
|
|
if idx[0] == service_name] )
|
|
|
|
if announcements:
|
|
|
|
self._debug_counts["outbound_message"] += 1
|
|
|
|
self._debug_counts["outbound_announcements"] += len(announcements)
|
|
|
|
self._debug_outstanding += 1
|
|
|
|
d = subscriber.callRemote("announce_v2", announcements)
|
|
|
|
d.addBoth(self._debug_retired)
|
|
|
|
d.addErrback(log.err,
|
|
|
|
format="subscriber errored during subscribe %(anns)s",
|
|
|
|
anns=announcements, facility="tahoe.introducer",
|
|
|
|
level=log.UNUSUAL, umid="mtZepQ")
|
|
|
|
return d
|