It really isn't THAT slow. It's not a significant factor in the network's overall performance.
On Friday 30 November 2007 18:49, Robert Hailey wrote: > > 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 -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071130/4a40b555/attachment.pgp>
