On Thursday 14 May 2009 20:36:31 Robert Hailey wrote: > > 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?
Not very (what if it changes?) ... we don't want darknet peers to cause us to connect to addresses on our LAN ... otherwise the solution is simply to try the local addresses included ... > > > 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. Possibly. It is indeed a load balancing problem. Queueing will help, or maybe simulated queueing. > > I think this conflicts with the current throttling mechanism; piling > on requests till one or both nodes say 'enough', Is this how it works now? > 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. Yes, it is very much like that. > > 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). Good idea... I thought it was somewhat like that already? It is important in some cases for it to block... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090514/240944ea/attachment.pgp>
