On May 14, 2009, at 5:06 PM, Matthew Toseland wrote:
> 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 ...
I agree that we don't want to try the local addresses of ~all~ our
peers; local connections are in principal an exception and not cause
enough to be sending so much local garbage handshaking traffic (that
could give away a freenet node).
But I think this is the right way to go... If it is not defined for a
given peer (allow/disallow local connections), then we could just
calculate the default boolean as
his.extAddresses.containsAny(my.extAddresses).... if it matches, then
there is an excellent chance of it being a local connection (99%). If
it changes, that's great! The decision to try local connections would
change too! As it's probably a laptop that has floated out of the LAN
(and we would want to stop sending handshakes to the local address
anyway). At worst we might send a few garbage handshakes to local non-
freenet machine until we connect to the node & find it's new external
address.
The reason I think this would solve the problem because (I think) the
principal reason that the nodes could not communicate is because the
gateway would have to send a packet to itself (many inexpensive or
firewalled ones will not).
e.g.
internal -> firewall -> external (generally works w/ current
countermeasures)
internal -->
firewall
internal <--
Does not work (at least for me). So what I propose is really an
extension of "detecting the problem" (the gateway which has the same
external ip). Don't know about multihoming, but I presume that this is
works in the common case.
>>
>>> 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?
Yep. To the best of my understanding...
Q: How do we determine if we are going to take a remote request?
A: If there is "room" to incur it's expected bandwidth.
Premise-1: all chks transfer at an equal rate
Result-1: new transfers squeeze bandwidth from other transfers.
Result-2: a node will accept any number of transfers until such a
point that all of them would go over the maximum allowed transfer time.
Effectively making every transfer to the slowest-allowed transfer (not
counting local traffic or non-busy nodes). This is why I advocated
lowering the slowest transfer time as a general speedup.
>> 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.
Does that mean that the logical alternative is token passing?
In fact... guarantee-able request acceptance (token passing), might
actually be a logical prerequisite for a fair-queueing system.
Interestingly any node can measure how many requests it can accept
right now (for bandwidth), but only can guess as to it's peers (by
backoff); so then, we may well accept requests which we cannot make
good on, because our peers cannot accept them (ethernet collision
logic at every hop).
>> 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...
Only in that they feed an outbound message queue rather than actually
sending a packet. But it looks to me like a bit of cruft from a
previous design.
In any case, you have a design note in the comments of PacketThrottle
that it would be better to have a sorted list or red/black tree rather
than a ticket system (where all threads wakeup); maybe a new class
needs to be written (BulkQueue) that *only* interleaves waiters (round
robin?) and the packet throttle then used only for actually sending
packets.
--
Robert Hailey
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20090515/7b435577/attachment.html>
