Changes between Version 2 and Version 3 of Ticket #68, comment 11


Ignore:
Timestamp:
2012-11-29T17:30:03Z (11 years ago)
Author:
zooko
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #68, comment 11

    v2 v3  
    1 Here is a simple scheme for decentralized introduction.  It probably scales up at least as well as the rest of our current network architecture does -- i.e. it is scalable enough for now.
     1Here is a simple scheme for decentralized introduction.  It probably scales up at least as well as the rest of our current network architecture does i.e. it is scalable enough for now.
    22
    3 First, implement #271 -- "subscriber-only introducer client". ''DONE''
     3First, implement #271 "subscriber-only introducer client". ''DONE''
    44
    5 Second, make announcement idempotent in the introducer -- i.e. make it so that if a node announces themselves when they are already in the introducer's set of announced nodes, that the introducer ignores the announcement.  (This makes sense, anyway, because the introducer doesn't need to inform any subscribers about the re-announcement since the clients will already have heard the earlier announcement from the introducer, and the only time a node would announce itself redundantly would be if that node were buggy.) ''DONE''
     5Second, make announcement idempotent in the introducer i.e. make it so that if a node announces themselves when they are already in the introducer's set of announced nodes, that the introducer ignores the announcement.  (This makes sense, anyway, because the introducer doesn't need to inform any subscribers about the re-announcement since the clients will already have heard the earlier announcement from the introducer, and the only time a node would announce itself redundantly would be if that node were buggy.) ''DONE''
    66
    77Third, make "introducers" a class of publishable, subscribable thing like storage server and read-only storage server and upload helper (as per #271).
    88
    9 Fourth, make all publishers -- introducer clients that send announcements -- send their announcements to an evenly distributed subset of the introducers, namely the "Chord fingers" -- the introducer halfway around the circle from the publisher, plus the one a quarter fo the way around the circle, etc.
     9Fourth, make all publishers — introducer clients that send announcements — send their announcements to an evenly distributed subset of the introducers, namely the "Chord fingers" — the introducer halfway around the circle from the publisher, plus the one a quarter fo the way around the circle, etc.
    1010
    11 Fifth, tell each introducer to ''subscribe'' to the introducer-announcements of a small set of other introducers -- again choosing the Chord fingers -- and whenever the introducer hears announcements from the introducers that it subscribes to, then it announces those announcements themselves, just as if it had just heard them from a client.  (Of course, it still ignores any announcements of nodes which it has previously announced, as above.)
     11Fifth, tell each introducer to ''subscribe'' to the introducer-announcements of a small set of other introducers — again choosing the Chord fingers — and whenever the introducer hears announcements from the introducers that it subscribes to, then it announces those announcements themselves, just as if it had just heard them from a client.  (Of course, it still ignores any announcements of nodes which it has previously announced, as above.)
    1212
    1313Now the load of handling introductions is evenly spread among all introducers, and there is no Single Point of !Failure/Single Point of Load.