On May 14, 2009, at 12:17 PM, Matthew Toseland wrote:

> Because we were both on the same LAN, it did not connect, until I  
> told him to
> set it to allow local addresses on that peer. There should be a  
> checkbox when
> adding a noderef, defaulting to on, "Friend may be on the same local  
> network
> as me" or something. (#3098)

I think that it should be possible to automatically detect this.  
Specifically, if we detect that our peer has the same "external  
address" as us, try and connect locally. Is that a reliable indicator?

> Once connected to my node, it repeatedly RNFed on the top block of  
> TUFI.
> Performance with one peer is expected to be poor, but it is worse  
> than IMHO
> it could be. Some sort of fair sharing scheme ought to allow a  
> darknet peer
> that isn't doing much to have a few requests accepted while we are  
> rejecting
> tons of requests from other darknet peers and opennet peers. (#3101)

I second that, but I'm not sure as to the best implementation.

On the surface this appears to be the same issue as balancing local/ 
remote requests. i.e. if your node is busy doing everyone else's work,  
your requests should take clear advantage when you finally get around  
to clicking a link.

I think this conflicts with the current throttling mechanism; piling  
on requests till one or both nodes say 'enough', and if we reserve  
some space we will not hit our bandwidth goal. Or that requests are  
actually "competing" like collisions on a busy ethernet channel rather  
than having an order.

One thing that I was playing around with earlier was re-factoring  
PacketThrottle to be viewed from the queue-side. Rather than  
"sendThrottledPacket" blocking till "a good time" to enqueue a message  
based on the throttle, that all the packets would be serially  
available interleaved (e.g. PacketThrottle.getBulkPackets(n); returns  
the next 'n' packets).

--
Robert Hailey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20090514/e97a652f/attachment.html>

Reply via email to