[mnet-devel] v0.7 and v0.8 (was: [ mnet-Bugs-850502 ] port newoldmetatracking and peerman to v0.7)

[Zooko O'Whielacronx]

>From mnet-bugs:

> https://sourceforge.net/tracker/?func=detail&atid=436453&aid=850502&group_id=43482
> 
> Category: Network / EGTP
> Group: v0.7
> Status: Open
> Resolution: None
> >Priority: 9
> Submitted By: Zooko O'Whielacronx (zooko)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: port newoldmetatracking and peerman to v0.7
> 
> Initial Comment:
> the recent patches to v0.6.2 ought to be ported to v0.7.
> 
> we should probably make a branch of v0.7 which is
> stablish so that people can run MTs, blockservers,
> etc., without suffering from unstable devel work...
...
> >Comment By: Myers Carpenter (myers_carpenter)
> 
> This is really important to me.

So we have a general agreement that v0.7 will be current stuff plus content 
tracking and a GUI, right?

And v0.8 will be the branch for disruptive stuff like Twistification, EGTPv2, 
DHT routing, or whatever.

Now this particular issue -- "port newoldmetatracking and peerman to v0.7" -- 
has a wrinkle which is that while v0.6.2 has peerman, which provides lookup 
service ("lookup current comm strat for this peer") and discovery service 
("list all known probably-active servers of a a given type"), and which does 
exponential backoff on retrying of unresponsive servers, v0.7 already has 
peerset, which provides an object-oriented interface to which peer, what 
services she offers, and what comm strat we use to talk to her.

These two ought to be merged, which should result in less code overall.

By "object-oriented interface" I mean that in v0.6.2 (with no peerset), you 
pass around a nodeId, which is a 20-byte unique string, and in v0.7 (with 
peerset), you pass around a Peer instance.

In the old code if you want to find out what comm strat to use to talk to that 
node you invoke a method of CryptoCommsHandler or peerman (depending on what 
you want to know exactly) and pass the nodeId.  In the new code if you want to 
find out what comm strat to use to talk to that node you say 
"mypeer.get_comm_strategy()" or something like that.

Similarly in the old code when you want to send a "do you have blocks" message 
to a peer, you call 

mymojotransactionmanager.initiate(peerId, "do you have blocks", blockIds, outcome_func, post_timeout_outcome_func)

In the new code, you would call

mypeer.do_you_have_blocks(blockIds, ophandler)

Similarly, in the old code when you want to find out what the average 
reliability has historically been for a certain peer, you do something like

mymojotransactionmanager.counterparty_object_keeper.get_counterparty(peerId).get_reliability()

In the new code, you would do

mypeer.get_reliability()


Now as you can see this is really more about unifying related data and related 
functionality into a single class more than about changing interfaces.  It is 
a potentially disruptive change, as anybody who does it will want to 
completely tear up CryptoCommsHandler, MojoTransactionManager, 
ConversationManager, CounterpartyObjectKeeper, SessionKeeper, and so forth and 
just write a fresh new class which unifies all of the functionality that they 
provide, in addition to the functionality that peerman and peerset provide.

Well, that is true if "anybody who does it" means "Zooko who does it".  :-)

So maybe this is a job for v0.8, and someone should do some less ambitious 
merge of peerman into v0.7.  I personally don't much like the idea of doing 
that kind of work in v0.7 -- the "keep on getting along with legacy code like 
MojoTransactionManager" kind of work, I mean.  I've been doing it for v0.6.2 
and consoling myself that this was the last time I would have to do it.  :-)

Really, if you don't mind holding your nose and just doing it, peerman 
probably ports right across into v0.7.  peerman replaced MetaTrackerLib in 
v0.6.2, and v0.7 currently uses that same MetaTrackerLib with the same 
interface as far as I know.


Here are four other issue tracker entries that are closely related to this 
e-mail:

[ 678902 ] Remove all refs to MojoTransactionManager from mnetlib
https://sourceforge.net/tracker/index.php?func=detail&aid=678902&group_id=43482&atid=436453
(You should use the Peer object or else a lookup or discovery manager instead 
of MojoTransactionManager.)

[ 679616 ] Remove all direct calls to MetaTrackLib and replace with calls to node.lookup_manager or node.discovery_manager
https://sourceforge.net/tracker/index.php?func=detail&aid=679616&group_id=43482&atid=436453
(peerman provides the lookup and discovery manager services.)

[ 831741 ] refactor relay to use Peer instances instead of peerIds
https://sourceforge.net/tracker/index.php?func=detail&aid=831741&group_id=43482&atid=436453

[ 650159 ] cleanup: peer relationships
https://sourceforge.net/tracker/index.php?func=detail&aid=650159&group_id=43482&atid=436453
(This is just a general issue report which basically covers everything 
I've written about in this e-mail.)


--Z



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel