[freenet-dev] Alpha, Darknet routing, et al.

[Robert Hailey]

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.

(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.

-

At this point the coloring would have to be applied to the live  
network, as there is little point speculating about the wonders and  
thresholds of routing/swapping benefits if the coloring does not work,  
much less augmenting requests to carry network id's, etc. I suggest  
probe requests carrying back network id's for exploring the network  
here.

--
Robert Hailey