On Friday 30 November 2007 19:35, Robert Hailey wrote: > > On Nov 30, 2007, at 1:01 PM, Matthew Toseland wrote: > > > 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: > >> > >> [...] that an SSK signature is verified at every node[...] would > >> yield the same > >> result 100% of the time.[...] > > On Nov 30, 2007, at 1:04 PM, Robert Hailey wrote: > > [...] I interpret as meaning that my node refuses requests primarily > > because it is waiting on everyone else [...] > > To use an analogy from the recent Houston/Katrina-Rita evacuation, in > relating to bandwidth. A single stoplight at the end of a major > freeway is not a significant factor, unless of course there are > 100,000 cars waiting at it. Even worse, make it two distantly-spaced > stoplights, and no effective progress will be made. > > If it is was the case that all rejects are from bandwidth limitations, > it would follow that the network was running at optimal capacity, only > to be made better by re-arranging the utilization of the bandwidth. Or > also if the network was mostly-idle, I suppose. Besides i/o (network/ > disk), the other major latency is processing (crypto).
Perhaps. Or perhaps it isn't being used because bandwidth liability is too conservative. Or perhaps it isn't being used because we're not matching demand to supply, as I originally suggested: when there is a gap, we don't get a request, when there isn't a gap, we do. > > My point is that while node X is verifying my request (which I'm going > to be doing anyway), I must wait. And in waiting, requests are being > dropped. I see the major problem at hand is that the time in-handling > of packets must be minimized, as if we are all waiting on the slowest > node, and for a slow-enough node, the cryptographic verification in a > virtual machine would be slow indeed. This might even be an effective > DDoS attack (accept-and-wait --> overload threads). If every node on the network was waiting for one really slow node then yes we'd have a problem. :) > > Or else, the current system in-place may be like ethernet: beyond a > point of congestion, it just doesn't work. -------------- 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/20071201/ed35968e/attachment.pgp>
