Improve Kademlia peer management (Trac #1357)

[str4d]

old unresponsive peers should be expulsed from the list as the lock up much, while active peers be exchanged between connected peers and also if an unknown peer connects to you, you save his info.

ref: http://forum.i2p/viewtopic.php?t=11477

normal kad is about finding files n downloading a file from a source that we have no influence on whether it goes off or stays on. In Bote we cannot influence the other's behaviour either, but there's a difference: we don't want their files, we want to upload ours, so some better profiling of reliability of kad peers (storage nodes)should take place, this could greatly improve reliability without raising redundancy. Yet for obvious reasons not exclusively the best performing nodes should be chosen, but alwaays have a small margin of "normal" ones too. profiling factors could be general reachability/responsiveness, received own mails (so they do not block my dest), and received receipt confirmations (so they do not block/censor the destinataries), automated test mails, overall uptime (time we know the node). Sounds easier than it is, though. If only one of my destinataries is blocked, the mails to others will still arrive and I'll get receipt confs for them and hence a positive evaluation of the storage node, even though it misbehaves. Maybe if another storage node gives me the confirmation and the one in question is closer to the key and does not, then punish strongly - not an immediate ban, but a quite noticeable punishment.

Migrated from https://trac.i2p2.de/ticket/1357

{
    "status": "assigned", 
    "changetime": "2017-01-15T15:28:10", 
    "description": "old unresponsive peers should be expulsed from the list as the lock up much, while active peers be exchanged between connected peers and also if an unknown peer connects to you, you save his info.\n\nref: http://forum.i2p/viewtopic.php?t=11477\n\nnormal kad is about finding files n downloading a file from a source that we have no influence on whether it goes off or stays on. In Bote we cannot influence the other's behaviour either, but there's a difference: we don't want their files, we want to upload ours, so some better profiling of reliability of kad peers (storage nodes)should take place, this could greatly improve reliability without raising redundancy. \nYet for obvious reasons not exclusively the best performing nodes should be chosen, but alwaays have a small margin of \"normal\" ones too. \nprofiling factors could be general reachability/responsiveness, received own mails (so they do not block my dest), and received receipt confirmations (so they do not block/censor the destinataries), automated test mails, overall uptime (time we know the node). Sounds easier than it is, though. If only one of my destinataries is blocked, the mails to others will still arrive and I'll get receipt confs for them and hence a positive evaluation of the storage node, even though it misbehaves. Maybe if another storage node gives me the confirmation and the one in question is closer to the key and does not, then punish strongly - not an immediate ban, but a quite noticeable punishment.", 
    "reporter": "user", 
    "cc": "", 
    "resolution": "", 
    "_ts": "1484494090875098", 
    "component": "apps/plugins", 
    "summary": "Bote peer management", 
    "priority": "minor", 
    "keywords": "I2P-Bote performance", 
    "version": "0.9.14.1", 
    "parents": "", 
    "time": "2014-08-24T22:23:37", 
    "milestone": "", 
    "owner": "str4d", 
    "type": "enhancement"
}

[str4d]

Trac update at 20140826T12:39:31: str4d changed description from:

old unresponsible peers should be expulsed from the list as the lock up much, while active peers be exchanged between connected peers and also if an unknown peer connects to you, you save his info.

ref: http://forum.i2p/viewtopic.php?t=11477

normal kad is about finding files n downloading a file from a source that we have no influence on whether it goes off or stays on. In Bote we cannot influence the other'S behaviour either, but there's a difference: we don't want their files, we want to upload ours, so some better profilig of reliability of kad peers (storage nodes)should take place, this could greatly improve reliability without raising redundancy. Yet for obvious reasons not exclusively the best performing nodes should be chosen, but alwaays have a small margin of "normal" ones too. profiling factors could be genral reachability/responsivenes, received own mails (so they do not block my dest), and received receipt confirmations (so they do not block/censor the destinataries), autotmated test mails, overall uptime (time we know the node). Sounds easier than it is, though. If only one of my destinataries is blocked, the mails to others will still arrive and I'll get receipt confs for them and hence a positive evaluation of the storage node, even though it misbehaves. Maybe if another storage node gives me the confirmation and the one in question is clser to the key and does not, then punisch strongly - not an immediate ban, but a quite noticeable punishment.

to:

old unresponsive peers should be expulsed from the list as the lock up much, while active peers be exchanged between connected peers and also if an unknown peer connects to you, you save his info.

ref: http://forum.i2p/viewtopic.php?t=11477

normal kad is about finding files n downloading a file from a source that we have no influence on whether it goes off or stays on. In Bote we cannot influence the other's behaviour either, but there's a difference: we don't want their files, we want to upload ours, so some better profiling of reliability of kad peers (storage nodes)should take place, this could greatly improve reliability without raising redundancy. Yet for obvious reasons not exclusively the best performing nodes should be chosen, but alwaays have a small margin of "normal" ones too. profiling factors could be general reachability/responsiveness, received own mails (so they do not block my dest), and received receipt confirmations (so they do not block/censor the destinataries), automated test mails, overall uptime (time we know the node). Sounds easier than it is, though. If only one of my destinataries is blocked, the mails to others will still arrive and I'll get receipt confs for them and hence a positive evaluation of the storage node, even though it misbehaves. Maybe if another storage node gives me the confirmation and the one in question is closer to the key and does not, then punish strongly - not an immediate ban, but a quite noticeable punishment.

[str4d]

Trac update at 20140827T23:52:09: user commented:

might also be of importance in light of android users. maybe they'll not be online long in order to save battery or data transfer. while using those as storage nodes would increase entropy it would also make things much more unreliable and latencies much bigger.

[str4d]

Trac update at 20140928T15:18:54:

• zzz changed owner from "" to "HungryHobo"
• zzz changed status from "new" to "assigned"

[str4d]

Trac update at 20150110T04:13:02:

• str4d changed keywords from "I2P-Bote, peer management" to "I2P-Bote performance"
• str4d changed milestone from "0.9.18" to ""

[str4d]

Trac update at 20170115T15:28:10: zzz changed owner from "HungryHobo" to "str4d"