[Mnet-devel] a bad idea for simplification of MetaTracking/EGTP/PeerMan

[zooko at zooko.com]

This is just an idea I had while looking at the output of "mnetcli status" (appended).

There are two caches of peers reflected in the "mnetcli status", the
"metatracker" cache and the "mtm" cache.

The former is filled when peers send "hello" to you, which happens only if you
are an MT.  The latter is filled when either (a) the peer sends any kind of
message at all to you or (b) you receive a description of that peer in a "list
servers result" message that you received from a MetaTracker.

So the idea was -- suppose there was no "hello" message, and no separate cache,
and MTs just reported on the peers that they happened to know about?

I guess there would be failures in both directions -- On the one hand some
peers would be gone, but since the MT had never needed to query the peer for
anything, they would still be listed as live in the MTs "list servers response"
results.  On the other hand some new peers would be present, but since they
hadn't needed to talk to the MT for anything, they wouldn't be listed in the
results.

Okay, I guess it is a bad idea to get rid of the "hello" message.

However, it might be a good idea to get rid of the MT database, leaving the
"mtm" (actually "peerman") database as the only database of known peers, and
have the "hello" message enter into that database...  Hm.  That would still
leave the "gone peers still listed" problem.  Okay nevermind, I'm going to
prepend the words "a bad" to the Subject line of this message and send it.

--Z


node.status([]):
'node uptime':  '0d 13h 33m 10s'
'router':
    'pusher':
         'have 0, done 0, fail 0 blocks; 4 servers'
         <publishcache #00 /home/zooko/.mnet-META/publishcache CLEAN>
         'flat/lru 0.00MB/500.00MB used (0.00%) CLEAN'
    'blockwrangler':
         'wanting 0 blocks for 0 files'
         'using strategy <KISS 1>'
         <downloadcache #00 /home/zooko/.mnet-META/downloadcache CLEAN>
         'flat/lru 0.00MB/500.00MB used (0.00%) CLEAN'
'metatracker':
     'knowing 5 nodes offering 5 distinct services'
     '    block server: 5 nodes'
     '    content tracker: 4 nodes'
     '    meta tracker: 1 nodes'
     '    publishing block server: 5 nodes'
     '    relay server: 4 nodes'
     '<Peer <33bnp>>: b mp   @ <TCP 25395 seqno 530793 to 213.67.4.86:22088 via None>'
     '<Peer <648yj>>: bc pr  @ <TCP 11550 seqno 1 to 82.48.76.165:32404 via <socket._socketobject object at 0x40c0f2ac>>'
     '<Peer <8fjho>>: bc pr  @ <TCP 25807 seqno 80 to 206.180.144.97:15701 via None>'
     '<Peer <n9sqz>>: bc pr  @ <TCP 25854 seqno 2 to 24.103.161.45:7150 via None>'
     '<Peer <nw31m>>: bc pr  @ <TCP 331 seqno 1 to 69.158.22.60:6453 via <socket._socketobject object at 0x40c17d24>>'
'blockserver':  'not running'
'mtm':  
        <h8ric>:  '0.7a1-140-UNSTABLE'
        'connected nodes':
         '<Peer <33bnp>>:  bp m  @ <TCP 25395 seqno 530793 to 213.67.4.86:22088 via None>'
         '<Peer <648yj>>: rbpc   @ <TCP 11550 seqno 1 to 82.48.76.165:32404 via <socket._socketobject object at 0x40c0f2ac>>'
         '<Peer <8fjho>>: rbpc   @ <TCP 25807 seqno 80 to 206.180.144.97:15701 via None>'
         '<Peer <n9sqz>>: rbpc   @ <TCP 25854 seqno 2 to 24.103.161.45:7150 via None>'
         '<Peer <nw31m>>: rbpc   @ <TCP 331 seqno 1 to 69.158.22.60:6453 via <socket._socketobject object at 0x40c17d24>>'
     <BandwidthThrottler IN 0.32/56k 1/5Hz 9.05k peak>
     <BandwidthThrottler OUT 1.11/56k 1/5Hz 16.52k peak>
'underboss':
    'current commands':  []
    'active commands':  []
    'completed commands':  []
'relayserver':  'not running'