On Sat, 22 Feb 2003 16:47 -0800 Matthew Toseland <toad at amphibian.dyndns.org>
wrote:
> On Sat, Feb 22, 2003 at 01:38:22AM -0800, palomitas at hushmail.com
> wrote:
>>
>> On Sat, 22 Feb 2003 01:21:43 -0800 Anthony Ginepro
>> <anthony.ginepro at laposte.net> wrote:
>>
>>> IMHO, it would be really useful for freenet to make semi-permanent
>>> connections like adsl/cable work better than they are now.
>>
>> Yes. The nodes should learn from previous connection attempts
>> and conclude something like "Well, it seems that this node 'XYZ'
>> is online Monday to Friday from 10am to 9pm GMT. On Saturdays it
>> is online 24hrs and on Sundays it is quite unlikely that it is
>> online."
>>
>> Those deduced rules are adjusted with every further connection
>> attempt and they are used to make the connection attempts when it
>> seems more likely that the other node is available.
>
> Absolutely not. We cannot connect to a node unless it is in the
> routing table. If it is offline, it will be replaced by a node that
> is online, or it will come back online.
Well then there has to be something more than just a routing table. Maybe
there could be a table of known nodes together with their contact probabilities.
This is something we are already doing in real life.
For every friend I have I learned when it is most likely
to contact him on the phone! How about implement this
into Freenet?
I'm thinking that the nodes should keep track of their connection attempts
to other nodes and store it in a table. For a specific node xyz a line
of the table could be visualized in this way:
probability of contact to node xyz
^
| | | | | | |
| | | | | | | *
| * | * | ** | | | ** | **
|*** |**** |*** | |** |**** |****
|**** |**** |**** | |**** |**********
|**** |**** |**** | *** |**** ************
|***********|*****|*****|*****************
******************************************
******************************************
******************************************
******************************************
+-----+-----+-----+-----+-----+-----+-----+-> time
Mon Tue Wed Thu Fri Sat Sun
In reality the resolution of the time should be 1 hour.
The probabilities are mean values of the last x (x=21?) days; older values
weighted lower (a Gaussian curve maybe?).
The node should explore the borders of the peaks in order to detect movement
of that peaks.
>From time to time the node should explore the areas with low contact
probability to detect drastic changes of the behavior of the remote node.
This reduces the failing connection attempts.
This improves load balancing. (A node that has to reject many requests
in "popular" hours receives a lower contact probability so that it is
contacted less often during that time.)
This improves the integration of semi-permanent nodes.
I think it was Ian who said that the other nodes should _announce_ their
up/down times. This is fine, but the node owner should then adjust these
times from time to time. This is very annoying and humans tend to forget
these things.
This announcement can't be much more than an initial guess for the other
node, something to initialize the above-mentioned table of probabilities.
If the node _learns_ automatically of the connection attempts it has
made, it can _adapt_ to the topology of the network and its changes.
--Palomitas de Ma?z
PS: Yes, I did code that already. ;)
Concerned about your privacy? Follow this link to get
FREE encrypted email: https://www.hushmail.com/?l=2
Big $$$ to be made with the HushMail Affiliate Program:
https://www.hushmail.com/about.php?subloc=affiliate&l=427
_______________________________________________
devl mailing list
devl at freenetproject.org
http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
