> > For a total of 0.3% chance of a query getting an answer? If only
> > 0.3% of all queries even get a DF, certainly the chance of
> > actually getting all the data is even lower?
> Where do you get the 0.3% chance from? psuccess is the probability
> of the whole requests successfully moving data.
Hum, I did that wrong... What I should have said is that given the
432,580 outbound aggregate requests, we had 767 come back through the
node for consideration for data source resetting for a DF proability
of 0.18%.
767/432580
.00177308243561884506
But notice, this isn't substantially better than the 0.3% that I claimed.
> http://127.0.0.1:8888/servlet/nodestatus/psuccess_data.txt
>
> More detailed data can be obtained from requestSuccessRatio and
> routingSuccessRatio (I use the hourly means), in the Diagnostics
> page.
But, that is ignores QR style queries?
> Yeah... that's for full file transfer though. I know, it's bad.
But, the good news is that it is trivially fixable (in total islation
for the first hop only). Answer the last request in, with all the
data out, priority over all other data. To avoid nodes wanting to
flood you, use the first time in, if you've seen the Q before from the
DSA. That way, trivially, all data requests would go at full tilt
until transferred, no more 1 bytes/second transfers, ever. And the
latency would always be 30ms for the first byte as well, always
(again, the first hop only).
Now, would that be best, I don't know. It would come at a cost. That
assumes that routing is sane and takes less than 100% of the
bandwidth. I don't know that that is the case. Certainly, by putting
it first, we could see if the network collapses. If all nodes
instantly lock up doing noting but routing, then, obviously, routing
takes 100% of the bandwidth.
Data certainly would want 100% of the bandwidth, this we've seen from
gnutella, which is way less demanding on the network than freenet ever
can be.
Maybe the way out is to just allocate some fixed portion to routing
and save the problem for another day. Say 10% for routing and 90% for
data. I suspect this is status quo one way or another, though, I
don't recall seeing a stat that had the split as a % bytes of
upstream.
> Why does your browser only do 4 conns at a time? Can't you fix that?
Safari, one day, it will be fixed, one day, there will be instructions
on how to do this in the usual freenet places. Until then... If I
get really bored, I'll grab the sources and puzzle out where the 4 is,
or just file a radar.
YAWaCI:
Oh, and I had a good idea with what to do with the people behind NATs
and firewalls, lets use them as massive routers. They contact lots of
people (until they load), you can ask them questions, they become
expert at what people that connect to them have (aka supernode), and
tell you exacty where to go for the content. We'd use them only on
queries we want to sink into our node. If we wanted to make them
something closer to first class, we could load in our address as a
proxy for them in DF messages when we pass them back and someone that
wants that data would have to contact us with a non-transient identity
(them, or their proxy) and then we'd hand that to the node we proxy
for as a insert that data into this node request, and they, upon
getting it connect out to the named node and inject the content. If
you don't want DDOS floods this would enable, just send a make
connection to X request and when X gets an inbound connection from a
transient node that was in a request we made that had a DF answer with
X in it, then we fire up a Q for the data, and they give it to us as
normal.
Even transients could get/give content to other transients by using
one data intermediary and one request intermediary, which in the grand
freenet style of anonymity, is reasonable.
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
