From toscano_moura at hotmail.com Tue Mar 1 00:30:07 2005 From: toscano_moura at hotmail.com (Hermano Toscano Moura) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] Data Replication on FreePastry 1.3.2 Message-ID: Hi There... Did anyone here work or are still working with data replication on FreePastry 1.3.2? I have some doubts and I wanna talk with someone that has some knowledge in this subject!!! Thanks in advance... Hermano Toscano From amislove at rice.edu Tue Mar 1 02:01:28 2005 From: amislove at rice.edu (Alan Mislove) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] Data Replication on FreePastry 1.3.2 In-Reply-To: References: Message-ID: Hermano - I'm a member of the FreePastry group at Rice, and FreePastry is still very much in active development. I wrote most of the replication code, so please feel free to email me with any questions or doubts you may have. Thanks! Alan Mislove On Tue, 1 Mar 2005, Hermano Toscano Moura wrote: > > Hi There... > Did anyone here work or are still working with data replication on > FreePastry 1.3.2? I have some doubts and I wanna talk with someone that has > some knowledge in this subject!!! > Thanks in advance... > > Hermano Toscano > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From nlothian at educationau.edu.au Tue Mar 1 04:35:43 2005 From: nlothian at educationau.edu.au (Nick Lothian) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] SSM for Java? Message-ID: Dumb question: What is single-source multicast and how does it differ from normal multicast? Multicast is pretty easy in Java (without JNI): http://javaalmanac.com/egs/java.net/WriteMulticast.html. -- Nick (Lothian) > -----Original Message----- > From: p2p-hackers-bounces@zgp.org > [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Nick Johnson > Sent: Monday, 28 February 2005 9:23 PM > To: Peer-to-peer development. > Subject: [p2p-hackers] SSM for Java? > > Has anyone come across a single-source-multicast library for > Java, possibly using JNI? I've seen tantalizing hints of one, > but no actual code. > > -Nick Johnson From arachnid at notdot.net Tue Mar 1 20:38:56 2005 From: arachnid at notdot.net (Nick Johnson) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] SSM for Java? In-Reply-To: References: Message-ID: <4cd2e6ea246f0811b3aa6c0e2099b091@notdot.net> Source-specific multicast (my original message was a typo) is an improvement on standard multicast using IGMPv3 that allows the receivers to specify the source IP of messages they want to receive. This prevents spoofing (to some extent, at least), and more importantly makes the job of routing multicast feeds much easier for the routers. -Nick Johnson On 1/03/2005, at 5:35 PM, Nick Lothian wrote: > Dumb question: What is single-source multicast and how does it differ > from normal multicast? > > Multicast is pretty easy in Java (without JNI): > http://javaalmanac.com/egs/java.net/WriteMulticast.html. > > -- Nick (Lothian) > >> -----Original Message----- >> From: p2p-hackers-bounces@zgp.org >> [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Nick Johnson >> Sent: Monday, 28 February 2005 9:23 PM >> To: Peer-to-peer development. >> Subject: [p2p-hackers] SSM for Java? >> >> Has anyone come across a single-source-multicast library for >> Java, possibly using JNI? I've seen tantalizing hints of one, >> but no actual code. >> >> -Nick Johnson > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > !DSPAM:4223f0c369855575466356! > From yariv at pando.com Fri Mar 4 16:14:41 2005 From: yariv at pando.com (Yariv Sadan) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] UDP hole punching performance Message-ID: <4c38c004d09f6b588c80a61971fbee7c@pando.com> Hello, A colleague told me recently that UDP hole punching is "slow." That is, if you transfer data between 2 NATed hosts through a UDP punched hole and by using a reliable UDP type of protocol, you would get lower transfer speeds than by using a direct TCP connection. In other words, he claims that UDP hole punching somehow reduces the connection's throughput. I, personally, don't see a reason for this statement to be true; however, I've never ran measurements myself so I can't confirm or discredit it. Does anybody with experience in this area know if there's any truth to this statement? Thanks, Yariv From matthew at matthew.at Fri Mar 4 16:41:35 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] UDP hole punching performance In-Reply-To: <4c38c004d09f6b588c80a61971fbee7c@pando.com> Message-ID: <013d01c520d9$0aabf200$02c7cac6@matthewdesk> Yariv Sadan writes: > A colleague told me recently that UDP hole punching is "slow."... That is only true if the UDP transfer protocol you implement has lower performance than TCP. Our MFP protocol does encrypted transfers over UDP, including full support in the MFPNet layer for UDP hole punching between two behind-NAT devices, at rates which at least equal and can actually exceed TCP performance (because we scale more appropriately for high delay*bandwidth, and because we have definitive selective-acknowledgements; and if you're transferring more than one stream of data, because we share congestion state)... See www.amicima.com for more. It is possible to do it less efficiently. For instance, we provide support for multiple streams with prioritization, so we can do simultaneous VOIP and file transfer with no impact to the voice. So can Skype... But on a cross-country connection, our file transfers have clocked at 11-18 *times* faster than Skype's current implemntation of file transfer over UDP. Matthew From ap at hamachi.cc Fri Mar 4 16:48:38 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] UDP hole punching performance In-Reply-To: <4c38c004d09f6b588c80a61971fbee7c@pando.com> References: <4c38c004d09f6b588c80a61971fbee7c@pando.com> Message-ID: <42289166.6050301@hamachi.cc> It 100% protocol-specific problem and not related to UDP/hp. The behaviour your friend saw might've been caused by an excessive IP fragmentation or inefficient ACKing or some other design flaw or an artefact of a reliable UDP protocol being used. Plain and simple IP-in-UDP encapsulation for packets received from a TUN/TAP device has a near zero performance hit. Just remember to either decrease TUN/TAP device MTU or be sure to preserver IP/DF flag when encapsulating the traffic (this is needed to allow for Path MTU discovery). Alex Yariv Sadan wrote: > Hello, > > A colleague told me recently that UDP hole punching is "slow." That is, > if you transfer data between 2 NATed hosts through a UDP punched hole > and by using a reliable UDP type of protocol, you would get lower > transfer speeds than by using a direct TCP connection. In other words, > he claims that UDP hole punching somehow reduces the connection's > throughput. I, personally, don't see a reason for this statement to be > true; however, I've never ran measurements myself so I can't confirm or > discredit it. Does anybody with experience in this area know if there's > any truth to this statement? > > Thanks, > Yariv > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > From ap at hamachi.cc Fri Mar 4 16:53:20 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] UDP hole punching performance In-Reply-To: <013d01c520d9$0aabf200$02c7cac6@matthewdesk> References: <013d01c520d9$0aabf200$02c7cac6@matthewdesk> Message-ID: <42289280.8090907@hamachi.cc> Matthew Kaufman wrote: > Yariv Sadan writes: > > ... But on a > cross-country connection, our file transfers have clocked at 11-18 *times* > faster than Skype's current implemntation of file transfer over UDP. > Do you make this comparison with two Skype clients residing behind two different NAT devices ? AFAIK in this case Skype won't be doing hole punching and be relaying the traffic through a third node instead. It will also rate-limit the transfer to a max of 5KB/sec (?). From matthew at matthew.at Fri Mar 4 19:31:06 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] UDP hole punching performance In-Reply-To: <42289280.8090907@hamachi.cc> Message-ID: <014701c520f0$b9473a60$02c7cac6@matthewdesk> Alex Pankratov: > Do you make this comparison with two Skype clients residing > behind two different NAT devices ? I don't remember those details, see below. > AFAIK in this case Skype won't be doing hole punching and > be relaying the traffic through a third node instead. It > will also rate-limit the transfer to a max of 5KB/sec (?). In both cases, I checked with tcpdump, and UDP was the only protocol in use and the traffic was going directly between the two computers involved. My experience is that the throughput scales linearly with latency in a way that would be explained if they don't use a sliding window at all, or certainly not a big enough one. Who knows... Might be rate-limited too - the point is that there are UDP applications that are slower than doing a file transfer over TCP (FTP, HTTP), and Skype is an example. Matthew From wtracz at yahoo.co.uk Sun Mar 6 16:10:00 2005 From: wtracz at yahoo.co.uk (William Tracz) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] Content validation with KARMA and other anti-free loading mechanisms Message-ID: <20050306161000.78312.qmail@web25702.mail.ukl.yahoo.com> I have recently been looking at the KARMA system of free load prevention and was wondering if it is at all possible (without centralisation) to authenticate/validate the content transmitted. By this I mean is there any way without a centralised bank-set to restrict credit being awarded to people sending certain files - mainly illegal content. I have thought long and hard about it and can not see any way that this is possible? I am taking for granted that on the network I can freely modify files (i.e add digital signatures etc. to them) to help the process. Is centralisation the only unfortunate answer? WT ( The KARMA paper can be found here: http://mnl.cs.sunysb.edu/home/karthik/BitTorrent/papers/incentives/karma.pdf the BitTorrent reference is deceptive, it seems to be for an eDonkey style network ) Send instant messages to your online friends http://uk.messenger.yahoo.com From eugen at leitl.org Mon Mar 7 10:49:34 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] [i2p] ANN: XML-RPC over I2P (fwd from david@rebirthing.co.nz) Message-ID: <20050307104934.GM13336@leitl.org> ----- Forwarded message from David McNab ----- From: David McNab Date: Mon, 07 Mar 2005 23:39:21 +1300 To: i2p@i2p.net Subject: [i2p] ANN: XML-RPC over I2P User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Hi all, For the last day, I've been playing with running XML-RPC servers over I2P. Thanks to eeProxy, and the fact that XML-RPC is done over straight HTTP, the task of getting XML-RPC working over I2P is very simple, just a few steps: 1) get the XML-RPC server up and running 2) with the I2P routerConsole, create a server tunnel for this XML-RPC server 3) for XML-RPC clients using this server, configure these to use I2P's eeProxy as an http proxy server, and 'http://my.xmlrpc-server.i2p' or 'http://i2p/destbase64string' as the URI With the Python XMLRPC client library, 'xmlrpclib', there's one very annoying oversight - no provision for an http proxy. So I've stuck up a python lib on www.freenet.org.nz/i2pxmlrpc.py This lib defines a class 'I2PXMLRPCServerProxy' which takes care of all this. You just instantiate it with a base64 dest (or a hosts.txt hostname), and use it as desired. The lib file can be executed, which will run a demo. -- Cheers David _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050307/e9a80b27/attachment.pgp From sam at neurogrid.com Tue Mar 8 02:05:09 2005 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] Final CFP: Agents and P2P Computing (AP2PC 2005) Message-ID: <422D0855.80901@neurogrid.com> *** our apologies if you receive multiple copies of this e-mail *** -------------------------------------------------- FINAL CALL FOR PAPERS AGENTS AND P2P COMPUTING (AP2PC 2005) -------------------------------------------------- Fourth International Workshop on Agents and Peer-to-Peer Computing (AP2PC 2005) http://p2p.ingce.unibo.it/ to be held at AAMAS 2005 http://www.aamas2005.nl/ Fourth International Joint Conference on Autonomous Agents and Multi Agent Systems Utrecht, Netherlands July 25-29, 2005 Utrecht University CALL FOR PAPERS Peer-to-peer (P2P) computing has attracted enormous media attention, initially spurred by the popularity of file sharing systems such as Napster, Gnutella, and Morpheus. More recently systems like BitTorrent and eDonkey have continued to sustain that attention. New techniques such as distributed hash-tables (DHTs), semantic routing, and Plaxton Meshes are being combined with traditional concepts such as Hypercubes, Trust Metrics and caching techniques to pool together the untapped computing power at the "edges" of the internet. These new techniques and possibilities have generated a lot of interest in many industrial organizations, and has resulted in the creation of a P2P working group on standardization in this area. (http://www.irtf.org/charters/p2prg.html). In P2P computing peers and services forego central coordination and dynamically organise themselves to support knowledge sharing and collaboration, in both cooperative and non-cooperative environments. The success of P2P systems strongly depends on a number of factors. First, the ability to ensure equitable distribution of content and services. Economic and business models which rely on incentive mechanisms to supply contributions to the system are being developed, along with methods for controlling the "free riding" issue. Second, the ability to enforce provision of trusted services. Reputation based P2P trust management models are becoming a focus of the research community as a viable solution. The trust models must balance both constraints imposed by the environment (e.g. scalability) and the unique properties of trust as a social and psychological phenomenon. Recently, we are also witnessing a move of the P2P paradigm to embrace mobile computing in an attempt to achieve ! even higher ubiquitousness. The possibility of services related to physical location and the relation with agents in physical proximity could introduce new opportunities and also new technical challenges. Although researchers working on distributed computing, MultiAgent Systems, databases and networks have been using similar concepts for a long time, it is only fairly recently that papers motivated by the current P2P paradigm have started appearing in high quality conferences and workshops. Research in agent systems in particular appears to be most relevant because, since their inception, MultiAgent Systems have always been thought of as collections of peers. The MultiAgent paradigm can thus be superimposed on the P2P architecture, where agents embody the description of the task environments, the decision-support capabilities, the collective behavior, and the interaction protocols of each peer. The emphasis in this context on decentralization, user autonomy, dynamic growth and other advantages of P2P, also leads to significant potential problems. Most prominent among these problems are coordination: the ability of an agent to make decisions on its own actions in the context of activities of other agents, and scalability: the value of the P2P systems lies in how well they scale along several dimensions, including complexity, heterogeneity of peers, robustness, traffic redistribution, and so forth. It is important to scale up coordination strategies along multiple dimensions to enhance their tractability and viability, and thereby to widen potential application domains. These two problems are common to many large-scale applications! . Without coordination, agents may be wasting their efforts, squander resources and fail to achieve their objectives in situations requiring collective effort. This workshop will bring together researchers working on agent systems and P2P computing with the intention of strengthening this connection. Researchers from other related areas such as distributed systems, networks and database systems will also be welcome (and, in our opinion, have a lot to contribute). We seek high-quality and original contributions on the general theme of "Agents and P2P Computing". The following is a non-exhaustive list of topics of special interest: * Intelligent agent techniques for P2P computing * P2P computing techniques for multi-agent systems * The Semantic Web, Semantic Coordination Mechanisms and P2P systems * Scalability, coordination, robustness and adaptability in P2P systems * Self-organization and emergent behavior in P2P networks * E-commerce and P2P computing * Participation and Contract Incentive Mechanisms in P2P Systems * Computational Models of Trust and Reputation * Community of interest building and regulation, and behavioral norms * Intellectual property rights in P2P systems * P2P architectures * Scalable Data Structures for P2P systems * Services in P2P systems (service definition languages, service discovery, filtering and composition etc.) * Knowledge Discovery and P2P Data Mining Agents * P2P oriented information systems * Information ecosystems and P2P systems * Security issues in P2P networks * Pervasive computing based on P2P architectures (ad-hoc networks, wireless communication devices and mobile systems) * Grid computing solutions based on agents and P2P paradigms * legal issues in P2P networks PANEL The theme of the panel will be Decentralised Trust in P2P and MultiAgent Systems. As P2P and MultiAgent systems become larger and more diverse the risks of interacting with malicious peers become increasingly problematic. The panel will address how computational trust issues can be addressed in P2P and MultiAgent systems. The panel will involve short presentations by the panelists followed by a discussion session involving the audience. IMPORTANT DATES Paper submission: 14th March 2005 Acceptance notification: 18th April 2005 Workshop: 25th or 26th July 2005 Camera ready for post-proceedings: 20th September 2005 SUBMISSION INSTRUCTIONS Unpublished papers should be formatted according to the LNCS/LNAI http://www.springer.de/comp/lncs/authors.html author instructions for proceedings and they should not be longer than 12 pages (about 5000 words including figures, tables, references, etc.). Please submit your papers through the Microsoft conference management system: https://msrcmt.research.microsoft.com/AP2PC2005/CallForPapers.aspx Particular preference will be given to those papers that build upon the contributions of papers presented at previous AP2PC workshops. In addition, please carefully consider the issues that our reviewers will be considering. Some of the issues our reviewers will be considering can be seen in this form: Sample Reviewers form http://www.neurogrid.net/ap2pc2005/review-form.html At the very least we would encourage all authors to read the abstracts of the papers submitted to previous workshops - available from the links in the following section. PUBLICATION Accepted papers will be distributed to the workshop participants as workshop notes. Post-proceedings of the revised papers (namely accepted papers presented at the workshop) will be published by Springer - Lecture Notes in Computer Science series (LNCS http://www.springer.de/comp/lncs/fcp2003.html#jul) Here are the volumes of revised and invited papers of preceding editions: LNCS volume no. 2530 http:/www.springeronline.com/sgw/cda/frontpage/0,11855,5-40109-22-2991818-0,00.html for AP2PC'2002 http://p2p.ingce.unibo.it/2002/ LNCS volume no. 2872 http:/www.springeronline.com/sgw/cda/frontpage/0,11855,5-40109-22-37060961-0,00.html for AP2PC'2003 http://p2p.ingce.unibo.it/2003/ EXECUTIVE COMMITTEE ORGANIZERS Program Co-chairs Zoran Despotovic School of Computer and Communication Sciences, EPFL CH-1015 Lausanne, Switzerland Email: zoran.despotovic@epfl.ch Sam Joseph (main contact) Dept. of Information and Computer Science, University of Hawaii at Manoa, USA 1680 East-West Road, POST 309, Honolulu, HI 96822 E-mail: srjoseph@hawaii.edu Claudio Sartori Dept. of Electronics, Computer Science and Systems, University of Bologna, Italy Viale Risorgimento, 2 - 40136 Bologna Italy E-mail: claudio.sartori@unibo.it Panel Chair Omer Rana School of Computer Science, Cardiff University, UK Queen's Buildings, Newport Road, Cardiff CF24 3AA, UK E-mail: o.f.rana@cs.cardiff.ac.uk STEERING COMMITTEE Karl Aberer, EPFL, Lausanne, Switzerland Sonia Bergamaschi, Dept. of Science Engineering, University of Modena and Reggio-Emilia, Italy Manolis Koubarakis, Dept. of Electronic and Computer Engineering, Technical University of Crete Paul Marrow, Intelligent Systems Laboratory, BTexact Technologies, UK Gianluca Moro, Dept. of Electronics, Computer Science and Systems, Univ. of Bologna, Cesena, Italy Aris M. Ouksel, Dept. of Information and Decision Sciences, University of Illinois at Chicago, USA Claudio Sartori, CNR-CSITE, University of Bologna, Italy Munindar P. Singh, Dept. of Computer Science, North Carolina State University, USA PROGRAM COMMITTEE Karl Aberer, EPFL, Lausanne, Switzerland Alessandro Agostini, ITC-IRST, Trento, Italy Djamal Benslimane, Universite Claude Bernard, France Sonia Bergamaschi, University of Modena and Reggio-Emilia, Italy M. Brian Blake, Georgetown University, USA Rajkumar Buyya, University of Melbourne, Australia Paolo Ciancarini, University of Bologna, Italy Costas Courcoubetis, Athens University of Economics and Business, Greece Yogesh Deshpande, University of Western Sydney, Australia Asuman Dogac, Middle East Technical University, Turkey Boi V. Faltings, EPFL, Lausanne, Switzerland Maria Gini, University of Minnesota, USA Dina Q. Goldin, University of Connecticut, USA Chihab Hanachi, University of Toulouse, France Willem Jonker, Philips, Netherlands Mark Klein, Massachusetts Institute of Technology, USA Matthias Klusch, DFKI, Saarbrucken, Germany Tan Kian Lee, National University of Singapore, Singapore Zakaria Maamar, Zayed University, UAE Wolfgang Mayer, University of South Australia, Australia Dejan Milojicic, Hewlett Packard Labs, USA Alberto Montresor, University of Bologna, Italy Luc Moreau, University of Southampton, UK Jean-Henry Morin, University of Geneve, Switzerland Andrea Omicini, University of Bologna, Italy Maria Orlowska, University of Queensland, Australia Aris. M. Ouksel, University of Illinois at Chicago, USA Mike Papazoglou, Tilburg University, Netherlands Paolo Petta, Austrian Research Institute for AI, Austria, Jeremy Pitt, Imperial College, UK Dimitris Plexousakis, Institute of Computer Science, FORTH, Greece Martin Purvis, University of Otago, New Zealand Omer F. Rana, Cardiff University, UK Douglas S. Reeves, North Carolina State University, USA Thomas Risse, Fraunhofer IPSI, Darmstadt, Germany Pierangela Samarati, University of Milan, Italy Heng Tao SHEN, ITEE, UQ, Australia Christophe Silbertin-Blanc, University of Toulouse, France Maarten van Steen, Vrije Universiteit, Netherlands Katia Sycara, Robotics Institute, Carnegie Mellon University, USA Heng Tao, University of Queensland, Australia Peter Triantafillou, Technical University of Crete, Greece Anand Tripathi, University of Minnesota, USA Vijay K. Vaishnavi, Georgia State University, USA Francisco Valverde-Albacete, Universidad Carlos III de Madrid, Spain Maurizio Vincini, University of Modena and Reggio-Emilia, Italy Fang Wang, BTexact Technologies, UK Gerhard Weiss, Technische Universitaet, Germany Bin Yu, North Carolina State University, USA Franco Zambonelli, University of Modena and Reggio-Emilia, Italy From zooko at zooko.com Tue Mar 8 21:04:46 2005 From: zooko at zooko.com (Zooko O'Whielacronx) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] good-bye, Mnet, and good luck. I'm going commercial! plus my last design doc Message-ID: <1d5d3191f0742472fddb96de3319794f@zooko.com> contents of this message: "good-bye, Mnet", "The Fully Connected Topology", "Rate-Limited Structured Flood", "A Nice Slow Network", "Did you say 'BROADCAST SEARCH'?" "Persistent Tit-for-Tat == Bilateral Accounting" Dear mnet-devel and p2p-hackers: I am about to accept an exciting job that will preclude me from contributing to open source projects in the distributed file-system space. I will miss the Mnet project! Good luck without me! I'm writing the following as a record of the most advanced design that I have thought of for Mnet. (See Acknowledgements section below.) Most or all of the design written below has previously been published in different web pages, e-mail messages, and IRC transcripts, and a brief presentation I made at Privacy Enhancing Technologies Workshop 2004. The design described below is almost but not quite what is currently implemented, by myself and others, in Mnet v0.7, available at [1]. *** Design of Mnet v0.7+: I. Network connectivity -- the Fully Connected Topology I.A. Local peer database. Each node remembers the nodeId of for each node that it has ever heard of or received a message from. There is a maximum number of nodeIds, in deference to memory and computation costs (your local memory and your local computation). I don't know what that maximum number should be. If you have more than the maximum number of nodeIds in your database, you can flush some of the least-recently-alive ones. I.B. Exponential Backoff. With every peer in your db is stored a "deadness level". When the deadness level is equal to 0, that means that the most recent thing that happened is that you receive a message from that peer -- whether it was a reponse to a request of yours or if it were a request from him to you. We say that the peers with deadness level 0 are "the live peers". If a peer has deadness level 1, then that means that the most recent time that you sent a request to that peer, he didn't write back. Now, whenever you want to choose from a set of peers in order to send a request to one of them, the set you choose from is all of the deadness level 0 peers, plus with 50% probability all of the deadness level 1 peers, plus with 25% probability all of the deadness level 2 peers, and so on. Deadness level 2 means that the peer was in deadness level 1, and you chose to query him (with 50% probability), and he didn't write back again. I.C. Lookup of Peer Contact Info. When you want to find the current contact info (i.e. current IP address+port number, or current Relay Server) for a peer, you send a query to a certain number of other peers (called "MetaTrackers" when they are serving this purpose) -- a "lookup contact info" query. How many peers? Approximately log(N) where N is the number of peers in your local peer database. Which peers? You use the Chord distribution -- you query the peer closest to your target, the one closest to the point halfway around the circle from your target, the one closest to the point a quarter of the way around the circle, and cetera. Obviously, you need to publish your current contact info to *your* MetaTrackers whenever you join the network or whenever your contact info changes. Your MetaTrackers are the peer in your db which is closest to you, the peer in your db which is closest to the point halfway around the circle, etc. I.D. Discovery of New Peers. Rate-Limited Structured Flood. Every 60 minutes, you send an update to each of your MetaTrackers. That update contains the list of the peerIds of every new peer. A "new peer" for this purpose is defined as follows: you've never before announced this peer to MetaTrackers, and this peer currently has deadness level 0 in your local db. If the complete (compressed) message containing the information about the new peers would exceed 256 KB, then select a random subset of the new peers to announce in this announcement so that the message doesn't exceed 256 KB. This is a rate-limited structured flood. The flooding nature of it means that eventually you will find out about the arrival of every new peer. The structured nature of it means that it will take only log(N) time intervals before you find out, and you will receive only (;-)) log(N) separate notifications of the arrival of a new peer. (And you will send log(N) separate announcements of new peers -- one announcement to each of your MetaTrackers.) The rate-limited nature of it means that if new peers are arriving so fast that these notifications would take more than log(N)*256 KB per hour bandwidth, that instead they take up only log(N)*256 KB per hour and it takes longer for you to find out about the arrival of every new peer. I.E. Relay. You choose some peer which you can make a TCP connection to and appoint it to be your RelayServer. How you choose it, and dynamically update your choice, is complicated -- see the implementation in RelayClient.py. Whenever someone wants to send a message to you and they find it impossible to open a TCP connection to you (which is all the time when you are behind a NAT or firewall that prevents incoming TCP connections) then they send the message to your RelayServer instead. See also [2, 3, 4]. II. Filesystem. II.A. Encoding of a file. This is already described fully and succinctly in [5]. Here is a capsule summary: 1. Erasure code the file, 2. Encrypt the blocks, 3. Put the list of the Ids of the encrypted blocks into a new file named the inode, 4. Encrypt the inode, 5. The Id of the inode, combined with the secret key used for encryption are the mnetURI of the file. II.B. Push each block to the BlockServer which has an nodeId closest to the blockId (in the Chord metric). II.C. In order to download a file, given its mnetURI, you first have to download the inode, and then you have to download a sufficient number of the erasure coded blocks. For each block that you want to download, you query the BlockServer whose Id is closest to that block's Id. If he doesn't have it, then you ask the BlockServer whose Id is the next-closest. Etc. If the file is not actually reconstructable at all because there are not enough blocks present at all on the network, then this search algorithm devolves to a broadcast search. This concludes the basic description of the design of Mnet v0.7+. There are other aspects of the design that are not included here, including a metadata search facility invented by Myers Carpenter. In addition, there are many specifics or added features in the core network+filestore that are excluded from this description for brevity. *** Discussion: III. A Nice Slow Network. The deliberate pace of announcement of new peers is a feature, not a bug. For starters it is convenient to implement, because for various reasons it is easier to efficiently manage 256 KB every hour than 72 bytes every second even though they amount to the same bandwidth over the long term. However, beyond it being convenient, it is also useful for discriminating among our peers, because we don't want to start using new peers until they've been around for a while anyway. Fresh peers are more likely to disappear than older ones. In earlier versions of this system, we heard about new peers more quickly, and then we had to add logic to avoid using them until time had passed. However, beyond it being convenient and useful, it is also desirable to me, because I wanted Mnet to be more amenable to deliberate and long-term use than to urgent and impulsive use. Brad Templeton argued to me in the year 2002 that if a distributed filesystem were primarily for acquiring novelty videos, pop songs, and porn, then instant gratification would be important, but if it were primarily for acquiring classic works of literature, political and historical documents, or backup copies of your own data, then instant gratification isn't so important. His argument made an impression on me. IV. Scalability Issues and other problems. IV.A. Size of the local Peer DB. One limitation on scale is the size of the local peer db. For a modernish desktop machine, the local peer db could probably be on the order of 2^20 entries with no noticeable problem. The limit could probably be made much higher by optimizing the db. The current db is trivial -- it consists of a Python dict in memory which gets serialized by Python pickle and then written to a file every hour or so. IV.A.i. In practice, almost all peers which fall into high deadness levels will never revive. If you purge a peer from your local db and then that peer does revive and reconnect to the network, and if he sends you a request, then you will re-add him to your db just as if he were a brand new peer. So if your local peer db is too big, you could purge peers, starting with the most dead ones. IV.B. Announcement of New Peers. Each newly arrived peer will be announced to each current peer. If the rate of arrivals of new peers is sufficiently small, then it will take log(N) time intervals for all peers to learn about the new peer. My estimate is that "sufficiently small" is about 2000 new peers per hour, with the current implementation. It could doubled or quadrupled by better compression of the announcement messages. If the rate of arrival of new peers exceeds this, then the time before all peers have heard about the new peer increases proportionally to the rate. IV.C. Block store churn. There is currently no way for a block server to indicate that its store of blocks is full and that it refuses to accept new blocks being pushed into it, so you should give them to someone else. Absent this "back pressure", the stores of nodes with small storage capacity are likely to get flushed out by new publications even while the stores of nodes with large capacity are underutilized. This inefficient distribution reduces the half-life of files by some unknown constant. IV.D. Did you say "BROADCAST SEARCH"? Well, consider what would happen if you stopped searching for a block after your first query. Then we would similar likelihood of finding a block as in e.g. the Chord File System, with minimal message complexity -- a single query. The problem is that maybe the block isn't on that node but is on a nearby node (either because that node joined the network after the block was published, or because the publisher of the block wasn't yet aware of that node when he published the block). This problem can be solved in one of three ways: 1. When a new node arrives, it requests copies of all of the relevant blocks from the node(s) that it shadows. This is a bad idea for this system. 2. As nodes arrive and leave, they keep track of which other nodes they shadow, then they forward requests which might be satisfied by other nodes. Interesting possibility, but I couldn't figure out how to do it in a way that wouldn't be very complicated and still end up falling in the worst case to the third approach: 3. When a downloader doesn't find the desired block on the server closest to the blockId, it chooses whether to broaden the search and query other servers that are further from the blockId. The interesting thing about 3 is that the decision about how broad to make the search is made by the agent who has the most information about its importance (such as whether other erasure coded blocks have been found that can replace the missing block, or whether the user considers downloading this file important enough to impose additional burden on the network). This same agent that has the most information is also the one that has the incentive to want the download to succeed, so it is this agent who should choose whether or not to impose the additional burden on the network of a broader search. See also section V -- "Persistent Tit-for-Tat == Bilateral Accounting". V. Persistent Tit-for-Tat == Bilateral Accounting. Mnet v0.7+ lacks something -- an incentive mechanism to limit excessive costs imposed on the network and simultaneously to motivate users to contribute resources to the network. I was always deeply impressed with the simplicity and robustness of Bram Cohen's "Tit-for-tat" incentive mechanism for BitTorrent. Suppose we wanted a similar "tit-for-tat" mechanism for Mnet v0.7++, but we wanted the peer relationships to extend through time and across multiple files and multiple user operations. Then we would probably invent a bilateral accounting scheme for each node to keep track of how much goodness each of its peers has done for it, and to reward helpful peers. This would then turn out to be more or less identical to the "bilateral accounting" scheme that was originally invented by Jim McCoy and Doug Barnes in Mojo Nation [footnote *]. *** Acknowledgements I know that I am doomed before I start to accidentally exclude important and deserving people from this section. Sorry. This is in roughly chronological order of their earliest contributions to this design, as far as I can remember. Obviously this design owes a great debt to the original designers of its direct ancestor Mojo Nation: Jim McCoy and Doug Barnes, as well as to the Evil Geniuses -- especially Greg Smith, Bram Cohen, and Drue Lowenstern. Also: Raph Levien, Sergei Osokine, the Freenet folks -- Ian Clarke, Oskar Sandberg, and Adam Langley among others -- Justin Chapweske of Swarmcast, Brandon Wiley, Martin Peck, the Chord folks, the Pastry folks, the CAN ("Content-Addressable Network") folks, the OceanStore folks, The Mnet Hackers [7] -- Hauke Johannknecht, Jukka Santala, Myers Carpenter, Oscar Haegar, Arno Waschk, Luke Nelson -- Mark S. Miller, Bram Cohen again (and Drue Lowenstern again) with BitTorrent, the Kademlia folks, numerous contributors to the p2p-hackers mailing list and the #p2p-hackers IRC channel. Like I said -- sorry about those omissions. [footnote *] Once upon a time there was digital cash, as pioneered by David Chaum. When Jim McCoy and Doug Barnes invented Mojo Nation, they used digital cash, and added bilateral accounting so that a pair of peers wouldn't require a transaction with a central token server in order to incentivize each other. The first three employees they hired to implement Mojo Nation in 1999 were Greg Smith, Bram Cohen, and myself. (Greg might have started in 1998 -- I'm not sure.) Several of the ideas in BitTorrent -- which Bram started writing in 2001 -- can be understood as radical simplifications of ideas in Mojo Nation. One such perspective is to think of BitTorrent's tit-for-tat incentives as being time-limited, file-specific, and non-transferrable bilateral accounting. This is not condemnation of BitTorrent's ideas, but praise of them -- they demonstrate the virtue of radical simplification. [1] http://mnetproject.org/ [2] http://mnetproject.org/repos/mnet/doc/network_overview.html [3] http://mnetproject.org/repos/mnet/doc/EGTPv1_Architecture.txt [4] http://mnetproject.org/repos/mnet/doc/messages_overview.html [5] http://mnetproject.org/repos/mnet/doc/new_filesystem.html [6] http://mnetproject.org/repos/mnet/CREDITS From dcarboni at gmail.com Wed Mar 9 11:18:24 2005 From: dcarboni at gmail.com (Davide Carboni) Date: Sat Dec 9 22:12:51 2006 Subject: [p2p-hackers] question on BT Message-ID: <71b79fa90503090318733b3e08@mail.gmail.com> Hi all, reading the protcol specs of Bittorrent I don't understand if once a peer A connects to a peer B through a socket S what are their roles: 1. A downloads and B uploads. If B wants to download a piece from A then B must connect to A with a new socket S2 2. Both A and B can download/upload from each other using S thanks for clues. D. From eugen at leitl.org Wed Mar 9 13:23:46 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] ANN: pyi2p (fwd from david@rebirthing.co.nz) Message-ID: <20050309132345.GN13336@leitl.org> ----- Forwarded message from David McNab ----- From: David McNab Date: Thu, 10 Mar 2005 01:36:17 +1300 To: i2p@i2p.net Subject: [i2p] ANN: pyi2p User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Hi all, Firstly - warmest appreciation to Connelly who's now busily diagnosing and working (and maybe hassling jrandom re the java side) to get the pySAM API working again with current I2P. Secondly - I've created a suite of python I2P utility modules. Called simply 'pyi2p' (to distinguish from the existing 'i2p' python module in CVS), pyi2p is a bag of goodies for Python I2P app development. http://www.freenet.org.nz/i2p/pyi2p.tar.gz Sneak preview: - I2PTunnel class - easy creation/management of I2P<->TCP tunnels - i2psocket - compatible subclass of python socket.socket which transparently creates and manages tunnels as needed - i2pxmlrpc - server and client classes for XML-RPC which work over I2P, including full demo suite - i2pbase64 - a base64 codec which works with I2P's base64 alphabet - i2phosts - a very dict subclass which inserts and retrieves entries to/from hosts.txt This is a first alpha of these modules. Use with caution. Should be working well enough to see what's going on. Fancy HTML documentation enclosed. Largely similar aims as Connelly's PySAM modules - ease of migrating apps (or targetting new python apps) to I2P. But radically different approach. PySAM modules offer python library-compatible sockets that traffic data via SAM. These modules do conventional TCP, but transparently establish I2P<->TCP tunnels as needed. Effect is essentially the same. I present these modules not as 'competition' to Connelly's excellent work, but as a complementary approach. Each has advantages/disadvantages - more power to consumer choice. Some situations will favour PySAM, other situations may favour pyi2p. Enjoy! -- Cheers David _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050309/c07f4c49/attachment.pgp From hal at finney.org Wed Mar 9 17:22:38 2005 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] question on BT Message-ID: <20050309172238.0E69257EE7@finney.org> D. writes: > Hi all, > reading the protcol specs of Bittorrent I don't understand if once a > peer A connects to a peer B through a socket S what are their roles: > > 1. A downloads and B uploads. If B wants to download a piece from A > then B must connect to A with a new socket S2 > 2. Both A and B can download/upload from each other using S They both download and upload using the same socket. H. From me at pixelcort.com Thu Mar 10 03:01:12 2005 From: me at pixelcort.com (Cortland Klein) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] My Introduction Message-ID: <422FB878.3040606@pixelcort.com> Hello. For those of you who don't know me already, I thought I might introduce myself. My name is Cortland Klein, founder of the nuWeb Project, which aims to bring together P2P technologies to solve bandwidth scalability problems. We are interested in working with new and existing P2P projects to bring together solutions that everyone can use. Currently, we are focusing on Peercaching (Dijjer), Peercasting (Peercast), and PushWeb/LiveRSS. Our site can be found at http://nuweb.org/ . I look forward to discussing and implementing P2P solutions with you all in the future. -- Cortland Klein (XMPP/SMTP) nuWeb Project Founder - http://nuweb.org/ "Infinite Scalability" Journal - http://pixelcort.com/ "Ranting and Raving" The geeks shall take over the world and the bits shall be set free! From eugen at leitl.org Thu Mar 10 07:49:58 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] thoughts toward i2p persistent storage (fwd from david@rebirthing.co.nz) Message-ID: <20050310074958.GY13336@leitl.org> ----- Forwarded message from David McNab ----- From: David McNab Date: Thu, 10 Mar 2005 11:58:57 +1300 To: i2p@i2p.net Subject: [i2p] thoughts toward i2p persistent storage User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Hi, Since my return to activity in I2P, I've been pondering the as yet unresolved challenge of reliable persistent storage in i2p. Recent irc discussions have come up with the opinion that a fully peer-to-peer architecture might be problematic in i2p, given the volume of query traffic as the p2p network grows. Also, that a system of syndicated servers, keeping each other up to date, accessed by clients, might be the way to go. So I'm launching this thread with a hope of triggering some detailed discussion on how we might architect such a beast. One option is to go straight nntp, and to build fancy nntp clients which can automatically insert/retrieve stuff under program control and present it as needed. But I'm wondering if we need the complexity and baggage of a full network of syndicated nntp servers, or whether a cut-down implementation of similar ideas would work better. One of the biggest trade-offs for such an architecture - syndicated servers accessed by thin clients - is between performance, convenience and scalability. One extreme is that every server in the syndicate mirrors everything. This is great for performance, because each client with each hit connects to a random server, and is guaranteed a successful insert/retrieve, as long as the server is up. If the server is down, the client moves on to another random server till it gets lucky. This extreme also has the advantage of convenience. Server admins can just boot their servers into the network, even run them transient, and they will automatically get and stay up to date. However, this situation suffers the obvious issue of scalability. The other option is a syndicate of servers, each of which maintain partial mirrors of overall content. However, that takes us at least part of the way to the full kademlia query flooding scenario. Here, we have a scenario where client 'Alice' knows about servers 'Steve', 'Sally' and 'Stan' and 'Samantha'. Alice wants to get 'SSK@yadayada/foo/bar'. Assume that only Sally has that item. Scenarios include: (i) alice tries steve - steve says 'try sally' - alice tries sally, sally coughs up the content (ii) alice tries steve, steve puts alice on hold, steve then gets the content from sally, steve says to alice 'here ya go' However, a syndicate where each server only partially mirrors opens up a can of worms. The big question is - what criteria are used for choice of what to mirror or not? Choice will have to be based on automatic or manual criteria, or a combination of both. Fully automated criteria will have to classify content based on some metric, such as kademlia. This makes life easy for server admins, but requires a good metric to give a good tradeoff between scalability and retrievability. Manual criteria will give server admins more control, but the admins will get bugged frequently, needing to choose whether they're willing to host SSK@this and SSK@that. Anyway, I've raved on long enough. What are /your/ thoughts? -- Cheers David _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050310/2cf798b1/attachment.pgp From eugen at leitl.org Thu Mar 10 08:05:21 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] Re: thoughts toward i2p persistent storage (fwd from frosk@i2pmail.org) Message-ID: <20050310080521.GZ13336@leitl.org> ----- Forwarded message from Frosk ----- From: Frosk Date: Thu, 10 Mar 2005 00:45:42 +0000 (UTC) To: i2p@i2p.net Subject: [i2p] Re: thoughts toward i2p persistent storage User-Agent: Loom/3.14 (http://gmane.org/) David McNab writes: > The other option is a syndicate of servers, each of which maintain > partial mirrors of overall content. However, that takes us at least part > of the way to the full kademlia query flooding scenario. Here, we have a > scenario where client 'Alice' knows about servers 'Steve', 'Sally' and > 'Stan' and 'Samantha'. Alice wants to get 'SSK yadayada/foo/bar'. Assume > that only Sally has that item. Scenarios include: > (i) alice tries steve - steve says 'try sally' - alice tries sally, > sally coughs up the content > (ii) alice tries steve, steve puts alice on hold, steve then gets the > content from sally, steve says to alice 'here ya go' The third scenario, covered by Feedspace (aka I2PContent) is that Alice knows beforehand that Sally has the content, either because Sally is a big-ass syndicator who, by choice, carries a (relatively) large part of the total content, or because Sally has announced somewhere that she has it (e.g., through announcement services available on the same network, through eepsites, etc). You may think Sally will get overloaded with requests, and you'd be right. However, Sally enters ad-hoc peering agreements with other syndicators (meaning they exchange some shared subset of the content they both have), and are able to refer incoming requests to these if the load needs to be shared. When Alice reaches a syndicator who can handle her request, say Steve, Alice will in fact enter such a peering agreement with Steve. Alice now acts as a syndicator for the content herself, for the duration of the peering. As long as they are peered, Steve will push content on Alice according to the subscription criteria of the peering agreement. We keep pulling at an absolute minimum, and let data flow wherever it's wanted, but nowhere else. Questions like "but how will I find a syndicator to carry my own content" still need to be answered, but this shouldn't be a big problem (especially since you are your own syndicator by default; it just becomes a problem of spreading the word). Down the road, it may be nice to have a fully distributed syndicate database for discovery of syndicators, but this isn't a critical component. We have started writing some code for Feedspace (though nothing functional yet), but there's plenty to be spec'ed yet. I'm working on a new revision of the "call for comments" paper after the IRC discussions following the current rev, but the current one isn't completely obsolete, so if you haven't yet, it would be cool if you'd have a look through http://frosk.i2p/i2pcontent-5.p{s, pdf} and tell us what you think. -- frosk _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050310/a4782679/attachment.pgp From achewood at gmail.com Thu Mar 10 11:16:56 2005 From: achewood at gmail.com (.) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] BT and localisation Message-ID: <654656bd05031003165839fb9b@mail.gmail.com> Is there any localisation in the peers connected to within a swarm...? For instance, if I'm in the US and there are peers spread around the world, am I any more likely to get data from other peers in the US than peers in, say, Japan or China? thanks. From Serguei.Osokine at efi.com Thu Mar 10 16:55:58 2005 From: Serguei.Osokine at efi.com (Serguei Osokine) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] BT and localisation Message-ID: <4A60C83D027E224BAA4550FB1A2B120E0DC3BF@fcexmb04.efi.internal> On Thursday, March 10, 2005 . wrote: > ...am I any more likely to get data from other peers in the US > than peers in, say, Japan or China? Yes. Since TCP sending rate is RTT-dependent and in BT you have multiple concurrent TCP streams, you'll tend to send more to the closest hosts and to receive more from them. So the peer selection algorithms on both ends will make sure that these hosts hosts are the preferred ones, since they will tend to give better transfer rates. Best wishes - S.Osokine. 10 Mar 2005. -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On Behalf Of . Sent: Thursday, March 10, 2005 3:17 AM To: p2p-hackers@zgp.org Subject: [p2p-hackers] BT and localisation Is there any localisation in the peers connected to within a swarm...? For instance, if I'm in the US and there are peers spread around the world, am I any more likely to get data from other peers in the US than peers in, say, Japan or China? thanks. _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From gbildson at limepeer.com Thu Mar 10 17:22:42 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] BT and localisation In-Reply-To: <4A60C83D027E224BAA4550FB1A2B120E0DC3BF@fcexmb04.efi.internal> Message-ID: The question here would be, is that effect strong enough to override other effects due to transfer capacity and general random association. Would the preferencing be significant. Thanks -greg > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of Serguei Osokine > Sent: Thursday, March 10, 2005 11:56 AM > To: .; Peer-to-peer development. > Subject: RE: [p2p-hackers] BT and localisation > > > On Thursday, March 10, 2005 . wrote: > > ...am I any more likely to get data from other peers in the US > > than peers in, say, Japan or China? > > Yes. Since TCP sending rate is RTT-dependent and in BT you > have multiple concurrent TCP streams, you'll tend to send more > to the closest hosts and to receive more from them. So the peer > selection algorithms on both ends will make sure that these hosts > hosts are the preferred ones, since they will tend to give better > transfer rates. > > Best wishes - > S.Osokine. > 10 Mar 2005. > > > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of . > Sent: Thursday, March 10, 2005 3:17 AM > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] BT and localisation > > > Is there any localisation in the peers connected to within a swarm...? > For instance, if I'm in the US and there are peers spread around the > world, am I any more likely to get data from other peers in the US > than peers in, say, Japan or China? > > thanks. > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From hal at finney.org Thu Mar 10 17:56:09 2005 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] BT and localisation Message-ID: <20050310175609.C1BA457EE7@finney.org> achewood@gmail.com writes: > Is there any localisation in the peers connected to within a swarm...? > For instance, if I'm in the US and there are peers spread around the > world, am I any more likely to get data from other peers in the US > than peers in, say, Japan or China? The tracker code itself doesn't do this, at least not the official BT python version: cache = self.cache2.setdefault(infohash, []) if len(cache) < rsize: del cache[:] cache.extend(self.becache2.setdefault(infohash, {}).values()) shuffle(cache) del self.cache1.get(infohash, [])[:] data['peers'] = ''.join(cache[-rsize:]) del cache[-rsize:] This basically copies all the peers it knows about from becache2 to cache2 (which is pointed to by cache). It then randomly shuffles cache2 and returns the last 'rsize' elements, deleting them from cache2. (rsize is the number of peers requested to be returned by the tracker.) The next call again returns and deletes the last rsize elements from cache2, until we have fewer than rsize elements in cache2. At that point it is cleared and we again copy all the known peers from becache2. This is very straightforward and makes no attempt to enforce localization. However as others point out, you may get better bandwidth to nearby peers and the self-reinforcing nature of the network would tend to emphasize those links. HF From travis at redswoosh.net Thu Mar 10 17:51:25 2005 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] BT and localisation In-Reply-To: <4A60C83D027E224BAA4550FB1A2B120E0DC3BF@fcexmb04.efi.internal> Message-ID: <200503101752.j2AHqjaL004611@be9.noc0.redswoosh.com> Though the selection happens on the client-side after the "search results" are already sent to the client, this "localization" effect is pretty minimal. The chances that any of the random peer locations you receive are going to be local is pretty low. Of course, a rigorous definition of what "local" means and an analysis of the diffusion of different networks would be necessary to come up with a confidence interval on the probability, but my experience is that you rarely get a result from the same 3rd tier network. Travis -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Serguei Osokine Sent: Thursday, March 10, 2005 8:56 AM To: .; Peer-to-peer development. Subject: RE: [p2p-hackers] BT and localisation On Thursday, March 10, 2005 . wrote: > ...am I any more likely to get data from other peers in the US > than peers in, say, Japan or China? Yes. Since TCP sending rate is RTT-dependent and in BT you have multiple concurrent TCP streams, you'll tend to send more to the closest hosts and to receive more from them. So the peer selection algorithms on both ends will make sure that these hosts hosts are the preferred ones, since they will tend to give better transfer rates. Best wishes - S.Osokine. 10 Mar 2005. -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On Behalf Of . Sent: Thursday, March 10, 2005 3:17 AM To: p2p-hackers@zgp.org Subject: [p2p-hackers] BT and localisation Is there any localisation in the peers connected to within a swarm...? For instance, if I'm in the US and there are peers spread around the world, am I any more likely to get data from other peers in the US than peers in, say, Japan or China? thanks. _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From zhaoh at cnic.cn Fri Mar 11 09:41:00 2005 From: zhaoh at cnic.cn (Tom) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] What's difference between two expressions. Message-ID: <00c901c5261e$6f531f40$9202e29f@cniculgpbq5czh> Hi all, Does the definition of the DEGREE of overlay network refer to the AVERAGE DISTANCE L between pairs of nodes in overlay network? Or what's the difference between them? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050311/ff14f8e0/attachment.htm From eugen at leitl.org Fri Mar 11 11:22:29 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] ANN: i2pxmltunmgr (fwd from david@rebirthing.co.nz) Message-ID: <20050311112228.GN17303@leitl.org> ----- Forwarded message from David McNab ----- From: David McNab Date: Fri, 11 Mar 2005 21:50:42 +1300 To: i2p@i2p.net Subject: [i2p] ANN: i2pxmltunmgr User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) Hi, Just a quick note to announce an alpha release of TCPI2P, which incorporates a standalone XML-RPC server for managing I2P tunnels, as well as flexible python classes for tunnel management and other handy stuff. Due to disgraceful non-performance by the local telco here in regard to my fux0r3d ADSL connection, I've had to temporarily put the code up on one of my sourceforge sites: http://psst.sf.net/tcpi2p This package, TCPi2P, replaces the 'pyi2p' package announced earlier. It's written in Python, and offers classes for bridging conventional TCP apps to I2P, and programmatically managing the tunnels without needing to manually do the tunneling through routerConsole. However, the XML-RPC tunnel manager server, 'i2pxmltunmgr', gets installed as a black-box prog. This server makes it possible for any language with XML-RPC libraries - perl, C/C++ etc - to create and manage keys and tunnels. After installing TCPI2P, just type 'i2pxmltunmgr --help' and read the short help. -- Cheers David _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050311/295f3ff4/attachment.pgp From gbildson at limepeer.com Fri Mar 11 15:51:42 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] What's difference between two expressions. In-Reply-To: <00c901c5261e$6f531f40$9202e29f@cniculgpbq5czh> Message-ID: Does that refer to the outdegree of a node? i.e. The number of connections between hosts. Thanks -greg -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On Behalf Of Tom Sent: Friday, March 11, 2005 4:41 AM To: p2p-hackers@zgp.org Subject: [p2p-hackers] What's difference between two expressions. Hi all, Does the definition of the DEGREE of overlay network refer to the AVERAGE DISTANCE L between pairs of nodes in overlay network? Or what's the difference between them? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050311/befe9549/attachment.htm From mgp at ucla.edu Fri Mar 11 17:19:31 2005 From: mgp at ucla.edu (Michael Parker) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] What's difference between two expressions. In-Reply-To: <00c901c5261e$6f531f40$9202e29f@cniculgpbq5czh> References: <00c901c5261e$6f531f40$9202e29f@cniculgpbq5czh> Message-ID: <4231D323.3010605@ucla.edu> The degree of a node typically refers to the number of links it has to other peers, i.e. the number of connections it maintains while on the overlay. The average distance between pairs of nodes is typically the average path length between any two nodes (measured in hops) -- meaning if we randomly pick two nodes on a network and try to find the shortest path between them, on average, that distance is L. - Mike Tom wrote: > Hi all, > Does the definition of the *DEGREE* of overlay network refer to the > *AVERAGE DISTANCE L* between pairs of nodes in overlay network? Or > what's the difference between them? > Thanks in advance. > >------------------------------------------------------------------------ > >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > From davia26 at hotmail.com Fri Mar 11 20:06:23 2005 From: davia26 at hotmail.com (David Arturo MONZON RUBIO) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] ANN: pyi2p (fwd from david@rebirthing.co.nz) In-Reply-To: <20050309132345.GN13336@leitl.org> Message-ID: An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050311/1af792e7/attachment.html From aharwood at cs.mu.oz.au Sun Mar 13 11:23:17 2005 From: aharwood at cs.mu.oz.au (Aaron Harwood) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Node counting algorithm In-Reply-To: <421D924F.20403@fr.fm> References: <421D924F.20403@fr.fm> Message-ID: <5dc5529e43b02d9ebbfb1c48a9c67223@cs.mu.oz.au> On 24/02/2005, at 7:37 PM, Gwenchlan wrote: > Le mercredi 23 f?vrier 2005 ? 21:32 -0800, Sean C. Rhea a ?crit : > >> On Feb 23, 2005, at 10:27 AM, Michael Parker wrote: >>> If your leaf set overlaps, it's just the number of entries in your >>> leaf set. >>> If your leaf set does not overlap, divide the size of the ring (e.g. >>> 2^128, 2^160) by the span of your leaf set (i.e., the farthest >>> clockwise node minus the farthest counterclockwise node, modulo the >>> ring size), and multiply by the size of your leaf set. Basically, >>> what this means is if your leaf set is size L, and it spans a >>> percentage x of the node identifier space, the size of the network >>> is approximately L * x^-1. To improve accuracy, ask the two farthest >>> nodes in your leaf set and ask them for their leaf sets, merging >>> them into yours before calculating. That way, you have a larger >>> effective L. >> >> This technique gives estimates that, on average, overestimate the >> size of the network if you pick node identifiers uniformly at random >> (UAR). The reason is that UAR doesn't mean evenly distributed; some >> nodes' leaf sets cover much more than others. If you have one node >> whose leaf set covers a larger portion of the key space, that node >> underestimates the size of the ring, but a lot of other nodes end up >> covering less of the key space (to make room for the larger one) and >> end up overestimating the network size. When you average them all, >> the few nodes that underestimate don't make up for all the rest that >> overestimate it. >> >> IANAM (I am not a mathematician), but this is what happens when you >> simulate it at least, with identifiers drawn using SHA. References >> for more mathematical explanations and a better algorithm are >> described in this paper: >> >> http://iptps05.cs.cornell.edu/PDFs/CameraReady_174.pdf >> >> Sean >> > Thanks for these DHT heuristics. I have omited to specify i was > looking for tricks applying to unstructured networks (probably random > graphs). > Thus we cannot deal with density here. I was thinking about using a > flexible method like randow walk, but K random walkers launched by > initiator raise the problem of scalability and accuracy as the overlay > may (more or less) vary during the counting itself, phenomenon > amplified by network size... Perhaps you could try to model the neighborhood growth of the network in question and then, with a sample of the neighborhood growth locally, you can extrapolate the process and determine the total number of nodes. This method assumes that the neighborhood growth characteristics (as a topological property) remains constant over a relatively long period of time (despite relatively large changes in the network size). --Aaron From zooko at zooko.com Mon Mar 14 12:31:51 2005 From: zooko at zooko.com (Zooko O'Whielacronx) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] SHA1 broken? In-Reply-To: <4A60C83D027E224BAA4550FB1A2B120E0DC36C@fcexmb04.efi.internal> References: <4A60C83D027E224BAA4550FB1A2B120E0DC36C@fcexmb04.efi.internal> Message-ID: <6038f2e5e363c978dd4b16d2fcddeab4@zooko.com> On 2005, Feb 17, at 19:23, Serguei Osokine wrote: > For anyone *but* the original code author, however, > achieving a malicious collision this way would be impossible. > > So the Bad Charlie Webmaster from Zooko is pretty much out of > luck - he'd have to conspire with an honest programmer Bob to do any > harm. Maybe. Executive summary: If MD5 were collision resistant, Alice could be certain that the software she runs is the software that Bob intended. Since MD5 isn't collision resistant, then whether Bad Charlie Webmaster can perform this attack depends on some subtler properties of MD5 -- properties which are not as well studied. In any case it isn't necessary for Bad Charlie to break MD5's second-preimage resistance in order to perform this attack. More detail: Cryptographers have traditionally measured hash functions against two definitions: collision resistance and second-preimage resistance, see [1]. collision resistance: You can't find any x1 and x2 such that h(x1) == h(x2). second-preimage resistance: Someone gives you a value x1. Now you can't find any x2 such that h(x1) == h(x2). Collision resistance is stronger than second-preimage resistance, in the sense that any hash function which is collision resistant must also be second-preimage resistant, but not vice versa. collision resistance > second-preimage resistance A lot of the discussion about the recent hash function weaknesses has been along the lines of people saying "Well, the attacks have shown that MD5 doesn't have collision resistance, but this doesn't matter because the property we require for our purposes is second-preimage resistance.". My story about Bad Charlie Webmaster [2] was intended to illustrate that second-preimage resistance is not sufficient to protect Alice, although collision resistance would protect her. Hal Finney has explained in detail [3] why he thinks the current attacks on hash functions don't enable Bad Charlie Webmaster to trick Alice. But what are we to make of this? If we believe Hal Finney's argument (I do), then MD5 doesn't have the property of collision-resistance, but it has some other property which makes it safe for Alice the User and Bob the Programmer to use. This property is that any two messages that can be found to collide are constrainted to have only a few small differences from one another, and those differences close together. I just want to emphasize that it isn't MD5's second-preimage resistance that is protecting Alice. If less constrained collisions can be generated in MD5, then Alice is vulnerable to Bad Charlie Webmaster even if MD5 is second-preimage resistant. Regards, Zooko [1] Menezes, van Oorschot, Vanstone "Handbook of Applied Cryptography" It's the best reference I know for this kind of thing, well worth the cover price, but it is also available free: http://www.cacr.math.uwaterloo.ca/hac/about/chap9.pdf [2] http://zgp.org/pipermail/p2p-hackers/2005-February/002403.html [3] http://zgp.org/pipermail/p2p-hackers/2005-February/002408.html From ardagna at dti.unimi.it Mon Mar 14 16:39:54 2005 From: ardagna at dti.unimi.it (Claudio Agostino Ardagna) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Reminder: CFP: 10th European Symposium on Research in Computer Security Message-ID: <04c201c528b4$7383f7e0$0b00000a@Berlino> [Apologies if you receive multiple copies of this message] CALL FOR PAPERS ESORICS 2005 10TH EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY Milan, Italy - September 14-16, 2005 http://esorics05.dti.unimi.it/ *********************************************************************** SUBMISSION OF PAPERS: MARCH 25, 2005 *********************************************************************** Papers offering novel research contributions in any aspect of computer security are solicited for submission to the Tenth European Symposium on Research in Computer Security (ESORICS 2005). Organized in a series of European countries, ESORICS is confirmed as the European research event in computer security. The symposium started in 1990 and has been held on alternate years in different European countries and attracts an international audience from both the academic and industrial communities. From 2002 it has been held yearly. The Symposium has established itself as one of the premiere, international gatherings on information assurance. Papers may present theory, technique, applications, or practical experience on topics including: - access control - accountability - anonymity - applied cryptography - authentication - covert channels - cryptographic protocols - cybercrime - data and application security - data integrity - denial of service attacks - dependability - digital right managament - firewalls - formal methods in security - identity management - inference control - information dissemination control - information flow control - information warfare - intellectual property protection - intrusion tolerance - language-based security - network security - non-interference - peer-to-peer security - privacy-enhancing technology - pseudonymity - secure electronic commerce - security administration - security as quality of service - security evaluation - security management - security models - security requirements engineering - security verification - smartcards - steganography - subliminal channels - survivability - system security - transaction management - trust models and trust management policies - trustworthy user devices The primary focus is on high-quality original unpublished research, case studies and implementation experiences. We encourage submissions of papers discussing industrial research and development. Proceedings will be published by Springer-Verlag in the Lecture Notes in Computer Science series. INSTRUCTIONS FOR PAPER SUBMISSIONS Submitted papers must not substantially overlap papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers should be at most 15 pages excluding the bibliography and well-marked appendices (using 11-point font), and at most 20 pages total. Committee members are not required to read the appendices, and so the paper should be intelligible without them. To submit a paper, send to esorics05@dti.unimi.it a plain ASCII text email containing the title and abstract of your paper, the authors' names, email and postal addresses, phone and fax numbers, and identification of the contact author. To the same message, attach your submission (as a MIME attachment) in PDF or portable postscript format. Do NOT send files formatted for word processing packages (e.g., Microsoft Word or WordPerfect files). Submissions not meeting these guidelines risk rejection without consideration of their merits. Submissions must be received by March 25, 2005 in order to be considered. Notification of acceptance or rejection will be sent to authors by May 30, 2005. Authors of accepted papers must be prepared to sign a copyright statement and must guarantee that their paper will be presented at the conference. Authors of accepted papers must follow the Springer Information for Authors' guidelines for the preparation of the manuscript and use the templates provided there. GENERAL CHAIR Pierangela Samarati University of Milan email: samarati@dti.unimi.it PROGRAM CHAIRS Sabrina De Capitani di Vimercati University of Milan email: decapita@dti.unimi.it Paul Syverson Naval Research Laboratory url: www.syverson.org PUBLICATION CHAIR Dieter Gollman TU Hamburg-Harburg email: diego@tuhh.de PUBLICITY CHAIR Claudio A. Ardagna University of Milan, Italy email: ardagna@dti.unimi.it IMPORTANT DATES Paper Submission due: March 25, 2005 Notification: May 30, 2005 Final papers due: June 30, 2005 PROGRAM COMMITTEE Rakesh Agrawal IBM Almaden Research Center, USA Gerard Allwein Naval Research Laboratory, USA Ross Anderson University of Cambridge, UK Vijay Atluri Rutgers University, USA Michael Backes IBM Zurich Research Laboratory, Switzerland Giampaolo Bella University of Catania, Italy Jan Camenisch IBM Zurich Research Laboratory, Switzerland David Chadwick University of Kent, UK Marc Dacier Institut Eur?com, France Ernesto Damiani University of Milan, Italy George Danezis University of Cambridge, UK Simon Foley University College, Ireland Philippe Golle Palo Alto Research Center, USA Sushil Jajodia George Mason University, USA Marit Hansen Independent Centre for Privacy Protection Schleswig-Holstein, Germany Philippa Hopcroft Oxford University, UK Dogan Kesdogan RWTH Aachen, Informatik IV, Germany Peng Liu The Pennsylvania State University, USA Javier Lopez University of Malaga, Spain Heiko Mantel ETH-Zentrum, Switzerland Nick Mathewson The Free Haven Project, USA Patrick McDaniel The Pennsylvania State University, USA Peng Ning NC State University, USA Peter Ryan University of Newcastle upon Tyne, UK Kazue Sako NEC Corporation, Japan Pierangela Samarati University of Milan, Italy Vanessa Teague University of Melbourne, Australian Mariemma I. Yague University of Malaga, Spain Alec Yasinsac Florida State University, USA (Not yet completed) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050314/0c18ddd6/attachment.htm From john.casey at gmail.com Tue Mar 15 05:18:08 2005 From: john.casey at gmail.com (John Casey) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Opaque Key Access in DHT's ?? In-Reply-To: References: Message-ID: Hi Jim, I know this is a really late respone just wondering if there way any way to interact with the underlying array of your bloom filter implementation or serialize it as a network payload? > You might look at the org.xlattice.crypto.filters package at > > http://xlattice.sourceforge.net/components/crypto/src > > The package was designed to allow neighbors to cheaply look at one > another's caches. > > -- > Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881 > http://jxcl.sourceforge.net Java unit test coverage > http://xlattice.sourceforge.net p2p communications infrastructure > From alenlpeacock at gmail.com Thu Mar 17 15:52:27 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Trust Inflation / Deflation Message-ID: I've been considering the implementation of a system that uses an economic model similar to GnuNet's Excess-Based Economic Model [1], but I'm a bit stuck on one point not mentioned in the paper: Trust Inflation / Deflation. Quick [and therefore unjust] summary of their system: Each node in the network maintains a record of its own trust of the other nodes, represented as a positive integer. Nodes that a node knows nothing about score 0. When nodes generate requests they include a priority, which translates to the amount the responder may decrement the requestor's trust. While resources are idle, nodes don't "debit" the priority amount against earned trust. When they are busy, they do (whether responding or not). When a response is received, a node increments trust in the responder. So, imagine a network of well-behaved nodes. Requests generated in the network are destined almost equally among the nodes. And it just so happens that they all generate requests at an aggregate rate below some threshold such that resources never become scarce (all nodes are in their 'idle' state), so trust is constantly incremented, never decremented. The trust that each node has in the other nodes is steadily rising. This goes on for some months. Now assume that at some point traffic increases. Nodes will begin charging against priority as they become busy. If all nodes maintained their default request priorities, there would be no ordering, so nodes deduce that they must have excess trust in the network and start upping the priorities of their outgoing requests. What metrics does a node use to determine the priority value of a request? Should it normalize by the highest trust it has in some other node[s]? Should it observe the 'market value' of request priorities arriving locally and try to match? Any up adjustment to the start condition default value could be considered 'trust inflation'. Consider the plight of a new node that just joins the network after all this excess trust has accumulated. Such a node may correctly assume that the network does not yet have much trust in it, but if 'trust inflation' has run rampant, it will have no way of knowing that it won't stand a chance of getting resources until it has spent an extraordinary amount of its own resources earning enough trust (to make up for the months when it didn't exist in the network), because it can only assign low priorities to requests. I suppose that if resources are 'in excess' most of the time, this doesn't matter, since no one will debit trust. So the opposite case might be more interesting. As more nodes join a network, it can be expected to become more busy with requests, and eventually, nodes reach a point in which they are in the idle state less often than the busy state. After this point, trust no longer accumulates, but becomes scarce (because for the majority of the time, nodes are debiting trust). As this continues, all nodes on average have very low trust, and it becomes difficult to distinguish well-behaving nodes from misbehaving ones. I'd call this 'trust deflation'. It seems like there needs to be some sort of way to enforce equilibrium in such a system. Is there, and I just missed it? Alen [1] http://gnunet.org/download/ebe.ps From Bernard.Traversat at Sun.COM Fri Mar 18 01:07:42 2005 From: Bernard.Traversat at Sun.COM (Bernard Traversat) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] The latest JXTA J2SE 2.3.3 and JXTA C/C++ 2.1 Releases are out! Message-ID: <423A29DE.2080309@Sun.COM> The JXTA community just announced the availability of two new releases of the JXTA P2P Platform: JXTA J2SE release, 2.3.3 "Pyrogy", and JXTA C/C++ release, 2.1 "Capri". Both the JXTA "Pyrogy" and "Capri" releases provide a number of bug fixes, performance improvements, as well as enhanced platform capabilities. You can access these releases via the jxta.org download page: http://download.jxta.org/build/release Release info are available at: http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=201 http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=200 These releases have been designed to be API and protocol backwards compatible with previous JXTA J2SE and C/C++ 2.x releases, and are fully interoperable. No excuses for not using JXTA for building your P2P applications, and entering the JXTA world where every peer resource in the network can be easily leveraged. Cheers. B. From dcarboni at gmail.com Fri Mar 18 11:12:34 2005 From: dcarboni at gmail.com (Davide Carboni) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Bittorrent resources for developers Message-ID: <71b79fa9050318031219909086@mail.gmail.com> Hi, I'm looking for a community where I can place questions about the BT implementation. I've found the "seminal" sites like bitconjurer.com but not all aspects are covered there. Any clues? D. -- I have made this letter longer than usual because I lack the time to make it shorter. B. Pascal From wesley at felter.org Fri Mar 18 14:52:27 2005 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Bittorrent resources for developers In-Reply-To: <71b79fa9050318031219909086@mail.gmail.com> References: <71b79fa9050318031219909086@mail.gmail.com> Message-ID: <423AEB2B.7040200@felter.org> Davide Carboni wrote: > Hi, I'm looking for a community where I can place questions about the > BT implementation. I've found the "seminal" sites like bitconjurer.com > but not all aspects are covered there. > Any clues? Try http://groups.yahoo.com/group/BitTorrent/messages Wes Felter - wesley@felter.org From zooko at zooko.com Fri Mar 18 15:30:30 2005 From: zooko at zooko.com (Zooko O'Whielacronx) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] another perspective on collision-resistant vs. second-preimage-resistant Message-ID: <83237a489848e2ff3e09455fa67b3117@zooko.com> Suppose you receive a software package from someone else. It could be in source code form or in binary form, or whatever. Suppose you use a hash function `f', compute h = f(software), and send h to a friend of yours. Now if f is a collision-resistant function, then any software package that your friend finds which matches h is the same software package that you have. If f is not collision-resistant, even if f is second-preimage-resistant, then your friend might find a software package which matches h but which is different from the one you have. Regards, Zooko From jdd at dixons.org Fri Mar 18 19:53:24 2005 From: jdd at dixons.org (Jim Dixon) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Opaque Key Access in DHT's ?? In-Reply-To: References: Message-ID: On Tue, 15 Mar 2005, John Casey wrote: > Hi Jim, I know this is a really late respone just wondering if there > way any way to interact with the underlying array of your bloom filter > implementation or serialize it as a network payload? In about two weeks, after I come back from holiday ;-) > > You might look at the org.xlattice.crypto.filters package at > > > > http://xlattice.sourceforge.net/components/crypto/src > > > > The package was designed to allow neighbors to cheaply look at one > > another's caches. -- Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881 http://xlattice.sourceforge.net p2p communications infrastructure From jeffh at cs.rice.edu Fri Mar 18 21:35:10 2005 From: jeffh at cs.rice.edu (Jeff Hoye) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Announcing FreePastry 1.4 Message-ID: <423B498E.90106@cs.rice.edu> The FreePastry team would like to announce the release of FreePastry-1.4. FreePastry is a structured p2p network overlay based on the Pastry protocol, released under a BSD-style license. Improvements over previous versions include: * A more reliable transport layer * Support for source routes to deal with Internet routing anomalies * An implementation of a lease based version of PAST (our DHT) * An implementation of multiple interconnected rings (see IPTPS'04) * An implementation of Glacier, a data-durability system utilizing erasure codes (to appear in NSDI'05) * Numerous bug fixes throughout Pastry, PAST, Scribe, and SplitStream For more information on FreePastry and to download, please go to: http://freepastry.rice.edu/FreePastry/ FreePastry-1.4 is also the underlying platform for ePOST, our distributed email system, which has been deployed for over a year now. For more information or to try out ePOST, please go to: http://www.epostmail.org/ Finally, We've added several "community process" pieces including: 1) An email discussion group. 2) An Online Bug database 3) A tutorial to help you get started with FreePastry http://freepastry.rice.edu/ -Jeff Jeff Hoye Programmer FreePastry Team Systems Group Rice University Houston, TX 77005 From lutianbo at software.ict.ac.cn Sun Mar 20 07:54:18 2005 From: lutianbo at software.ict.ac.cn (Lutianbo) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] How to embed a figure using Latex Message-ID: <009801c52d22$050fb2a0$9402000a@ictltbo> Hi, all. I want to embed a figure in my paper using LATEX. The embeding code is as follows: \begin{figure}[h] \centering \includegraphics[width=0.45\textwidth]{example_tmp.eps} \caption{Example of caption.} \end{figure} However, the figure doesn't appear in the corresponding pdf file. Does anybody know why and how to to do it? Kind regards, --Tian -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050320/ed6090ee/attachment.html From fis at wiwi.hu-berlin.de Sun Mar 20 09:12:12 2005 From: fis at wiwi.hu-berlin.de (Matthias Fischmann) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] How to embed a figure using Latex In-Reply-To: <009801c52d22$050fb2a0$9402000a@ictltbo> References: <009801c52d22$050fb2a0$9402000a@ictltbo> Message-ID: <20050320091212.GA9335@mini> why are you posting this on a mailing list dedicated to discussion p2p issues? (no, you paper being on p2p is not a good reason. anyway, you should be able to find the answer with google faster than over any list, whether suitable for this question or not.) (yes, i know, i'm a smart-ass. sorry. :-)) cheers, matthias On Sun, Mar 20, 2005 at 03:54:18PM +0800, Lutianbo wrote: > To: "Peer-to-peer development." > From: Lutianbo > Subject: [p2p-hackers] How to embed a figure using Latex > > Hi, all. > I want to embed a figure in my paper using LATEX. The embeding code is > as follows: > > \begin{figure}[h] > \centering > \includegraphics[width=0.45\textwidth]{example_tmp.eps} > \caption{Example of caption.} > \end{figure} > > However, the figure doesn't appear in the corresponding pdf file. > Does anybody know why and how to to do it? > > Kind regards, > --Tian > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050320/edbf6328/attachment.pgp From anoopsmv at gmail.com Tue Mar 22 10:27:10 2005 From: anoopsmv at gmail.com (Anoop Mavilaveettil) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p Message-ID: <7fcef5ea05032202273e639715@mail.gmail.com> Hello, First of all, let me thank you for all the sharing of knowledge that is going on in here.I must say that, I have learned a lot, ever since I started frequenting this list. I'm just a newbie in the p2p space and is in the process of building up a p2p based communication and collaboration program and this question is about one issue that I'm confronting and is kind of confused with. If some one can point, or as much as give me a slight hint, about techniques involved, It'd be hugely appreciated. The issue is with user presence/buddy awareness/ user awareness. Mind you, I'm not talking about peer discovery, I think I have got that part all figured out. I'm not even talking about peer presence(even though in some way we can classify this issue as peer presence). How would a user connected to a p2p network, through a specific peer, know/get a notification,whenever some other user connects to the network through another peer?. (Some thing like the buddy system in skype). I've kind of searched the web for answers and all most all of them talk about discovering peers and none talks about user/peer presence(Or may be my search isn't all that good). There are only couple of solutions that I could some how figure out and on analysis, both of them aren't/will not be that robust or efficient. a) Using some kind of keep alive packets between buddies(Works as long as the same pair of users connects through the same pair of peers all the time). b)Using an overlay of super peers/ meta trackers for user tracking and then them firing all required messages to interested peers, whenever a user connects to the p2p net. As I said earlier, both methods aren't that great in terms of efficiency and/or robustness. Is there some other way or any other techniques that could be used to let a peer instantly know about the connection status of his buddy? Thanks in advance, Sreedhar From mfreed at cs.nyu.edu Tue Mar 22 14:59:32 2005 From: mfreed at cs.nyu.edu (Michael J. Freedman) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: <7fcef5ea05032202273e639715@mail.gmail.com> References: <7fcef5ea05032202273e639715@mail.gmail.com> Message-ID: On Tue, 22 Mar 2005, Anoop Mavilaveettil wrote: > Date: Tue, 22 Mar 2005 02:27:10 -0800 > From: Anoop Mavilaveettil > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] A Question about user awareness in p2p > > Hello, > First of all, let me thank you for all the sharing of knowledge that > is going on in here.I must say that, I have learned a lot, ever since > I started frequenting this list. ... > b)Using an overlay of super peers/ meta trackers for user tracking and > then them firing all required messages to interested peers, whenever a > user connects to the p2p net. > As I said earlier, both methods aren't that great in terms of > efficiency and/or robustness. Is there some other way or any other > techniques that could be used to let a peer instantly know about the > connection status of his buddy? Hi Sreedhar, This type of "discovering needles in the haystack" problem is exactly where structured routing overlays (or, perhaps slightly inaccurately, distributed hash tables) perform superiorly to unstructured routing meshes (like Gnutella et al.). Using such a distributed indexing layer, when a peer joins the system, it announces itself under its system handle; when another peer joins, it searches for its buddies under their handles in this shared architecture. To ensure freshness, these announcements should have a TTL; still, they need not be all that short, as information learned from the "DHT" can of course be verified by peers (i.e., ping them to check if still alive). For more information on structured overlays, I suggest looking at the MIT Chord -- http://pdos.lcs.mit.edu/chord/ Rice/MSR Pastry -- http://freepastry.rice.edu/ For an example of using these type of interfaces for node discovery under such weak consistency requirements, check out our use in: CoralCDN -- http://www.coralcdn.org/ If you just want an "working" DHT to play with, you can use the deployed OpenDHT service as such a rendezvous point. OpenDHT -- http://www.opendht.org/ Good luck, --mike ----- "Not all those who wander are lost" www.michaelfreedman.org "You make it fun; we'll make it run" www.coralcdn.org From aloeser at cs.tu-berlin.de Tue Mar 22 15:14:02 2005 From: aloeser at cs.tu-berlin.de (Alexander =?iso-8859-1?Q?L=F6ser?=) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Interest based locality and query distribution Message-ID: <4240363A.B3644F47@cs.tu-berlin.de> Hi all recently several unstructured peer-to-peer systems dynamically select neighbours for each peer using the principle of interest-based locality, e.g. [1,2,3,4]. To model and simulate the behaviour in such networks information about the distribution of interests of each user, e.g. the queries each user issues and the content each user publishes, is required. I'm interested to prove the following hypotheses: 1.) Queries follow a Zipf distribution, only a few queries are highly popular, while the majority of the queries cover only rare topics. 2.) A minority of users issues the majority of all queries. 3.) It is very likely, that these users also stay for a long time in the network. 4.) Most of the queries cover only own interests. What percentage of queries is issued to 'random' topics? 5.) User interests follow a Zipf distribution, e.g. a user spends much of her queries to only one or two topics. Does anybody know citations from real file sharing trace, e.g. Gnutella, Kazaa that support or reject my hypotheses? Alex [1] V. Cholvi, P. Felber, and E.W. Biersack. Efficient Search in Unstructured Peer-to-Peer Networks. [2] Adriana Iamnitchi, Matei Ripeanu and Ian Foster, Small World File Sharing Communities. [3] J. Keller, D. Stern and F. Dang Ngoc. MAAY: A Self-Adaptive Peer Network for Efficient Document Search. [4] Efficient Content Location Using Interest Based Locality in Peer-to-Peer Systems http://www.ieee-infocom.org/2003/papers/53_01.PDF -- ___________________________________________________________ Alexander L?ser Technische Universit?t Berlin http://cis.cs.tu-berlin.de/~aloeser/ office : +49- 30-314-25551 fax : +49- 30-314-21601 ___________________________________________________________ From gbildson at limepeer.com Tue Mar 22 16:03:41 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Interest based locality and query distribution In-Reply-To: <4240363A.B3644F47@cs.tu-berlin.de> Message-ID: Anecdotally, I would say that only your point number 5 is correct. Point 1 is somewhat correct but given that we have done old studies showing that caching of results is not useful, the focus of queries is much more spread out than you believe. (No I don't have the caching studies available.) I don't believe 2 or 3 at all. Thanks -greg > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of Alexander L?ser > Sent: Tuesday, March 22, 2005 10:14 AM > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] Interest based locality and query distribution > > > Hi all > recently several unstructured peer-to-peer systems dynamically select > neighbours for each peer using the principle of interest-based locality, > e.g. [1,2,3,4]. To model and simulate the behaviour in such networks > information about the distribution of interests of each user, e.g. the > queries each user issues and the content each user publishes, is > required. I'm interested to prove the following hypotheses: > > 1.) Queries follow a Zipf distribution, only a few queries are highly > popular, while the majority of the queries cover only rare topics. > 2.) A minority of users issues the majority of all queries. > 3.) It is very likely, that these users also stay for a long time in the > network. > 4.) Most of the queries cover only own interests. What percentage of > queries is issued to 'random' topics? > 5.) User interests follow a Zipf distribution, e.g. a user spends much > of her queries to only one or two topics. > > Does anybody know citations from real file sharing trace, e.g. Gnutella, > Kazaa that support or reject my hypotheses? > > Alex > > > [1] V. Cholvi, P. Felber, and E.W. Biersack. Efficient Search in > Unstructured Peer-to-Peer Networks. > [2] Adriana Iamnitchi, Matei Ripeanu and Ian Foster, Small World File > Sharing Communities. > [3] J. Keller, D. Stern and F. Dang Ngoc. MAAY: A Self-Adaptive Peer > Network for Efficient Document Search. > [4] Efficient Content Location Using Interest Based Locality in > Peer-to-Peer Systems http://www.ieee-infocom.org/2003/papers/53_01.PDF > > -- > ___________________________________________________________ > > Alexander L?ser > Technische Universit?t Berlin > http://cis.cs.tu-berlin.de/~aloeser/ > office : +49- 30-314-25551 > fax : +49- 30-314-21601 > ___________________________________________________________ > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From gbildson at limepeer.com Tue Mar 22 16:10:41 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: Message-ID: I agree here. I expect you would want two things. You would want a DHT for lookup of your buddies and publishing of yourself being online. You may also want to publish your interest in these particular users coming online so that clients don't need to continually poll the DHT for their buddies. This would allow you to learn that your buddies came online more quickly though a callback at a lower lookup cost (but higher storage cost in the DHT). Thanks -greg > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of Michael J. Freedman > Sent: Tuesday, March 22, 2005 10:00 AM > To: Anoop Mavilaveettil; Peer-to-peer development. > Subject: Re: [p2p-hackers] A Question about user awareness in p2p > > > On Tue, 22 Mar 2005, Anoop Mavilaveettil wrote: > > > Date: Tue, 22 Mar 2005 02:27:10 -0800 > > From: Anoop Mavilaveettil > > To: p2p-hackers@zgp.org > > Subject: [p2p-hackers] A Question about user awareness in p2p > > > > Hello, > > First of all, let me thank you for all the sharing of knowledge that > > is going on in here.I must say that, I have learned a lot, ever since > > I started frequenting this list. > > ... > > > b)Using an overlay of super peers/ meta trackers for user tracking and > > then them firing all required messages to interested peers, whenever a > > user connects to the p2p net. > > As I said earlier, both methods aren't that great in terms of > > efficiency and/or robustness. Is there some other way or any other > > techniques that could be used to let a peer instantly know about the > > connection status of his buddy? > > Hi Sreedhar, > > This type of "discovering needles in the haystack" problem is exactly > where structured routing overlays (or, perhaps slightly inaccurately, > distributed hash tables) perform superiorly to unstructured routing > meshes (like Gnutella et al.). > > Using such a distributed indexing layer, when a peer joins the system, it > announces itself under its system handle; when another peer joins, it > searches for its buddies under their handles in this shared architecture. > > To ensure freshness, these announcements should have a TTL; still, they > need not be all that short, as information learned from the "DHT" can of > course be verified by peers (i.e., ping them to check if still alive). > > For more information on structured overlays, I suggest looking at the > > MIT Chord -- http://pdos.lcs.mit.edu/chord/ > Rice/MSR Pastry -- http://freepastry.rice.edu/ > > For an example of using these type of interfaces for node discovery under > such weak consistency requirements, check out our use in: > > CoralCDN -- http://www.coralcdn.org/ > > If you just want an "working" DHT to play with, you can use the deployed > OpenDHT service as such a rendezvous point. > > OpenDHT -- http://www.opendht.org/ > > > Good luck, > --mike > > > ----- > "Not all those who wander are lost" www.michaelfreedman.org > "You make it fun; we'll make it run" www.coralcdn.org > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From anoopsmv at gmail.com Tue Mar 22 18:00:55 2005 From: anoopsmv at gmail.com (Anoop Mavilaveettil) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: References: <7fcef5ea05032202273e639715@mail.gmail.com> Message-ID: <7fcef5ea050322100027240f08@mail.gmail.com> Thanks Mike and Greg, Yes I had known that I would have to(and was planning to) use DHT for peer discovery. But the issue I had was about a peer getting a notification when another specific peer comes online. As Greg said, this would have involved polling DHT for this info, and if the buddy system is very well connected(I mean a majority of the peers have buddies), then this polling could become a bottleneck. See the issue of, say, figuring out if "my" buddies are connected to the p2p net when "I" come online is what that could be solved by DHT. But I was and is looking a solution for is the issue of "I'm already connected and now how would "I" know when one of my buddies come online?". Greg's idea of keeping the buddy info, also in the DHT would work out(I think) but at a larger storage cost or so would a distributed buddy database. Is there any other options? -Sreedhar On Tue, 22 Mar 2005 09:59:32 -0500 (EST), Michael J. Freedman wrote: > On Tue, 22 Mar 2005, Anoop Mavilaveettil wrote: > > > Date: Tue, 22 Mar 2005 02:27:10 -0800 > > From: Anoop Mavilaveettil > > To: p2p-hackers@zgp.org > > Subject: [p2p-hackers] A Question about user awareness in p2p > > > > Hello, > > First of all, let me thank you for all the sharing of knowledge that > > is going on in here.I must say that, I have learned a lot, ever since > > I started frequenting this list. > > ... > > > b)Using an overlay of super peers/ meta trackers for user tracking and > > then them firing all required messages to interested peers, whenever a > > user connects to the p2p net. > > As I said earlier, both methods aren't that great in terms of > > efficiency and/or robustness. Is there some other way or any other > > techniques that could be used to let a peer instantly know about the > > connection status of his buddy? > > Hi Sreedhar, > > This type of "discovering needles in the haystack" problem is exactly > where structured routing overlays (or, perhaps slightly inaccurately, > distributed hash tables) perform superiorly to unstructured routing > meshes (like Gnutella et al.). > > Using such a distributed indexing layer, when a peer joins the system, it > announces itself under its system handle; when another peer joins, it > searches for its buddies under their handles in this shared architecture. > > To ensure freshness, these announcements should have a TTL; still, they > need not be all that short, as information learned from the "DHT" can of > course be verified by peers (i.e., ping them to check if still alive). > > For more information on structured overlays, I suggest looking at the > > MIT Chord -- http://pdos.lcs.mit.edu/chord/ > Rice/MSR Pastry -- http://freepastry.rice.edu/ > > For an example of using these type of interfaces for node discovery under > such weak consistency requirements, check out our use in: > > CoralCDN -- http://www.coralcdn.org/ > > If you just want an "working" DHT to play with, you can use the deployed > OpenDHT service as such a rendezvous point. > > OpenDHT -- http://www.opendht.org/ > > Good luck, > --mike > > ----- > "Not all those who wander are lost" www.michaelfreedman.org > "You make it fun; we'll make it run" www.coralcdn.org > From markus-kern at gmx.net Tue Mar 22 18:17:12 2005 From: markus-kern at gmx.net (Markus Kern) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: <7fcef5ea050322100027240f08@mail.gmail.com> References: <7fcef5ea05032202273e639715@mail.gmail.com> <7fcef5ea050322100027240f08@mail.gmail.com> Message-ID: <4535036343.20050322191712@gmx.net> On Tuesday, March 22, 2005, 7:00:55 PM Anoop Mavilaveettil wrote: > Thanks Mike and Greg, > Yes I had known that I would have to(and was planning to) use DHT for > peer discovery. But the issue I had was about a peer getting a > notification when another specific peer comes online. > As Greg said, this would have involved polling DHT for this info, and > if the buddy system is very well connected(I mean a majority of the > peers have buddies), then this polling could become a bottleneck. > See the issue of, say, figuring out if "my" buddies are connected to > the p2p net when "I" come online is what that could be solved by DHT. > But I was and is looking a solution for is the issue of "I'm already > connected and now how would "I" know when one of my buddies come > online?". I we assume that two people are always in each others buddy list a person who comes online can look up all his buddies on the DHT and send them a direct notification that he is online. Except for some complications when both parties are firewalled (which would require a solution anyway if you want to do anything useful) I see no problems with this approach. Am I missing something? -- Markus Kern From srhea at cs.berkeley.edu Tue Mar 22 19:17:38 2005 From: srhea at cs.berkeley.edu (Sean C. Rhea) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: <4535036343.20050322191712@gmx.net> References: <7fcef5ea05032202273e639715@mail.gmail.com> <7fcef5ea050322100027240f08@mail.gmail.com> <4535036343.20050322191712@gmx.net> Message-ID: <986975ec2646c2d5600cda6553ce31ae@cs.berkeley.edu> On Mar 22, 2005, at 10:17 AM, Markus Kern wrote: > I we assume that two people are always in each others buddy list a > person who comes online can look up all his buddies on the DHT and send > them a direct notification that he is online. Except for some > complications when both parties are firewalled (which would require a > solution anyway if you want to do anything useful) I see no problems > with this approach. Am I missing something? This is exactly what I would suggest, too. It keeps application-level semantics out of the DHT, and as Markus points out, the only difficulty is with firewalls and NATs, which you have to work around (through hole punching, or forwarding) anyway. For doing the peer discovery, OpenDHT (opendht.org) is a perfect match, and you can start using it will very little effort. In fact, we already have a chat client you can check out that uses it for peer discovery (we call it rendezvous, but it's the same thing) available on the website. Sean -- Practice empathy. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050322/717edfe6/PGP.pgp From rita at comet.columbia.edu Tue Mar 22 19:38:48 2005 From: rita at comet.columbia.edu (Rita H. Wouhaybi) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Interest based locality and query distribution References: <20050322191803.BF0283FD36@capsicum.zgp.org> Message-ID: <00e901c52f16$c5126430$9e433b80@comet.columbia.edu> Most of your points are answered in the 2 measurement papers present here: http://www.cs.toronto.edu/~stefan/publications.html Rita H. Wouhaybi rita@comet.columbia.edu http://comet.columbia.edu/~rita/ > Date: Tue, 22 Mar 2005 16:14:02 +0100 > From: Alexander L?ser > Subject: [p2p-hackers] Interest based locality and query distribution > To: p2p-hackers@zgp.org > Message-ID: <4240363A.B3644F47@cs.tu-berlin.de> > Content-Type: text/plain; charset=iso-8859-1 > > Hi all > recently several unstructured peer-to-peer systems dynamically select > neighbours for each peer using the principle of interest-based locality, > e.g. [1,2,3,4]. To model and simulate the behaviour in such networks > information about the distribution of interests of each user, e.g. the > queries each user issues and the content each user publishes, is > required. I'm interested to prove the following hypotheses: > > 1.) Queries follow a Zipf distribution, only a few queries are highly > popular, while the majority of the queries cover only rare topics. > 2.) A minority of users issues the majority of all queries. > 3.) It is very likely, that these users also stay for a long time in the > network. > 4.) Most of the queries cover only own interests. What percentage of > queries is issued to 'random' topics? > 5.) User interests follow a Zipf distribution, e.g. a user spends much > of her queries to only one or two topics. > > Does anybody know citations from real file sharing trace, e.g. Gnutella, > Kazaa that support or reject my hypotheses? > > Alex > > > [1] V. Cholvi, P. Felber, and E.W. Biersack. Efficient Search in > Unstructured Peer-to-Peer Networks. > [2] Adriana Iamnitchi, Matei Ripeanu and Ian Foster, Small World File > Sharing Communities. > [3] J. Keller, D. Stern and F. Dang Ngoc. MAAY: A Self-Adaptive Peer > Network for Efficient Document Search. > [4] Efficient Content Location Using Interest Based Locality in > Peer-to-Peer Systems http://www.ieee-infocom.org/2003/papers/53_01.PDF > > -- > ___________________________________________________________ > > Alexander L?ser > Technische Universit?t Berlin > http://cis.cs.tu-berlin.de/~aloeser/ > office : +49- 30-314-25551 > fax : +49- 30-314-21601 > ___________________________________________________________ > > From anoopsmv at gmail.com Tue Mar 22 19:46:09 2005 From: anoopsmv at gmail.com (Anoop Mavilaveettil) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: <4535036343.20050322191712@gmx.net> References: <7fcef5ea05032202273e639715@mail.gmail.com> <7fcef5ea050322100027240f08@mail.gmail.com> <4535036343.20050322191712@gmx.net> Message-ID: <7fcef5ea05032211466b7c1e0c@mail.gmail.com> Well it is not that simple. 1)First, it is not necessary or mandatory that "two people are always in each other's buddy list". A user might have added another user in his buddy list, but not the other way. In this case when the second guy comes online, the first guy would never get a notification. 2)Second. One major issue, that I have to point out, is that I'm not talking about peers, I am talking about users. A user can connect to the p2p net using any peers. Let me explain a common scenario a) User1 connects to the p2p net using peer1. b)User2 connects to the p2p net using peer2. c)User1 using common message mechanisms add user2(NOT PEER2) as his buddy. But the main thing to note, is that User2 doesn't even know/don't care to know about user1 adding him to buddy list and user2 never adds user1 in his buddy lists. d)User2 disconnects from the p2p net. At this time, we can possibly have some notification mechanisms, which will notify user1@peer1 about the disconnection of user2. e)User2 connects to the p2p net from peer3. ---> And here lies my issue. How would user1@peer1 would know about the arrival of user2@peer3( without structured or limited flooding?) NAT traversal and all other issues are lower level ones, and solutions for those issues are well documented and easily available on the web. On Tue, 22 Mar 2005 19:17:12 +0100, Markus Kern wrote: > > On Tuesday, March 22, 2005, 7:00:55 PM Anoop Mavilaveettil wrote: > > > Thanks Mike and Greg, > > Yes I had known that I would have to(and was planning to) use DHT for > > peer discovery. But the issue I had was about a peer getting a > > notification when another specific peer comes online. > > As Greg said, this would have involved polling DHT for this info, and > > if the buddy system is very well connected(I mean a majority of the > > peers have buddies), then this polling could become a bottleneck. > > See the issue of, say, figuring out if "my" buddies are connected to > > the p2p net when "I" come online is what that could be solved by DHT. > > But I was and is looking a solution for is the issue of "I'm already > > connected and now how would "I" know when one of my buddies come > > online?". > > I we assume that two people are always in each others buddy list a > person who comes online can look up all his buddies on the DHT and send > them a direct notification that he is online. Except for some > complications when both parties are firewalled (which would require a > solution anyway if you want to do anything useful) I see no problems > with this approach. Am I missing something? > > -- > Markus Kern > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From markus-kern at gmx.net Tue Mar 22 20:12:12 2005 From: markus-kern at gmx.net (Markus Kern) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: <7fcef5ea05032211466b7c1e0c@mail.gmail.com> References: <7fcef5ea05032202273e639715@mail.gmail.com> <7fcef5ea050322100027240f08@mail.gmail.com> <4535036343.20050322191712@gmx.net> <7fcef5ea05032211466b7c1e0c@mail.gmail.com> Message-ID: <8641936156.20050322211212@gmx.net> On Tuesday, March 22, 2005, 8:46:09 PM Anoop Mavilaveettil wrote: > Well it is not that simple. > 1)First, it is not necessary or mandatory that "two people are always > in each other's buddy list". A user might have added another user in > his buddy list, but not the other way. In this case when the second > guy comes online, the first guy would never get a notification. It is not necessary for the list to be the buddy list of course. You could keep a list at each user where you add people to be notified automatically. > 2)Second. One major issue, that I have to point out, is that I'm not > talking about peers, I am talking about users. A user can connect to > the p2p net using any peers. > Let me explain a common scenario > a) User1 connects to the p2p net using peer1. > b)User2 connects to the p2p net using peer2. > c)User1 using common message mechanisms add user2(NOT PEER2) as his > buddy. But the main thing to note, is that User2 doesn't even > know/don't care to know about user1 adding him to buddy list and user2 > never adds user1 in his buddy lists. > d)User2 disconnects from the p2p net. At this time, we can possibly > have some notification mechanisms, which will notify user1@peer1 about > the disconnection of user2. > e)User2 connects to the p2p net from peer3. ---> And here lies my > issue. How would user1@peer1 would know about the arrival of > user2@peer3( without structured or limited flooding?) > NAT traversal and all other issues are lower level ones, and solutions > for those issues are well documented and easily available on the web. It is not entirely clear to me what distinguishes a user from a peer in your case but I assume it is that the user cannot maintain a state between connections to peers. In this case the best place to store the list of people to be notified when the user comes online is probably the DHT (where the buddy list would be anyway?). If you want some sort of event notification you will naturally need a list of event sinks. Where you store this list is largely irrelevant but it makes sense to store it close to the event source. -- Markus Kern From gbildson at limepeer.com Tue Mar 22 22:24:01 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: <8641936156.20050322211212@gmx.net> Message-ID: > On Tuesday, March 22, 2005, 8:46:09 PM Anoop Mavilaveettil > wrote: > > > Well it is not that simple. > > 1)First, it is not necessary or mandatory that "two people are always > > in each other's buddy list". A user might have added another user in > > his buddy list, but not the other way. In this case when the second > > guy comes online, the first guy would never get a notification. > > It is not necessary for the list to be the buddy list of course. You > could keep a list at each user where you add people to be notified > automatically. You can't update your list of who to notify when you are offline. Thus, the DHT would have to store that information at the least. > > > 2)Second. One major issue, that I have to point out, is that I'm not > > talking about peers, I am talking about users. A user can connect to > > the p2p net using any peers. > > > Let me explain a common scenario > > a) User1 connects to the p2p net using peer1. > > b)User2 connects to the p2p net using peer2. > > c)User1 using common message mechanisms add user2(NOT PEER2) as his > > buddy. But the main thing to note, is that User2 doesn't even > > know/don't care to know about user1 adding him to buddy list and user2 > > never adds user1 in his buddy lists. > > d)User2 disconnects from the p2p net. At this time, we can possibly > > have some notification mechanisms, which will notify user1@peer1 about > > the disconnection of user2. > > e)User2 connects to the p2p net from peer3. ---> And here lies my > > issue. How would user1@peer1 would know about the arrival of > > user2@peer3( without structured or limited flooding?) > > NAT traversal and all other issues are lower level ones, and solutions > > for those issues are well documented and easily available on the web. > I don't see how logging on to a third peer would be any different than logging on to a second peer. The only potential problem that I see is that when moving computer to computer, you can't store state and thus need all information (including your own buddy list) stored in a distributed database with security and privacy measures in place for access. The network would need to store your information permanently. This is an area that I have been thinking about for quite a while. How could you build a distributed friendster for example? I presume that it would be fairly hard to build a perfect fault-tolerant P2P database. To achieve this more easily it would be useful to have a third class of network resources that could provide a longer lived source of data. These federated data servers would not need to be totally centralized but hopefully, they would also not be totally transient like standard P2P clients. The P2P clients could upload a timestamped version of the data from the federated data servers for heavy access and indexing purposes during active use. Publishing changes would have to go back to the data servers. Ideally, some users would be willing to run these longer lived servers and provide this resource to their network of interest. The alternative to these hosts might be to detect long uptime clients and make use of these as data hosts with heavy replication. Anyways, this may be totally different from what Sreedhar was asking about but I find it to be an interesting question. Thanks -greg From nlothian at educationau.edu.au Tue Mar 22 22:29:26 2005 From: nlothian at educationau.edu.au (Nick Lothian) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Interest based locality and query distribution Message-ID: Joe Kraus (the founder of Excite from back when Excite actually had their own search engine) has posted about the distribution of queries on Excite at http://bnoopy.typepad.com/bnoopy/2005/03/the_long_tail_o.html While it isn't P2P I suspect that the user's behaviour would be similar. "The most interesting statistic however, was that while the top 10 searches were thousands of times more popular than the average search, these top-10 searches represented only 3% of our total volume. 97% of our traffic came from the "long tail" - queries asked a little over once a day." Nick > -----Original Message----- > From: p2p-hackers-bounces@zgp.org > [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Alexander L?ser > Sent: Wednesday, 23 March 2005 1:44 AM > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] Interest based locality and query distribution > > Hi all > recently several unstructured peer-to-peer systems > dynamically select neighbours for each peer using the > principle of interest-based locality, e.g. [1,2,3,4]. To > model and simulate the behaviour in such networks information > about the distribution of interests of each user, e.g. the > queries each user issues and the content each user publishes, > is required. I'm interested to prove the following hypotheses: > > 1.) Queries follow a Zipf distribution, only a few queries > are highly popular, while the majority of the queries cover > only rare topics. > 2.) A minority of users issues the majority of all queries. > 3.) It is very likely, that these users also stay for a long > time in the network. > 4.) Most of the queries cover only own interests. What > percentage of queries is issued to 'random' topics? > 5.) User interests follow a Zipf distribution, e.g. a user > spends much of her queries to only one or two topics. > > Does anybody know citations from real file sharing trace, > e.g. Gnutella, Kazaa that support or reject my hypotheses? > > Alex > > > [1] V. Cholvi, P. Felber, and E.W. Biersack. Efficient Search > in Unstructured Peer-to-Peer Networks. > [2] Adriana Iamnitchi, Matei Ripeanu and Ian Foster, Small > World File Sharing Communities. > [3] J. Keller, D. Stern and F. Dang Ngoc. MAAY: A > Self-Adaptive Peer Network for Efficient Document Search. > [4] Efficient Content Location Using Interest Based Locality > in Peer-to-Peer Systems > http://www.ieee-infocom.org/2003/papers/53_01.PDF > > -- > > ___________________________________________________________ > > Alexander L?ser > Technische Universit?t Berlin > http://cis.cs.tu-berlin.de/~aloeser/ > office : +49- 30-314-25551 > fax : +49- 30-314-21601 > ___________________________________________________________ > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From anoopsmv at gmail.com Wed Mar 23 01:09:36 2005 From: anoopsmv at gmail.com (Anoop Mavilaveettil) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: References: <8641936156.20050322211212@gmx.net> Message-ID: <7fcef5ea0503221709715d7bc1@mail.gmail.com> > I don't see how logging on to a third peer would be any different than > logging on to a second peer. The only potential problem that I see is that > when moving computer to computer, you can't store state and thus need all > information (including your own buddy list) stored in a distributed database > with security and privacy measures in place for access. Exactly, That exactly is my issue. Couldn't have said it much better I guess, my English is real poor to convey ideas -:). > To achieve this more easily it would be useful to have a third class of network > resources that could provide a longer lived source of data. Again, bingo!. If you see my first post, this is exactly where I'm at now. Basically having another overlay of super peers which would do the indexing and other mundane stuff(some thing like fast track) But honestly, I was not really satisfied/happy with the design and that's why I posted here. My ideal p2p system( and I know in real world, ideal stuff rarely exist) wouldn't/shouldn't need any extra infrastructure, except may be some bootstrap nodes. Any one can connect, publish information about himself and start working. > Anyways, this may be totally different from what > Sreedhar was asking about but I find it to be an interesting question. Nope, this is not totally different from what I have in mind and infact exactly what I have in mind. thanks, -Sreedhar From eugen at leitl.org Wed Mar 23 08:07:48 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] [i2p] weekly status notes [mar 22] (fwd from jrandom@i2p.net) Message-ID: <20050323080748.GG17303@leitl.org> ----- Forwarded message from jrandom ----- From: jrandom Date: Tue, 22 Mar 2005 12:59:29 -0800 To: i2p@i2p.net Subject: [i2p] weekly status notes [mar 22] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi y'all, quick status update * Index 1) 0.5.0.3 2) batching 3) updating 4) ??? * 0.5.0.3 The new release is out and about, and most of y'all have upgraded fairly quickly - thanks! There were some bugfixes to various issues, but nothing revolutionary - the biggest part was dropping 0.5 and 0.5.0.1 users off the net. I've been tracking the net's behavior since then, digging through what's going on, and while there has been some improvement, there are still some things that need to get sorted out. There'll be a new release in the next day or two with a bugfix for an issue that no one has run into yet, but that breaks the new batching code. There will also be some tools for automating the update process according to the user's preferences, along with other minor things. * batching As I mentioned in my blog, there's room for dramatically reducing the bandwidth and message count required on the net by doing some very simple batching of tunnel messages - rather than putting each I2NP message, regardless of size, in a tunnel message of its own, by adding in a brief delay we can bundle up to 15 or more within a single tunnel message. The biggest gains there will occur with services that use small messages (such as IRC), while large file transfers will not be affected by this much. The code to perform the batching has been implemented and tested, but unfortunately there's a bug on the live net which would cause all but the first I2NP message within a tunnel message to be lost. Thats why we're going to have an interim release with that fix in it, followed by the batching release a week or so after that. * updating In this interim release, we're going to be shipping some of the oft discussed 'autoupdate' code. We've got the tools to periodically check for authentic update announcements, download the update either anonymously or not, and then either install it or simply display a notice on the router console telling you that its ready and waiting for installation. The update itself will now use smeghead's new signed update format which is essentially the update plus a DSA signature. The keys used to verify that signature will be bundled with I2P, as well as configurable on the router console. The default behavior will be to simply periodically check for update announcements but not to act on them - just to display a one-click "Update now" feature on the router console. There will be lots of other scenarios for different user needs, but they'll hopefully all be accounted for through a new configuration page. * ??? I'm feeling a bit under the weather, so the above doesn't really go into all the detail about whats up. Swing on by the meeting and fill in the gaps :) Oh, as an aside, I'll be pushing out a new PGP key for myself in the next day or two as well (since this one expires shortly...), so keep an eye out. =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFCQIW+GnFL2th344YRAj03AKCAwDNl6Dr/4Xi6l9x4kOhw8YIkEwCglfFc 98JQv3aXNdaBiA65c5DP8c8= =qfoJ -----END PGP SIGNATURE----- _______________________________________________ i2p mailing list i2p@i2p.net http://i2p.dnsalias.net/mailman/listinfo/i2p ----- End forwarded message ----- -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050323/30a24ffc/attachment.pgp From etienne.riviere at irisa.fr Wed Mar 23 15:27:56 2005 From: etienne.riviere at irisa.fr (Etienne Riviere) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Interest based locality and query distribution In-Reply-To: <4240363A.B3644F47@cs.tu-berlin.de> References: <4240363A.B3644F47@cs.tu-berlin.de> Message-ID: <42418AFC.3020708@irisa.fr> Hi Alexander, I think you should have interest in these two publications that give some hints about your questions. I'm interest in users behaviour modeling also, and i'll try to match your hypothesis against some real trace (from FastTrack (Kazaa)) i have. [1] is dealing about a trace gathered from a crawl of thousands of edonkey clients (what is obtained is cache contents). This can exhibit some interest for your questions. What is shown is the effect of removing 'generous uploaders' from the network, among other measurements. On-going work in our lab is on fine-grain exploitation of semantic clustering. [2] is about proximity of users in the same trace (both geographical and interest based) Best regards. Etienne [1] : Sidath Handurukande, Anne-Marie Kermarrec, Fabrice Le Fessant, and Laurent Massouli?. *Exploiting Semantic Clustering in the eDonkey P2P network*. In /SIGOPS European Workshop/, Leuven, Belgium, pages 109-114, September 2004. http://www.irisa.fr/paris/Biblio/Papers/Kermarrec/HanKerLefMas04EWSIGOPS.pdf [2] : Fabrice Le Fessant, Sidath Handurukande, Anne-Marie Kermarrec, and Laurent Massouli?. *Clustering in Peer-to-Peer File Sharing Workloads*. In /3rd International Workshop on Peer-to-peer systems (IPTPS 04)/, San Diego, CA, February 2004. http://iptps04.cs.ucsd.edu/papers/le-fessant-clustering.pdf Alexander L?ser a ?crit : >Hi all >recently several unstructured peer-to-peer systems dynamically select >neighbours for each peer using the principle of interest-based locality, >e.g. [1,2,3,4]. To model and simulate the behaviour in such networks >information about the distribution of interests of each user, e.g. the >queries each user issues and the content each user publishes, is >required. I'm interested to prove the following hypotheses: > >1.) Queries follow a Zipf distribution, only a few queries are highly >popular, while the majority of the queries cover only rare topics. >2.) A minority of users issues the majority of all queries. >3.) It is very likely, that these users also stay for a long time in the >network. >4.) Most of the queries cover only own interests. What percentage of >queries is issued to 'random' topics? >5.) User interests follow a Zipf distribution, e.g. a user spends much >of her queries to only one or two topics. > >Does anybody know citations from real file sharing trace, e.g. Gnutella, >Kazaa that support or reject my hypotheses? > >Alex > > >[1] V. Cholvi, P. Felber, and E.W. Biersack. Efficient Search in >Unstructured Peer-to-Peer Networks. >[2] Adriana Iamnitchi, Matei Ripeanu and Ian Foster, Small World File >Sharing Communities. >[3] J. Keller, D. Stern and F. Dang Ngoc. MAAY: A Self-Adaptive Peer >Network for Efficient Document Search. >[4] Efficient Content Location Using Interest Based Locality in >Peer-to-Peer Systems http://www.ieee-infocom.org/2003/papers/53_01.PDF > >-- >___________________________________________________________ > > Alexander L?ser > Technische Universit?t Berlin > http://cis.cs.tu-berlin.de/~aloeser/ > office : +49- 30-314-25551 > fax : +49- 30-314-21601 >___________________________________________________________ > > >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > -- Etienne Riviere - PhD candidate - PARIS project Office E208 - IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France T?l: +33 (0)2 99 84 71 48, Fax: +33 (0)2 99 84 71 71 http://www.irisa.fr/paris/pages-perso/Etienne-Riviere MajecSTIC'05 : 16, 17 & 18 Nov., Rennes : http://majecstic05.irisa.fr From gbildson at limepeer.com Wed Mar 23 16:08:29 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: <7fcef5ea0503221709715d7bc1@mail.gmail.com> Message-ID: So, I guess the interesting followup question might be - does OceanStore or Tapestry, etc, have any unique and easily communicable insight into the issue of distributed long-term data storage. Or, do we really need a third class of network participant with closer to server-like long uptime, perhaps a stable ip and able to dedicate a meaningful amount of storage. In this latter case, I'm thinking about people dedicating a chunk of their linux(/web?) server to a network that they believe in. Thanks -greg > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of Anoop Mavilaveettil > Sent: Tuesday, March 22, 2005 8:10 PM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] A Question about user awareness in p2p > > > > I don't see how logging on to a third peer would be any different than > > logging on to a second peer. The only potential problem that I > see is that > > when moving computer to computer, you can't store state and > thus need all > > information (including your own buddy list) stored in a > distributed database > > with security and privacy measures in place for access. > > Exactly, That exactly is my issue. Couldn't have said it much better I > guess, my English is real poor to convey ideas -:). > > > To achieve this more easily it would be useful to have a third > class of network > > resources that could provide a longer lived source of data. > > Again, bingo!. If you see my first post, this is exactly where I'm at > now. Basically having another overlay of super peers which would do > the indexing and other mundane stuff(some thing like fast track) > But honestly, I was not really satisfied/happy with the design and > that's why I posted here. My ideal p2p system( and I know in real > world, ideal stuff rarely exist) wouldn't/shouldn't need any extra > infrastructure, except may be some bootstrap nodes. Any one can > connect, publish information about himself and start working. > > > Anyways, this may be totally different from what > > Sreedhar was asking about but I find it to be an interesting question. > > Nope, this is not totally different from what I have in mind and > infact exactly what I have in mind. > > thanks, > -Sreedhar From jrydberg at gnu.org Wed Mar 23 17:02:13 2005 From: jrydberg at gnu.org (Johan Rydberg) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Network simulation Message-ID: <87u0n2b8iy.fsf@night.trouble.net> Do anyone know of a "good" network library, besides providing a sane API, also provides the possibility to simulate the network in a deterministic environment? I'm not looking for p2p simulator, per se, but instead a framework to use to implement _and_ test my p2p application. ~j From justin7 at gmail.com Wed Mar 23 17:12:37 2005 From: justin7 at gmail.com (Justin Schmidt) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Network simulation In-Reply-To: <87u0n2b8iy.fsf@night.trouble.net> References: <87u0n2b8iy.fsf@night.trouble.net> Message-ID: OPNET's software is generally regarded as the best, but it is a commercial product. Perhaps you have access to an academic version of Modeler? I haven't used ns/ns-2 in a few years, but that used to be a workable alternative. J On Wed, 23 Mar 2005 18:02:13 +0100, Johan Rydberg wrote: > Do anyone know of a "good" network library, besides providing a sane > API, also provides the possibility to simulate the network in a > deterministic environment? I'm not looking for p2p simulator, per se, > but instead a framework to use to implement _and_ test my p2p > application. > > ~j > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From srhea at cs.berkeley.edu Wed Mar 23 17:53:34 2005 From: srhea at cs.berkeley.edu (Sean C. Rhea) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Network simulation In-Reply-To: <87u0n2b8iy.fsf@night.trouble.net> References: <87u0n2b8iy.fsf@night.trouble.net> Message-ID: On Mar 23, 2005, at 9:02 AM, Johan Rydberg wrote: > Do anyone know of a "good" network library, besides providing a sane > API, also provides the possibility to simulate the network in a > deterministic environment? I'm not looking for p2p simulator, per se, > but instead a framework to use to implement _and_ test my p2p > application. It doesn't simulate bandwidth restrictions (only latency), but the simulator that comes with Bamboo (bamboo-dht.org) will allow you to run the same code under simulation and on real networks. It has a BSD license. Sean -- Men who have discovered the limits of arrogance make better company: You notice more when you're not running around imposing your will on everything. -- Virginia Vitzthum -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050323/167efcc3/PGP.pgp From srhea at cs.berkeley.edu Wed Mar 23 18:02:33 2005 From: srhea at cs.berkeley.edu (Sean C. Rhea) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] A Question about user awareness in p2p In-Reply-To: References: Message-ID: <9d97d8ca84f7a7fb8d127c7517b4ec3c@cs.berkeley.edu> On Mar 23, 2005, at 8:08 AM, Greg Bildson wrote: > So, I guess the interesting followup question might be - does > OceanStore or Tapestry, etc, have any unique and easily communicable > insight into the > issue of distributed long-term data storage. Tapestry just stores pointers to data stored on other hosts. The OceanStore model is exactly what you mention below: more stable hosts (possibly provided as part of a commercial infrastructure, possibly not) provide storage resources to the system. On top of that, Hakim Weatherspoon has done some work on identifying sets of machines that are likely to be failure-independent, so that you don't replicate/erasure code a file onto a bunch of hosts that all fail at the same time. One tricky part of all of this is accounting. How do you know that the host that says it's storing your files is actually doing so without random sampling all the time? The Samsara paper is the only published work I know of that looked at this right now. > Or, do we really need a third class of network participant with closer > to > server-like long uptime, perhaps a stable ip and able to dedicate a > meaningful amount of storage. In this latter case, I'm thinking about > people dedicating a chunk of their linux(/web?) server to a network > that > they believe in. The other tricky part is consistency. If you don't trust these hosts completely, you need something like a Byzantine agreement protocol. The actual protocols aren't too bad (although they're a little tricky to code), but mapping the files to hosts as they come and go and adjusting the protocol to handle those changes is hard. More specifically, you have to handle the case where so much churn goes on that none of the original participants in the agreement group is around any more after some period of time. I'm not aware of any published work on how to handle it. Sean -- To announce that there must be no criticism of the president or that we are to stand by the president right or wrong is not only unpatriotic and servile but is morally treasonable to the American public. -- Theodore Roosevelt -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050323/a6be3f47/PGP.pgp From rushhour33 at comcast.net Wed Mar 23 22:40:51 2005 From: rushhour33 at comcast.net (Russell Grayson) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Interest based locality and query distribution References: <4240363A.B3644F47@cs.tu-berlin.de> <42418AFC.3020708@irisa.fr> Message-ID: <001501c52ff9$5de9e920$3feef545@chip> Sorry to ask guys buy does anyone know of a p2p site where I can get free porn with out spy-ware being downloaded on my HDD? I hope this does'nt offend any one . . . if so Im sorry . ----- Original Message ----- From: "Etienne Riviere" To: "Peer-to-peer development." Sent: Wednesday, March 23, 2005 10:27 AM Subject: Re: [p2p-hackers] Interest based locality and query distribution > Hi Alexander, > > I think you should have interest in these two publications that give > some hints about your questions. I'm interest in users behaviour > modeling also, and i'll try to match your hypothesis against some real > trace (from FastTrack (Kazaa)) i have. > > [1] is dealing about a trace gathered from a crawl of thousands of > edonkey clients (what is obtained is cache contents). This can exhibit > some interest for your questions. What is shown is the effect of > removing 'generous uploaders' from the network, among other > measurements. On-going work in our lab is on fine-grain exploitation of > semantic clustering. > > [2] is about proximity of users in the same trace (both geographical and > interest based) > > Best regards. > Etienne > > [1] : Sidath Handurukande, Anne-Marie Kermarrec, Fabrice Le Fessant, and > Laurent Massouli?. *Exploiting Semantic Clustering in the eDonkey P2P > network*. In /SIGOPS European Workshop/, Leuven, Belgium, pages 109-114, > September 2004. > http://www.irisa.fr/paris/Biblio/Papers/Kermarrec/HanKerLefMas04EWSIGOPS.pdf > > > [2] : Fabrice Le Fessant, Sidath Handurukande, Anne-Marie Kermarrec, and > Laurent Massouli?. *Clustering in Peer-to-Peer File Sharing Workloads*. > In /3rd International Workshop on Peer-to-peer systems (IPTPS 04)/, San > Diego, CA, February 2004. > http://iptps04.cs.ucsd.edu/papers/le-fessant-clustering.pdf > > > Alexander L?ser a ?crit : > > >Hi all > >recently several unstructured peer-to-peer systems dynamically select > >neighbours for each peer using the principle of interest-based locality, > >e.g. [1,2,3,4]. To model and simulate the behaviour in such networks > >information about the distribution of interests of each user, e.g. the > >queries each user issues and the content each user publishes, is > >required. I'm interested to prove the following hypotheses: > > > >1.) Queries follow a Zipf distribution, only a few queries are highly > >popular, while the majority of the queries cover only rare topics. > >2.) A minority of users issues the majority of all queries. > >3.) It is very likely, that these users also stay for a long time in the > >network. > >4.) Most of the queries cover only own interests. What percentage of > >queries is issued to 'random' topics? > >5.) User interests follow a Zipf distribution, e.g. a user spends much > >of her queries to only one or two topics. > > > >Does anybody know citations from real file sharing trace, e.g. Gnutella, > >Kazaa that support or reject my hypotheses? > > > >Alex > > > > > >[1] V. Cholvi, P. Felber, and E.W. Biersack. Efficient Search in > >Unstructured Peer-to-Peer Networks. > >[2] Adriana Iamnitchi, Matei Ripeanu and Ian Foster, Small World File > >Sharing Communities. > >[3] J. Keller, D. Stern and F. Dang Ngoc. MAAY: A Self-Adaptive Peer > >Network for Efficient Document Search. > >[4] Efficient Content Location Using Interest Based Locality in > >Peer-to-Peer Systems http://www.ieee-infocom.org/2003/papers/53_01.PDF > > > >-- > >___________________________________________________________ > > > > Alexander L?ser > > Technische Universit?t Berlin > > http://cis.cs.tu-berlin.de/~aloeser/ > > office : +49- 30-314-25551 > > fax : +49- 30-314-21601 > >___________________________________________________________ > > > > > >_______________________________________________ > >p2p-hackers mailing list > >p2p-hackers@zgp.org > >http://zgp.org/mailman/listinfo/p2p-hackers > >_______________________________________________ > >Here is a web page listing P2P Conferences: > >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > > > -- > Etienne Riviere - PhD candidate - PARIS project > Office E208 - IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France > T?l: +33 (0)2 99 84 71 48, Fax: +33 (0)2 99 84 71 71 > http://www.irisa.fr/paris/pages-perso/Etienne-Riviere > MajecSTIC'05 : 16, 17 & 18 Nov., Rennes : http://majecstic05.irisa.fr > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From lgonze at panix.com Wed Mar 23 23:31:51 2005 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Interest based locality and query distribution In-Reply-To: <001501c52ff9$5de9e920$3feef545@chip> References: <4240363A.B3644F47@cs.tu-berlin.de> <42418AFC.3020708@irisa.fr> <001501c52ff9$5de9e920$3feef545@chip> Message-ID: Try Pastry. On Wed, 23 Mar 2005, Russell Grayson wrote: > Sorry to ask guys buy does anyone know of a p2p site where I can get free > porn with out spy-ware being downloaded on my HDD? I hope this does'nt > offend any one . . . if so Im sorry . > ----- Original Message ----- > From: "Etienne Riviere" > To: "Peer-to-peer development." > Sent: Wednesday, March 23, 2005 10:27 AM > Subject: Re: [p2p-hackers] Interest based locality and query distribution > > >> Hi Alexander, >> >> I think you should have interest in these two publications that give >> some hints about your questions. I'm interest in users behaviour >> modeling also, and i'll try to match your hypothesis against some real >> trace (from FastTrack (Kazaa)) i have. >> >> [1] is dealing about a trace gathered from a crawl of thousands of >> edonkey clients (what is obtained is cache contents). This can exhibit >> some interest for your questions. What is shown is the effect of >> removing 'generous uploaders' from the network, among other >> measurements. On-going work in our lab is on fine-grain exploitation of >> semantic clustering. >> >> [2] is about proximity of users in the same trace (both geographical and >> interest based) >> >> Best regards. >> Etienne >> >> [1] : Sidath Handurukande, Anne-Marie Kermarrec, Fabrice Le Fessant, and >> Laurent Massouli?. *Exploiting Semantic Clustering in the eDonkey P2P >> network*. In /SIGOPS European Workshop/, Leuven, Belgium, pages 109-114, >> September 2004. >> > http://www.irisa.fr/paris/Biblio/Papers/Kermarrec/HanKerLefMas04EWSIGOPS.pdf >> >> >> [2] : Fabrice Le Fessant, Sidath Handurukande, Anne-Marie Kermarrec, and >> Laurent Massouli?. *Clustering in Peer-to-Peer File Sharing Workloads*. >> In /3rd International Workshop on Peer-to-peer systems (IPTPS 04)/, San >> Diego, CA, February 2004. >> http://iptps04.cs.ucsd.edu/papers/le-fessant-clustering.pdf >> >> >> Alexander L?ser a ?crit : >> >>> Hi all >>> recently several unstructured peer-to-peer systems dynamically select >>> neighbours for each peer using the principle of interest-based locality, >>> e.g. [1,2,3,4]. To model and simulate the behaviour in such networks >>> information about the distribution of interests of each user, e.g. the >>> queries each user issues and the content each user publishes, is >>> required. I'm interested to prove the following hypotheses: >>> >>> 1.) Queries follow a Zipf distribution, only a few queries are highly >>> popular, while the majority of the queries cover only rare topics. >>> 2.) A minority of users issues the majority of all queries. >>> 3.) It is very likely, that these users also stay for a long time in the >>> network. >>> 4.) Most of the queries cover only own interests. What percentage of >>> queries is issued to 'random' topics? >>> 5.) User interests follow a Zipf distribution, e.g. a user spends much >>> of her queries to only one or two topics. >>> >>> Does anybody know citations from real file sharing trace, e.g. Gnutella, >>> Kazaa that support or reject my hypotheses? >>> >>> Alex >>> >>> >>> [1] V. Cholvi, P. Felber, and E.W. Biersack. Efficient Search in >>> Unstructured Peer-to-Peer Networks. >>> [2] Adriana Iamnitchi, Matei Ripeanu and Ian Foster, Small World File >>> Sharing Communities. >>> [3] J. Keller, D. Stern and F. Dang Ngoc. MAAY: A Self-Adaptive Peer >>> Network for Efficient Document Search. >>> [4] Efficient Content Location Using Interest Based Locality in >>> Peer-to-Peer Systems http://www.ieee-infocom.org/2003/papers/53_01.PDF >>> >>> -- >>> ___________________________________________________________ >>> >>> Alexander L?ser >>> Technische Universit?t Berlin >>> http://cis.cs.tu-berlin.de/~aloeser/ >>> office : +49- 30-314-25551 >>> fax : +49- 30-314-21601 >>> ___________________________________________________________ >>> >>> >>> _______________________________________________ >>> p2p-hackers mailing list >>> p2p-hackers@zgp.org >>> http://zgp.org/mailman/listinfo/p2p-hackers >>> _______________________________________________ >>> Here is a web page listing P2P Conferences: >>> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences >>> >>> >> >> -- >> Etienne Riviere - PhD candidate - PARIS project >> Office E208 - IRISA-INRIA, Campus de Beaulieu, 35042 Rennes cedex, France >> T?l: +33 (0)2 99 84 71 48, Fax: +33 (0)2 99 84 71 71 >> http://www.irisa.fr/paris/pages-perso/Etienne-Riviere >> MajecSTIC'05 : 16, 17 & 18 Nov., Rennes : http://majecstic05.irisa.fr >> >> >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@zgp.org >> http://zgp.org/mailman/listinfo/p2p-hackers >> _______________________________________________ >> Here is a web page listing P2P Conferences: >> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From ardagna at dti.unimi.it Thu Mar 24 11:24:21 2005 From: ardagna at dti.unimi.it (Claudio Agostino Ardagna) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] REMINDER: CFP - ESORICS 2005: Deadline extension (April 1) Message-ID: <020601c53064$068353e0$0b00000a@Berlino> [Apologies if you receive multiple copies of this message] CALL FOR PAPERS ESORICS 2005 10TH EUROPEAN SYMPOSIUM ON RESEARCH IN COMPUTER SECURITY Milan, Italy - September 14-16, 2005 http://esorics05.dti.unimi.it/ ************************************************************************ Due to several requests the deadline is extended to April 1, 2005 (firm) ************************************************************************ Papers offering novel research contributions in any aspect of computer security are solicited for submission to the Tenth European Symposium on Research in Computer Security (ESORICS 2005). Organized in a series of European countries, ESORICS is confirmed as the European research event in computer security. The symposium started in 1990 and has been held on alternate years in different European countries and attracts an international audience from both the academic and industrial communities. From 2002 it has been held yearly. The Symposium has established itself as one of the premiere, international gatherings on information assurance. Papers may present theory, technique, applications, or practical experience on topics including: - access control - accountability - anonymity - applied cryptography - authentication - covert channels - cryptographic protocols - cybercrime - data and application security - data integrity - denial of service attacks - dependability - digital right managament - firewalls - formal methods in security - identity management - inference control - information dissemination control - information flow control - information warfare - intellectual property protection - intrusion tolerance - language-based security - network security - non-interference - peer-to-peer security - privacy-enhancing technology - pseudonymity - secure electronic commerce - security administration - security as quality of service - security evaluation - security management - security models - security requirements engineering - security verification - smartcards - steganography - subliminal channels - survivability - system security - transaction management - trust models and trust management policies - trustworthy user devices The primary focus is on high-quality original unpublished research, case studies and implementation experiences. We encourage submissions of papers discussing industrial research and development. Proceedings will be published by Springer-Verlag in the Lecture Notes in Computer Science series. INSTRUCTIONS FOR PAPER SUBMISSIONS Submitted papers must not substantially overlap papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers should be at most 15 pages excluding the bibliography and well-marked appendices (using 11-point font), and at most 20 pages total. Committee members are not required to read the appendices, and so the paper should be intelligible without them. To submit a paper, send to esorics05@dti.unimi.it a plain ASCII text email containing the title and abstract of your paper, the authors' names, email and postal addresses, phone and fax numbers, and identification of the contact author. To the same message, attach your submission (as a MIME attachment) in PDF or portable postscript format. Do NOT send files formatted for word processing packages (e.g., Microsoft Word or WordPerfect files). Submissions not meeting these guidelines risk rejection without consideration of their merits. Submissions must be received by March 25, 2005 in order to be considered. Notification of acceptance or rejection will be sent to authors by May 30, 2005. Authors of accepted papers must be prepared to sign a copyright statement and must guarantee that their paper will be presented at the conference. Authors of accepted papers must follow the Springer Information for Authors' guidelines for the preparation of the manuscript and use the templates provided there. GENERAL CHAIR Pierangela Samarati University of Milan email: samarati@dti.unimi.it PROGRAM CHAIRS Sabrina De Capitani di Vimercati University of Milan email: decapita@dti.unimi.it Paul Syverson Naval Research Laboratory url: www.syverson.org PUBLICATION CHAIR Dieter Gollman TU Hamburg-Harburg email: diego@tuhh.de PUBLICITY CHAIR Claudio A. Ardagna University of Milan, Italy email: ardagna@dti.unimi.it IMPORTANT DATES Paper Submission due: April 1, 2005 (NEW) Notification: May 30, 2005 Final papers due: June 30, 2005 PROGRAM COMMITTEE Rakesh Agrawal IBM Almaden Research Center, USA Gerard Allwein Naval Research Laboratory, USA Ross Anderson University of Cambridge, UK Vijay Atluri Rutgers University, USA Michael Backes IBM Zurich Research Laboratory, Switzerland Giampaolo Bella University of Catania, Italy Jan Camenisch IBM Zurich Research Laboratory, Switzerland David Chadwick University of Kent, UK Marc Dacier Institut Eur?com, France Ernesto Damiani University of Milan, Italy George Danezis University of Cambridge, UK Simon Foley University College, Ireland Philippe Golle Palo Alto Research Center, USA Sushil Jajodia George Mason University, USA Marit Hansen Independent Centre for Privacy Protection Schleswig-Holstein, Germany Philippa Hopcroft Oxford University, UK Dogan Kesdogan RWTH Aachen, Informatik IV, Germany Peng Liu The Pennsylvania State University, USA Javier Lopez University of Malaga, Spain Heiko Mantel ETH-Zentrum, Switzerland Nick Mathewson The Free Haven Project, USA Patrick McDaniel The Pennsylvania State University, USA Peng Ning NC State University, USA Peter Ryan University of Newcastle upon Tyne, UK Kazue Sako NEC Corporation, Japan Pierangela Samarati University of Milan, Italy Vanessa Teague University of Melbourne, Australian Mariemma I. Yague University of Malaga, Spain Alec Yasinsac Florida State University, USA -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050324/d2508aff/attachment.html From travis.parsons at gmail.com Thu Mar 24 21:12:07 2005 From: travis.parsons at gmail.com (Travis Parsons) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Building Sr. Technical Leadership Team for New SIP/P2P Project Message-ID: <4b1e44a205032413126725d33a@mail.gmail.com> Hi ? I'm Travis Parsons and I'm leading a project to create a SIP/P2P platform to support a new consumer-oriented global network for content access, communication, collaboration and multi-person interactive applications. Adam Fisk (Last Bamboo, Limewire); Jed McAleb (MetaMachine, eDonkey); and Henning Schulzrinne (SIP co-author; Columbia University CS Chair) are collaborating as advisors in the design of an enabling technical architecture. I'm building out the technical leadership team that will join this design effort and carry out the implementation of the architecture and functional requirements and participate in the growth of the new company. We're on the very front edge of a big shift in technology that will benefit the early movers. This project/company is based in the Bay Area of California and working together on site as a team is preferred. The ideal timeframe is immediately. Areas of focus for the project include: ? Presence-based, social network applications ? Peer-to-peer (P2P) distributed application architectures ? Session Initiated Protocol (SIP) based multi-media communications ? Ubiquitous application access, cross-device compatibility and mobility ? Open platform orientation for creation and delivery of third-party applications to end users Ideal team members possess the following skills and experiences: ? Experience managing large projects, preferably including coordination of automated testing, builds, and code coverage. ? P2P/distributed computing experience. ? Network programming experience (TCP and UDP). ? Understanding of SIP preferred. ? Object oriented design skills and experience using design patterns. ? XML experience. ? Experience with "agile" processes preferred, code reviews, test-driven development, etc. ? Java experience. ? C/C++ experience. ? Experience working with multiple platforms and mobile devices preferred. ? Ability to learn new protocols quickly. ? Experience scaling large systems to many thousands of simultaneous users preferred. ? Must believe you are an innovator. ? Must be capable of working in a limited-structure, dynamic, small company environment and have excellent people skills. If you are interested in learning more about the details of this project and how to get involved, please introduce yourself via email. Please provide some background on your interests and experiences to start the dialogue. My email address is travis.parsons@gmail.com I appreciate this forum and the ability to reach out to you. Travis From dbarrett at quinthar.com Sat Mar 26 08:03:14 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Building Sr. Technical Leadership Team for NewSIP/P2P Project In-Reply-To: <4b1e44a205032413126725d33a@mail.gmail.com> Message-ID: <20050326080326.B19843FCA5@capsicum.zgp.org> Hi there, I'd love to learn more about your project. You describe it as a "SIP/P2P platform to support a new consumer-oriented global network for content access, communication, collaboration and multi-person interactive applications." Specifically: 1) Are you building an actual application, a platform on which you expect others to build applications, or both? 2) If the answer to #1 is "both", is your emphasis on creating a platform (and thus the application is merely a proof of concept), or on creating the application (and thus the platform is merely a plugin API with published standards)? 3) Are you recruiting volunteers or paid employees? 4) It sounds like you already have some big guns on board. Are you primarily looking for people to implement a design that's mostly in place, or are you primarily looking for people to flesh out a design? 5) If the answer to #4 is "both" or "to design", that sounds like a lot of cooks in the kitchen. What skills do you, Adam Fisk, Jed McAleb, and Henning Schulzrinne lack that you need before you can have a solid design? 6) If you could describe your final product as "like X but with elements of Y, and with Z, which is totally new"? Thanks! -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Travis Parsons > Sent: Thursday, March 24, 2005 1:12 PM > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] Building Sr. Technical Leadership Team for > NewSIP/P2P Project > > Hi - I'm Travis Parsons and I'm leading a project to create a SIP/P2P > platform to support a new consumer-oriented global network for content > access, communication, collaboration and multi-person interactive > applications. > > Adam Fisk (Last Bamboo, Limewire); Jed McAleb (MetaMachine, eDonkey); > and Henning Schulzrinne (SIP co-author; Columbia University CS Chair) > are collaborating as advisors in the design of an enabling technical > architecture. > > I'm building out the technical leadership team that will join this > design effort and carry out the implementation of the architecture and > functional requirements and participate in the growth of the new > company. We're on the very front edge of a big shift in technology > that will benefit the early movers. > > This project/company is based in the Bay Area of California and > working together on site as a team is preferred. The ideal timeframe > is immediately. > > > Areas of focus for the project include: > > . Presence-based, social network applications > . Peer-to-peer (P2P) distributed application architectures > . Session Initiated Protocol (SIP) based multi-media communications > . Ubiquitous application access, cross-device compatibility and > mobility > . Open platform orientation for creation and delivery of third-party > applications to end users > > > Ideal team members possess the following skills and experiences: > > . Experience managing large projects, preferably including > coordination of automated testing, builds, and code coverage. > . P2P/distributed computing experience. > . Network programming experience (TCP and UDP). > . Understanding of SIP preferred. > . Object oriented design skills and experience using design patterns. > . XML experience. > . Experience with "agile" processes preferred, code reviews, > test-driven development, etc. > . Java experience. > . C/C++ experience. > . Experience working with multiple platforms and mobile devices > preferred. > . Ability to learn new protocols quickly. > . Experience scaling large systems to many thousands of simultaneous > users preferred. > . Must believe you are an innovator. > . Must be capable of working in a limited-structure, dynamic, small > company environment and have excellent people skills. > > > If you are interested in learning more about the details of this > project and how to get involved, please introduce yourself via email. > Please provide some background on your interests and experiences to > start the dialogue. My email address is travis.parsons@gmail.com > > I appreciate this forum and the ability to reach out to you. > > Travis > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From travis at redswoosh.net Tue Mar 29 23:21:05 2005 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Your contact info Message-ID: <1112138465.31853.34975.sendUpdate@mx.plaxo.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: Travis Kalanick.vcf Type: text/x-vcard Size: 348 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050329/9c226263/TravisKalanick.vcf From ian at locut.us Tue Mar 29 23:26:47 2005 From: ian at locut.us (Ian Clarke) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Your contact info In-Reply-To: <1112138465.31853.34975.sendUpdate@mx.plaxo.com> References: <1112138465.31853.34975.sendUpdate@mx.plaxo.com> Message-ID: I think Travis may have a virus :-) Ian. On 30 Mar 2005, at 00:21, Travis Kalanick wrote: > Peer-to-peer, > > I'm updating my address book. Please take a moment to update your > latest contact information. Your information is stored in my personal > address book and will not be shared with anyone else. Plaxo is free, > if you'd like to give it a try. > > Travis Kalanick > travis@redswoosh.net > Red Swoosh, Inc. -- Founder, The Freenet Project http://freenetproject.org/ CEO, Cematics Ltd http://cematics.com/ Personal Blog http://locut.us/~ian/blog/ From travis at redswoosh.net Tue Mar 29 23:29:03 2005 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Your contact info In-Reply-To: <1112138465.31853.34975.sendUpdate@mx.plaxo.com> Message-ID: <200503292330.j2TNUMaL001437@be9.noc0.redswoosh.com> Sorry about the Plaxo spam . . :-( Won't happen again! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050329/726f078d/attachment.htm From larytet.8753341 at bloglines.com Wed Mar 30 17:46:52 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] ping eom Message-ID: <1112204812.3432487491.17106.sendItem@bloglines.com> eom From john.casey at gmail.com Wed Mar 30 22:13:21 2005 From: john.casey at gmail.com (John Casey) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] ping eom In-Reply-To: <1112204812.3432487491.17106.sendItem@bloglines.com> References: <1112204812.3432487491.17106.sendItem@bloglines.com> Message-ID: pong On 30 Mar 2005 17:46:52 -0000, larytet.8753341@bloglines.com wrote: > eom > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > From telecontrol at t-online.de Wed Mar 30 23:49:53 2005 From: telecontrol at t-online.de (telecontrol@t-online.de) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Peer2Peer TV Cybersky, the countdown runs Message-ID: <20050330234953.9EEF5407FD7@p15167310.pureserver.info> Dear Cybertelly-Free-TV Friend, please visit http://bytetornado.microdollar.org and insert/update your Broadband user data as soon as possible. The service was stopped due to a temporary injunction by major german tv operator "premiere" and is now expected to start at 12th of april. You will receive a download-link after updating your personal data. Your user name: p2p-hackers@zgp.org Your password: CJ%aa!xo If you want to disable your account, click http://bytetornado.microdollar.org/php/remove.php?UserID=p2p-hackers@zgp.org or click the link "Disable your account" on http://bytetornado.microdollar.org Thanks, the cybertelly team http://www.cybertelly.com From wharms at bfs.de Thu Mar 31 07:16:09 2005 From: wharms at bfs.de (walter harms) Date: Sat Dec 9 22:12:52 2006 Subject: [p2p-hackers] Where to start ? Message-ID: <424BA3B9.3000601@bfs.de> Hi list, I try to collect information from a distributed network. Every Node has a dial-up modem. The sink is also 1 dial-up modem. These modem has to serve ca. 20 Nodes. Simply calling every Node takes 20 units (obvious). The challenge is to gather information from all Nodes (fast) and handle failures I guess this problem must be around since modems exists. Can anyone point me to some resources where i can find programs/literature ? I have found same stuff concerning wireless networks but that doesnt help very much. re, walter