On Friday 05 September 2008 13:54, Michael Rogers wrote:
> Matthew Toseland wrote:
> >> Would it be useful if we could distinguish between peers going offline
> >> and peers dropping the least-recently-used opennet connection - maybe
> >> add an extra field to FNPDisconnect (and assume the peer went offline if
> >> the connection just times out)? 
> > 
> > I think we do this already, don't we?
> 
> Doesn't look like it - OpennetManager calls PeerManager.disconnect,
> which doesn't tell the peer the reason for disconnecting AFAICT.

There are two flags on the FNPDisconnect, iirc one is set if we want the 
distant node to remove our connection (when we drop the LRU connection), and 
isn't set when we're just shutting down.
> 
> >> What other factors do you think might 
> >> bias the sample?
> > 
> > Well for instance on a well established developer's node, the connections 
are 
> > likely to be "good" connections, which tend to be nodes with big stores, 
lots 
> > of bandwidth, and probably high uptimes (as that enables them to gather 
more 
> > data).
> 
> Good point, the measurement node should be separate from any well-known
> nodes (seednodes etc). We could track the average peer lifetime over
> time to see whether long-lived nodes really tend to have long-lived
> peers. If so, I guess short-lived nodes must tend to have short-lived
> peers - maybe that explains some of the problems experienced by new users?

Hmmm, so introduce the node, let it run for a while, record the average peer 
uptime at various stages, then dump it and start again?

Yes I do think that long lived nodes tend to have long lived neighbours. 
Opennet drops the least recently useful node, remember? So "good" nodes will 
tend to have "good" peers, seems a reasonable expectation?
> 
> Cheers,
> Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080905/3a017a70/attachment.pgp>

Reply via email to