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.
[...]
_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
