On Feb 5, 2008, at 5:39 PM, Robert Hailey wrote: > > On Feb 5, 2008, at 1:05 PM, Matthew Toseland wrote: >> Is this sufficiently well-defined for simulations yet? It seems to >> me there >> will be threshold parameters and so on? > > Is it well-defined enough to be implemented for simulations? The > biggest threshold business will be in attempting to break up peers > into network groups. Since this coloring mechanism would be oblivious > to present routing, it could be deployed on the live network up unto > any of the routing changes, plus the coloring my take so long from a > zero-state that it would be necessary. > > (1) Challange/Response Pings > > Requires at least one new message type (PongWithSecret?CRAMPong?), but > it may be better to separate it into it's own request/response pair > (PingSecret/PongSecret). So... two message types, and one handler (for > PingSecret) which is just a minor extension of the routableRequest.
I've committed an initial implementation of this in r17609, disabled via a boolean. In addition to what was previously discussed, I added a mechanism to make the first number of hops random. Being requestor-settable, it is not mandatory to be used in the end, but this should allow for a number of possibilities: - Detection of two subnets connected by a bridge wider than one or two peers (tricky, though). - Closer correlation to swap requests walking path (but does not loop). - An enhanced version of the node pinger which could manipulate both the htl & dawnHtls (the htl at which it begins to behave normally) for a more gradient (less boolean) view of well-connectedness between it's peer connections. I have not had time enough to test it at all, any debugging or comments are appreciated. See: src/freenet/node/NetworkIDManager.java -- Robert Hailey > > (2) SecretNodePinger (much different task than present 'NodePinger') > > Alerted to connect/disconnect/add/remove peernodes, this class would > keep a running list of pingable nodes for each peer node; it does so > by methodically setting 'secrets' in a node and sending requests for > that secret from other nodes. Requires a maxHtl, and some time > threshold (or percentage) to keep a peernode in the list despite > missing a ping or two. Decision asto reusing the same secret for all > connectivity to a given node or reseting it each time. Presumably not > getting an ack from a set-secret/uid request is cause for backoff. > Decision asto trying to ascertain connectivity from backed off nodes. > I would suggest a separate message for alerting peers to the uid/ > secret (rather than dealing with separate node ref/n2n queues etc). > So... one message type, and a large class. > > This should be easily testable in a simulation, but finding a good HTL > may best be done on the live network (would we want to use 10?) > > (3) NetworkIDManager > > Take the lists from #2 and somehow try to intelligently break them up > into separate network groups. It is expected that most of the nodes > will be reachable from most of the other nodes; or that one or two > nodes will be totally isolated... in the middle there is a definite > threshold sensitivity here with respect to algorithms and constants. > Also supply an assigned network-id on a per-peer baises, and one for > the node at large. Requires adding a noderef-ish network id to get it > to our peers, we might want to use a separate info message though, as > we would be sending a potentially different id to each peer. Other > contants include how long to wait between reanalyzing the pings from > #2. > > At least on a large scale, this would be more difficult to simulate, > but doable. > [...] -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080206/a3095a80/attachment.html>
