This should be optional -- whether you want your request "probability routed" or not -- because it exposes the user to a high degree of risk on being routed to a compromised node. If the NSA ensures that they have the fastest connections -- and they certainly have to power/money to do so -- they could steer a lot of traffic their way. I think we should put up with the slowness for now. In a very short time, the next year or two, the number of people with broadband connections will out number those without -- if we haven't already crossed that threshold.
brett ----- Original Message ----- From: "Muzzle" <[email protected]> To: <freenet-dev at lists.sourceforge.net> Sent: Friday, August 04, 2000 5:38 PM Subject: Re: [Freenet-dev] Re: [Freenet-tech] Speed Issues > On Thu, 3 Aug 2000 01:32:48 -0700, > freenet-dev-admin at lists.sourceforge.net wrote: > > > > >>I have been experimenting with a node for several days now and have been > >>experiencing incredibly slow transfers through freenet particularly on > >>larger files. It appears that several of the other nodes that I talk with > >>are severely bandwidth challenged. Freenet is unlikely to be a viable > >>online resource unless a method is built in to the routing process which > >>lends prefference to connections with higher transfer rates. For those of > >>you who are more technical than I am, would it be feasible to include a > >>transfer rate metric in the data that is stored for each connection and > >>could such a metric be used to direct traffic to faster servers. > >If instead of the current best route strategy there would be a probability > >routing, coupled with a speed value of routes. Storing the round-trip value > >at each known route would add a lot more meaning the probability routing. > >The probability of a routing into certain direction should be calculated > >from closest routing found multiplied with that routings roundtrip value, > >and the lower total the better. If a routing probability fails it should > >either route into a random direction, or perhaps the second best should be > >tried. Either way this should allow finding new routes to hosts, aswell as > >routing more traffic into faster directions. > > > >I'm kinda sleepy so I hope you excuse my flood of typo's :-D > > It could be a client issue. > The client could request the file to two or tree different nodes and > then retrive it from the faster node-chain. > > > -- > Muzzle, Flatline, Zero on IRC; ICQ# 36124438 > Key fingerprint: 5881 356B DDA7 115B 6FAF C529 34ED 70A8 7E52 D805 > www.internations.net/it/muzzle > "We are, we can, we will" > > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
