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
