[mnet-devel] BW unit tests
icepick at icepick.info
icepick at icepick.info
Sat Feb 15 14:50:02 GMT 2003
On Fri, Feb 14, 2003 at 06:02:05AM -0500, Zooko wrote:
>
> icepick wrote:
> >
> > 2003-02-07_05:54:00 () peers = self.sort_peers_by_queries(self.mtm._handicapper.sort_by_preference_from_dict_of_Peers(outcome, "do you have blobs", {}))
> >
> > My question to zooko: how much does BW need to knoe about the internals of
> > MojoTransactionManger? This weighs in on how much we can say the network
> > code is seprate from the app code.
>
> I suggest that we eliminate handicappers from _new.
>
> There are currently only two left in _new compared to about 8 or 10 in _old.
> I say we eliminate those two, extirpate the whole concept of handicappers, and
> write a new BlockWranglingStrategy that doesn't use that concept.
>
> (Well, of course it can use the concept of sorting peers by preference,
> internally to itself, but it doesn't use the concept of invoking a global
> handicapper function which is held in mtm._handicapper.)
>
> By the way, BlockWranglingStrategy.KISS uses handicappers in only one single
> place -- when it calls
> "list_sorted_peers_without_outstanding_searches_and_callback()".
> BlockWranglingStrategy.GSR uses that, and it also uses
> "pick_best_peer_who_claimed_block()", so it has two places that would have to be
> changed.
Why not move the handicapper stuff into Node? Or are you saying that the
handicapper is still needed by egtp for network ops, and that we should
invent something new for the application layer?
myers
--
You're just jealous because the voices only talk to me.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
mnet-devel mailing list
mnet-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mnet-devel
More information about the Mnet-devel
mailing list