On Nov 29, 2007, at 7:26 PM, Matthew Toseland wrote: > I conclude that the reason that Freenet's performance sucks is that > the > current load management algorithms do not adequately match demand to > supply!
On Nov 17, 2007, at 2:05 PM, Matthew Toseland wrote: > The pubkey itself for an SSK cannot be encrypted as a node > forwarding an SSK > has to be able to verify the signature. Of course, there are two issues involved here... Slow (latency) and Slow (throughput). In the "Short refs" thread, when Matthew implied that an SSK signature is verified at every node, my first thought was... cryptography is slow, and in a 'good' network such a verification would yield the same result 100% of the time. If it is not already the case, perhaps it would make good sense to only verify the signature: 1) If we are the 'receiving' node. interested in it, or 2) If we are caching the network data locally, or 3) Statistically (1-in-every-N packets) to sanitize a 'bad' network (where N is probably related to HTL) Otherwise, it would seem that the common case (where the data is only routed) would not require verification, as bad data would be verified 'later' in the chain; better latency at the cost of a possibly avoidable transmission of bad data. Note that in the above case #2 (the second-most-common case, I imagine) the check could be done after the network response; e.g. have one dedicated thread checking signatures & adding to the local cache (localizing the latency of crypto & disk I/O; freeing the OS resource of a thread). Since somehow I got the subject of threads... :) and whereas we now will refuse requests to limit the number of threads freenet uses, threads effect the network. A load management system may take into account how many threads we can devote to a particular connection (which presumably is equivalent to the number of queued transactions). -- Robert Hailey -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071130/36a9c6aa/attachment.html>
