Scott G. Miller asks, "What would you guys like to be able to do in the
simulator?"
There are all kinds of things that would be useful to know, depending on
how the network is set up.
Things we might like to know include:
1) The number of hops to find a key immediately after it has
been inserted.
2) The numbef of hops to find a key after the net has
"stabilized."
3) The number of messages sent to perform an insert.
4) The number of bytes transmitted to perform an operation.
5) The number of inserts that should have resulted in key
collisions but instead resulted in data being duplicated under
the same key.
6) The number of requests that fail because a message was
already seen before.
7) The actual number of keys in the network.
8) The number of bytes used by multipart messages with at least
one part missing.
9) The number of requests sent to "duff" nodes.
"Number of" should be the {maximum,median,average,80%-quintile,total}
across all nodes.
Parameters that will be established by usage (and that therefore should
be measured and fed into the simulation) include:
1) The fraction of nodes that are transient (never claim to be
the DataSource).
2) The size (distribution) of data stores in all the nodes.
3) The insert-request ratio.
4) The percentage of requests for a nonexistant key.
5) The percentantage of inserts of an existant key.
6) The "node arrival rate" (the network is not static).
7) The chances that a node will go "duff" after an insert.
8) The fraction of nodes that arbitrarily drop any requests.
9) The number of nodes any node knows when the node starts up.
Parameters that can be changed in the source code (and which the simulation can
therefore suggest an optimal value of) include:
1) The frequency with which a node changes the DataSource on an
DataSend.
2) The frequency with which a node arbitrarily increments the
HopsToLive when that value is 1.
3) The hops to live for an insert.
4) The hops-to-live distribution for requests.
5) The function used to determine what data a node will delete
from an overfull data store.
6) The maximum size of each component of a multipart message.
7) The maximum number of parts in a multipart message.
8) The fraction of nodes that use an alternative closeness
relation (e.g., the key that lexicographically follows the
desired key).
9) The way "duff" nodes are handled (no distinction, constant
ignore duration, exponentially increasing ignore duration,
ignore until heard from, one strike and you're out, three
strikes and you're out, ..?).
This will allow us to answer questions like:
What is the minimum number of hops-to-live to keep the number of
conflicting keys to a minimum?
Will changing the DataSource more frequently make data easier or
harder to find?
Will changing the DataSource more frequently make the network as
a whole able to hold more data?
Which is more space efficient, 16K or 32K parts to multipart
messages?
_______________________________________________
Freenet-dev mailing list
Freenet-dev at lists.sourceforge.net
http://lists.sourceforge.net/mailman/listinfo/freenet-dev
