Florent Daigni?re wrote: > * Volodya <Volodya at WhenGendarmeSleeps.org> [2007-05-21 11:16:13]: > > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> jarvil at gmail.com wrote: >> >>> Hello, >>> >>> I proposed an advanced option on the peers (friends) page for high speed >>> links. >>> >>> In the present code, if you increase the outgoing bandwith the peers >>> inevitably end up in backed off mode as the ones who cannot deal with >>> the higher throughput backoff the incoming connection. I dont know the >>> method used for Backed Off values but some basic math tells me that >>> mode nodes can only receive 10K/s for each connection. Let me explain. >>> >>> If you have one node on default setting of 15K/s outgoing bandwith and >>> 60K/s incoming (4xoutgoing). If a user has 6 connections you have a >>> max of 10K incoming for each connection. 10K/s is double the speed of >>> a modem connection and hardly broadband speed. IMHO This severely >>> limits the speed of freenet. >>> >>> What I would like to see is the ability to set individual bandwith on >>> peers OR designate a peer as high speed which excludes it from the >>> bandwith management on the normal peers. This would send a message to >>> the other peer requesting a high speed link which would appear on >>> their peer listing as request for high speed and the speed requested. >>> If they agree then the link operates at the new speed sending data at >>> the maximum speed specified until there is no more data to send. >>> >>> Regards >>> >>> Jarvil >>> >> This will also help those of us who are running more than one node and they >> are on the >> same LAN. >> >> > > I have tried to explain it on irc: it doesn't and won't help... and > probably will f*ck up the load-balancing. > > Even if we have "faster than other" links, the node doesn't take that > into account when it routes requests : the "fast link" isn't more likely > to be used than any other one because of how routing works. We route to > what we think to be the shortest path not the local-fastest one (to > avoid missrouting). > > What would help is a way to "share" datastores amongst different trusted > nodes. > I think sharing datastores could potentially be an interesting concept, but I'm not clear on the semantics. This could potentially be rather easy to implement.
Does datastores include datacaches? Are datastores only shared for requests and inserts act normally? Would sharing for inserts make any sense since the shared nodes being peers would likely be close to each other location-wise anyway? Would "chains" of trust be used in this sharing idea? Would shared datastores be potentially implemented similar to how Squid caches communicate?
