![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Song Haibin wrote:
-----Original Message----- From: p2pi-bounces at ietf.org [mailto:p2pi-bounces at ietf.org] On Behalf Of Ted Hardie
...
To my way of thinking, that makes it easier to consider the API design, as it is not so much an API that says "What's the best choice right now?" but "What's the best X (flow pattern, topology, price)". The second set of questions is sufficiently more modular that it is both easier to get right and, at least in my opinion, more interesting. Just my two cents, TedI think it depends on whether the P2P application or the party that provides peer selection information service makes the final choice. IMO, the peer selection information service should provide information to help the p2p application to determine best paths or peers, but not itself makes the final choice.
FWIW, there is a lot of work in peer selection in web cache hierarchies that may be applicable here. Keith Moore's work (SONAR) comes to mind, but there are others.
Come to think of it, there are a lot of analogies between P2P - and P4P - and web cache hierarchies. Has this been explored??
Joe
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ p2pi mailing list p2pi at ietf.org https://www.ietf.org/mailman/listinfo/p2pi