From enzomich at gmail.com Sun Jan 1 15:11:27 2006 From: enzomich at gmail.com (Enzo Michelangeli) Date: Sat Dec 9 22:13:06 2006 Subject: [p2p-hackers] Kademlia and Java References: <20051230102028.9bg4nvglf1b4cw40@webmail.bice.it> Message-ID: <01f201c60ee5$aeab4f40$0200a8c0@em.noip.com> ----- Original Message ----- From: Sent: Friday, December 30, 2005 5:20 PM > I'm looking at a Java implementation of the Kademlia API. > http://kademlia.scs.cs.nyu.edu doesn't work, so I was wondering if > someone have experienced the Plan X 0.4.12 library. There is something > called "org.planx.xmlstore.routing.Kademlia" mentioned in the Javadoc, > that could be useful. > > Is there someone who can help me? Where to find the library and is it > useful? Have you tried http://plan-x.org/ ? And, specifically for the Kademlia part, http://www.thomas.ambus.dk/plan-x/routing/ . > Is there something else implementing Kademlia? Azureus (http://azureus.sourceforge.net/ ) implements Kademlia for its "distributed tracker" feature, and it's written in Java. Of course, its implementation is likely to be incompatible with Plan-X... Enzo From tyler.close at gmail.com Sun Jan 1 22:54:02 2006 From: tyler.close at gmail.com (Tyler Close) Date: Sat Dec 9 22:13:06 2006 Subject: Google 'Safe Browsing' vs. RESTful authorization Re: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization In-Reply-To: <43B4661D.5030301@bitzi.com> References: <5691356f05092710332a623de2@mail.gmail.com> <1127850423.3A956345@bd12.dngr.org> <1127901049.15818.47.camel@p-dvsi-418-1.rd.francetelecom.fr> <5691356f0509280755501a1c1d@mail.gmail.com> <1127922062.15818.82.camel@p-dvsi-418-1.rd.francetelecom.fr> <5691356f050929103656e4f30f@mail.gmail.com> <43B4661D.5030301@bitzi.com> Message-ID: <5691356f0601011454p31a83694s6bf1d415a11b0a8a@mail.gmail.com> Hi Gordon, Thanks for sending this link to the Google 'Safe Browsing' extension. The irony is astounding. I'm not sure what to do about this kind of attack. Since the browser is disclosing all the visited URLs, we have to assume that the attacker now has them. Given this knowledge, the attacker has everything he needs to mount a cross-site authorization (Confused Deputy) attack against a design that relies on HTTP Auth, or session cookies. So in addition to destroying the user's privacy, Google has also made it difficult to protect the user's authority. Assuming use of the 'Safe Browsing' extension and an active attacker, I suspect the access control of most applications on the web today could be circumvented. For an example cross-site authorization attack, see end of the email at: http://groups.yahoo.com/group/rest-discuss/message/5249 I think maintaining a secret URL space is crucial to implementing access control in a WWW application; whether using capability URLs or not. It's sad that people with high level access to critical infrastructure don't understand this. Hopefully, the more obvious privacy issues will be enough to ensure the 'Safe Browsing' extension is not widely deployed. In the past, these privacy concerns have been sufficient to derail similar applications. Tyler On 12/29/05, Gordon Mohr wrote: > I like Tyler's notion of SSL-passed 'capability URLs', and had > occasion to think about them again when reading the following: > > Two Things That Bother Me About Google's New Firefox Extension > http://www.oreillynet.com/pub/wlg/8760 > > "1) Every request is transmitted to Google over HTTP, i.e. in > clear-text. This is not good. Here is why: Consider a web > application that uses SSL to encrypt the session. If this web > application were to submit private information about you via a > GET request (i.e in the URL, such as a credit card number), > this will now be transmitted to > http://www.google.com/safebrowsing/lookup in clear-text, allowing > someone on your network segment, or any router in between yourself > and google.com to sniff the information off the wire." > > Asking a trusted third party their opinion of an URL seems a > reasonable anti-phishing measure. But if that "trusted" third > party is careless in its handling of HTTPS URLs, as it > appears Google has been in this design, the prerequisite > URL secrecy required for capability URLs will be often and > casually violated. > > Of course, any security measure can be thwarted with sufficient > carelessness, and in this case the onus should be on Google to > fix this oversight, and respect the privacy of HTTPS URL requests. > > But it's been 2 weeks since this problem was highlighted, and > it remains unfixed and mostly undiscussed. That suggests to me > that people's expectations of HTTPS URL secrecy -- and of the > standards that toolbar/extension makers like Google should be > held to in protecting user secrets -- are pretty low. Perhaps > so low that capability URLs would only be usable by the > hyper-conscientious, who generally do fine under any system. > > - Gordon > > Tyler Close wrote: > > Hi Antoine, > > > > On 9/28/05, Antoine Pitrou wrote: > >>> On 9/28/05, Antoine Pitrou wrote: > >>>> I'm curious as to how "capability URLs" can't be stolen and re-used by a > >>>> malicious piece of Javascript like other URLs can. > >>> Simply because a capability URL is unguessable. > >> It is permanent too, > > > > No, the lifetime of the URL is up to the application designer. Using > > capability URLs does not place any duration restrictions on how you > > define the lifetime of your resources. > > > >> And you have to keep this URL somewhere... Given that it's full of > >> random ascii garbage, you can't keep it in your head (contrast this with > >> a properly chosen password), and you don't want to copy it by hand > >> either. So it /will/ end up in electronic clickable form somewhere: for > >> example in your bookmarks. > > > > I think keeping capability URLs in your bookmarks is a perfectly > > sensible thing to do, providing you then protect your bookmarks. I run > > OS X, so my entire filesystem is encrypted, including my bookmarks > > file. > > > >> >From your own explanation on the REST mailing-list : ? The user just > >> *clicks on hyperlinks*, without ever needing to be aware of the resource > >> password. ? Those hyperlinks have to be somewhere... > >> > >> (and of course, this totally mandates HTTPS, which is impossible for > >> most Web sites for reasons I already explained) > > > > This argument is a little out of date. You can get affordable HTTPS > > hosting from providers like GoDaddy and 1and1. Even before the advent > > of shared hosting for HTTPS, colocation was already an affordable > > option and likely required anyways in order to get the performance > > characteristics that you want for your web application. For very small > > scale projects, running Apache on your home machine with a dyndns > > hostname and a 7.99 SSL certificate is also doable. > > > >> As a mix proposal, it would be more interesting if a new URL was > >> generated everytime the user identifies (with login/password). More > >> interesting again, it could be generated client side in Javascript using > >> a formula like "HASH(HASH(password) + challenge)" where the challenge is > >> a temporary value generated by the server for this very session (thus > >> with an expiration time). Which means: > >> - the URL is temporary (it expires with the challenge) > >> - this URL does not need to be recorded anywhere on the client since > >> it's generated at every new login > >> - in plain non-encrypted HTTPS, the data which goes over the wire only > >> gives temporary access to the resource > > > > When I attend DefCon, I am always amazed that people are surprised by > > the Wall of Sheep, people who know that network snooping is possible. > > I guess you just have to experience the efficiency of live network > > snooping in order to truly appreciate it. > > > > With the rise of ubiquitous WiFi, passing secrets, even temporary > > ones, over the network in the clear is asking for trouble. Your 15 > > minute session timeout is an eon on the timescale of a script watching > > the network for your protocol and exploiting it on the fly. > > > > SSL has finally come into a somewhat reasonable price range. We should > > go ahead and exploit it. We don't need to mess around with dodgy > > timeout based designs. > > > > Thanks again for the questions. > > > > Tyler > > > > -- > > The web-calculus is the union of REST and capability-based security: > > http://www.waterken.com/dev/Web/ > > > > Name your trusted sites to distinguish them from phishing sites. > > https://addons.mozilla.org/extensions/moreinfo.php?id=957 > > _______________________________________________ > > 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 > > > -- The web-calculus is the union of REST and capability-based security: http://www.waterken.com/dev/Web/ Name your trusted sites to distinguish them from phishing sites. https://addons.mozilla.org/extensions/moreinfo.php?id=957 From coderman at gmail.com Mon Jan 2 03:18:12 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:06 2006 Subject: Google 'Safe Browsing' vs. RESTful authorization Re: [p2p-hackers] Re: [rest-discuss] Re: RESTful authorization In-Reply-To: <5691356f0601011454p31a83694s6bf1d415a11b0a8a@mail.gmail.com> References: <5691356f05092710332a623de2@mail.gmail.com> <1127850423.3A956345@bd12.dngr.org> <1127901049.15818.47.camel@p-dvsi-418-1.rd.francetelecom.fr> <5691356f0509280755501a1c1d@mail.gmail.com> <1127922062.15818.82.camel@p-dvsi-418-1.rd.francetelecom.fr> <5691356f050929103656e4f30f@mail.gmail.com> <43B4661D.5030301@bitzi.com> <5691356f0601011454p31a83694s6bf1d415a11b0a8a@mail.gmail.com> Message-ID: <4ef5fec60601011918m62c20330i6e485963ff9481e9@mail.gmail.com> On 1/1/06, Tyler Close wrote: > ... > I'm not sure what to do about this kind of attack. Since the browser > is disclosing all the visited URLs, we have to assume that the > attacker now has them. Given this knowledge, the attacker has > everything he needs to mount a cross-site authorization (Confused > Deputy) attack against a design that relies on HTTP Auth, or session > cookies. So in addition to destroying the user's privacy, Google has > also made it difficult to protect the user's authority. Assuming use > of the 'Safe Browsing' extension and an active attacker, I suspect the > access control of most applications on the web today could be > circumvented. yeah, that sums it up nicely. for http (not https) you can s/safe browsing/wireless/g. the times when you could be sloppy with auth and get away with it are rapidly ending. > I think maintaining a secret URL space is crucial to implementing > access control in a WWW application; whether using capability URLs or > not. agreed and this is a reasonable and straightfoward process. my personal preference is using a VPN to authenticate users and provide them access to a private network. within this private network any authenticated users may share and collaborate using capability URL's and so forth. the moment a user is revoked (by terminating VPN account) they no longer have any useable capabilities / authority on that private network. likewise, disclosure of the capabilities / session ids / http auth outside of the VPN does not provide an attacker any benefit unless they can also compromise user authentication to get into the VPN. > It's sad that people with high level access to critical > infrastructure don't understand this. Hopefully, the more obvious > privacy issues will be enough to ensure the 'Safe Browsing' extension > is not widely deployed. In the past, these privacy concerns have been > sufficient to derail similar applications. the problem is this will remain an assumption open to abuse. how do you ever really _know_ that such an active attack is not mounted? especially over wireless? VPN's are a reasonable solution and perhaps with enough interest and developer motivation they can be made much more usable and common than they currently are. on this note, the new SSH will support OpenVPN style networks using tun/tap devices: http://www.securityfocus.com/columnists/375 see also: http://openvpn.net/ From luca.piccarreta at gmail.com Mon Jan 2 17:36:50 2006 From: luca.piccarreta at gmail.com (Luca Piccarreta) Date: Sat Dec 9 22:13:06 2006 Subject: [p2p-hackers] New project: P2P VPN, sort of... Message-ID: <000701c60fc3$2079cb50$6e1f0e05@bigclit> Hi all, my name is Luca Piccarreta, I've implemented a sort of P2P application (based on a KAD network) with an embedded VPN (well.... not yet private :) based on a TUN driver, and a ridiculous name server which map DNS requests to Kad queries. In the end, the application should be a big firewall opener, on top of which it should be easy to build P2P applications, or to connect to computers behind NAT/firewalls. Of course, all the code has been written in a hurry, but I think that with the help of someone it could become a very nice application. If you want an idea of what it should become, have at look at Hamachi (http://www.hamachi.cc), and add on top of that the ability to refer to peers with friendly name (say http://name_of_an_host.kad) What's there: - KAD network (own flavour, not compatible with Emule or whatever) - TUN interface and forwarding (got from OpenVPN TAP-WIN32 driver and bits and pieces of code) - Nameservice (trivial, but working) - Linux/WIN32 - C++ What's not there: - Message signing/encryption - A nice GUI - Some users... - A home page The project is at sourceforge (http://sourceforge.net/projects/x-kad) Eagerly waiting for volunteers! Luca. From matthew at matthew.at Tue Jan 3 02:19:10 2006 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Amicima's amiciPhone now on Macintosh In-Reply-To: <200511291753.jATHrjU72911@where.matthew.at> Message-ID: <200601030219.k032JIU70139@where.matthew.at> amiciPhone, our Skype-like P2P communicator that does encrypted peer-to-peer VoIP calling, text messaging, user presence, and file transfer (including photo preview when sending images) is now available for the Macintosh (OS X 10.3.9 or later, and PPC-only at this point). Also, the Windows XP version is still available and has been upgraded several times (latest release is Beta 4). This is a great way to try out what MFP and MFPNet can do (both of which have documentation and open-source implementations available on our website, unlike Skype's proprietary protocol model) and we'd also love to hear feedback about the application itself before we add any more features, so give it a try! (and get your friends to give it a try too!) Matthew Kaufman matthew@matthew.at amiciPhone: matthew@test.amicima.com http://www.amicima.com Ps. For a good time, try calling "7" From ks91 at sfc.wide.ad.jp Tue Jan 3 16:28:53 2006 From: ks91 at sfc.wide.ad.jp (Kenji Saito) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Final CFP: DAS-P2P 2006 Message-ID: I hope that all of you had a pleasant and happy new year. This is the final call for papers for DAS-P2P 2006. *** our apologies if you receive multiple copies of this e-mail *** *** the deadline for paper submission is January 8th (firm deadline) *** ****************************************************************************** * The First International Workshop on * Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006) * http://das-p2p.wide.ad.jp/ * * In conjunction with The First International Conference on * Availability, Reliability and Security (ARES 2006). * http://www.ares-conf.org/ * * Vienna University of Technology, Austria * April 20th-22nd, 2006 ****************************************************************************** [CALL FOR PAPERS] The First International Workshop on Dependable and Sustainable Peer-to-Peer Systems (DAS-P2P 2006) is the first workshop which focuses on dependability and sustainability of peer-to-peer (P2P) systems, with respect to their designs, operations, applications and social impacts. P2P can be a promising technology on which we can depend lives of ours and our children, upon which we can build sustainable societies. Designs of P2P systems are characterized by their usage of overlay networks such that there is symmetry in the roles among participants. This implies distribution of authorities, not only preventing introduction of single points of failure, but also assuring a level of autonomy which allows many of us to spontaneously start, maintain, or recover from failures of, such systems. Although difficulties exist, such as uncertainty in the trust among participants, one needs to be aware that such difficulties are, in many parts, due to our own human nature; depending on P2P is, in fact and literally, depending on ourselves and our friends, who seem to be the only ones we can trust anyway, when it comes to our own survival. The goal of this workshop is to share experiences, insights and new ideas, and set forth research agendas and suggestive future directions by collaborations among researchers with different disciplines and with similar interests toward dependability and sustainability. The following is a non-exhaustive list of relevant topics: * Designs and operations of dependable and sustainable P2P systems - Self-organization and emergence - Attack-resistance - Fault tolerance - Sustainable operations - Sustainable mutual trust - Sustainable reciprocal relationships * Applications and social impacts of dependable and sustainable P2P systems - Sustainable economy - Sustainable governance - Sustainable lifestyles - Rescue activities - Post-catastrophic recovery - Tackling environmental problems The program of the workshop will be a combination of invited talks, paper presentations and discussions. [SUBMISSION INSTRUCTIONS] (updated on 2005/10/21) The workshop invites your contributions of previously unpublished papers, which will be selected based on their originality, technical merit and topical relevance. Papers will also be selected by the likelihood that they will lead to interesting and fruitful discussions at the workshop. Your contributions should be formatted acoording to the IEEE Computer Society Press Proceedings Author Guidelines: 10-point Times, single-spaced, two-column format (see http://computer.org/cspress/instruct.htm for detail; if the link does not work, see http://www.tinmith.net/tabletop2006/IEEE/Format/instruct.htm for approximation). Each of your contributions should not exceed 8 pages. See the workshop web site (http://das-p2p.wide.ad.jp/) for the submission procedure. [PUBLICATION] (updated on 2005/10/21) Proceedings of the workshop will be published by IEEE Computer Society Press. [IMPORTANT DATES] (updated on 2005/12/14) Paper submission due: January 8th, 2006 Notification of acceptance: January 18th, 2006 Camera-ready copies due: February 1st, 2006 Author registration due: February 1st, 2006 Workshop: April 20th-22nd, 2006 (exact date is to be decided) [REGISTRATION] Workshop registration will be handled by the ARES 2006 organization along with the main conference registration. [PROGRAM COMMITTEE] * Stephane Bressan, National University of Singapore, Singapore * Bernard Burg, Panasonic Research, USA * Ian Clarke, Freenet Project, UK * Roger Dingledine, The Free Haven Project, USA * Yusuke Doi, TOSHIBA Corporation, Japan (co-chair) * Claudiu Duma, Linkoping University, Sweden * Debojyoti Dutta, University of Southern California, USA * Noria Foukia, University of Otago, New Zealand * Maria Gini, University of Minnesota, USA * Achmad Nizar Hidayanto, University of Indonesia, Indonesia * Sam Joseph, University of Hawaii, USA * Youki Kadobayashi, Nara Instritute of Science and Technology, Japan (co-chair) * Anirban Mondal, University of Tokyo, Japan * Akiko Orita, Keio University, Japan * Omer F Rana, Cardiff University, UK * Kenji Saito, Keio University, Japan (co-chair) * Claudio Sartori, University of Bologna, Italy * Nguyen Manh Tho, Vienna University of Technology, Austria * Sheng Zhong, State University of New York at Buffalo, USA See the workshop web site (http://das-p2p.wide.ad.jp/) for any updates. ----- For further information, please contact program co-chair Kenji Saito, Graduate School of Media and Governance, Keio University, 5322 Endo, Fujisawa, Kanagawa 252-8520 Japan, e-mail: ks91@sfc.wide.ad.jp From Bernard.Traversat at Sun.COM Tue Jan 3 18:58:02 2006 From: Bernard.Traversat at Sun.COM (Bernard Traversat) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] New JXTA Java SE, Java ME and C/C++ releases are available! Message-ID: <43BAC93A.2090406@sun.com> The JXTA (www.jxta.org) community recently announced the availability of three new releases of the JXTA P2P open-source protocols: - JXTA JSE 2.3.6 "Jiggs Dinner" Release (http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=230) - JXME 2.1.1 "Merimde" Release (http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=229) - JXTA-C 2.3 "Bali" Release (http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=231) These releases provide a number of bug fixes, performance improvements, and new enhanced features. These releases have been designed to be API and protocol backwards compatible with previous JXTA releases. All three implementations are fully interoperable. You can access these releases via the jxta.org download page: http://www.jxta.org/download.html Cheers and Happy New Year! B. --http://weblogs.java.net/blog/tra "As Java implies platform independence, and XML implies language independence, JXTA implies network independence." From wolfgang.mueller at wiai.uni-bamberg.de Wed Jan 4 14:03:07 2006 From: wolfgang.mueller at wiai.uni-bamberg.de (Wolfgang =?iso-8859-1?q?M=FCller?=) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Actual availability of P2P systems Message-ID: <200601041503.07976.wolfgang.mueller@wiai.uni-bamberg.de> Hi all, I am aware of literature evaluating online times of single peers in structured/unstructured networks. However, I do not recall to have come across a paper that investigates the availability of the whole network in large fielded applications. I think it is improbable that there are no measurement studies answering my question, and I would be interested in any pointers I can get. My main question is: How often does it happen in existing P2P netowrks that significant parts of the network are really unreachable? How high is the percentage of requests that fail (in the sense that they return a faulty result) in existing fielded DHT applications? Looking forward to your replies, Cheers, Wolfgang -- Dr. Wolfgang M?ller LS Medieninformatik Universit?t Bamberg Check out the SIG MM web site http://www.sigmm.org From wolfgang.mueller at wiai.uni-bamberg.de Wed Jan 4 14:30:13 2006 From: wolfgang.mueller at wiai.uni-bamberg.de (Wolfgang =?iso-8859-1?q?M=FCller?=) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Napster Screenshots? Message-ID: <200601041530.13523.wolfgang.mueller@wiai.uni-bamberg.de> Hi, For a report, I would like to have a screenshot of an early Napster version. Unfortunately I don't have any. Does any of you guys/girls have something like that? I would be very thankful if you would get in contact with me. Cheers, Wolfgang -- Dr. Wolfgang M?ller LS Medieninformatik Universit?t Bamberg Check out the SIG MM web site http://www.sigmm.org From reinout at cs.vu.nl Wed Jan 4 14:41:19 2006 From: reinout at cs.vu.nl (Reinout van Schouwen) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Napster Screenshots? In-Reply-To: <200601041530.13523.wolfgang.mueller@wiai.uni-bamberg.de> References: <200601041530.13523.wolfgang.mueller@wiai.uni-bamberg.de> Message-ID: On Wed, 4 Jan 2006, Wolfgang M?ller wrote: > For a report, I would like to have a screenshot of an early Napster > version. Unfortunately I don't have any. Does any of you guys/girls > have something like that? I would be very thankful if you would get in > contact with me. I'll bet Google Images has something for you? regards, -- Reinout van Schouwen *** student of Artifical Intelligence email: reinout@cs.vu.nl *** mobile phone: +31-6-44360778 www.vanschouwen.info *** help mee met GNOME vertalen: nl.gnome.org From emmert at ftw.at Wed Jan 4 14:45:46 2006 From: emmert at ftw.at (Barbara Emmert) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Actual availability of P2P systems In-Reply-To: <200601041503.07976.wolfgang.mueller@wiai.uni-bamberg.de> Message-ID: <43BBEDAA.13695.1377AAE@emmert.ftw.at> Hi Wolfgang, a theoretical examination of the stability of a Chord ring is done in "On the Stability of Chord-based P2P Systems", by Andreas Binzenh?fer, Dirk Staehle, and Robert Henjes and was presented at GLOBECOM 2005 in St. Louis. The authors analyze the probabilities for a disconnection of the peers in the ring and investigate the corresponding scalability with stochastic methods. If you're interested in the paper, you can download it via http://www-info3.informatik.uni-wuerzburg.de/staff/binzenhoefer/ Have a nice day Barbara -- Dipl.-Inform. Barbara Emmert Forschungszentrum Telekommunikation Wien - www.ftw.at Tel: +43-1-5052830-45 From mathieu.harel at laposte.net Wed Jan 4 14:46:45 2006 From: mathieu.harel at laposte.net (mathieu.harel) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Napster Screenshots? Message-ID: Hi, You can find two screenshots of the v2.0 Beta 9 at http://www.kefk.net/P2P/Website/Inhalt/index.asp (middle of the page) Regards, Mathieu > Hi, > > For a report, I would like to have a screenshot of an early Napster version. > Unfortunately I don't have any. Does any of you guys/girls have something > like that? I would be very thankful if you would get in contact with me. > > Cheers, > Wolfgang > > -- > Dr. Wolfgang M???ller > LS Medieninformatik > Universit???t Bamberg > Check out the SIG MM web site http://www.sigmm.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 > Acc?dez au courrier ?lectronique de La Poste : www.laposte.net ; Jusqu'au 25 d?cembre, participez au grand jeu du Calendrier de l'Avent et ?gagnez tous les jours de nombreux lots, + de 300 cadeaux en jeu ! From agthorr at cs.uoregon.edu Wed Jan 4 23:16:20 2006 From: agthorr at cs.uoregon.edu (Daniel Stutzbach) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Actual availability of P2P systems In-Reply-To: <200601041503.07976.wolfgang.mueller@wiai.uni-bamberg.de> References: <200601041503.07976.wolfgang.mueller@wiai.uni-bamberg.de> Message-ID: <20060104231619.GC2464@cs.uoregon.edu> On Wed, Jan 04, 2006 at 03:03:07PM +0100, Wolfgang M?ller wrote: > How often does it happen in existing P2P netowrks that significant parts of > the network are really unreachable? One could argue that unreachable peers are not actually part of the network, and therefore this happens 0% of the time. ;-) I know what you mean, though: how often are a significant fraction of peers which are running the P2P software unreachable from the largest connected component? I'm not aware of any measurement studies on this topic (perhaps partly because it's difficult to measure). Are you thinking of DHT applications or "unstructured" P2P systems such as Gnutella? In the later case, significant fragmentation is very unlikely due to the high out-degree of most peers. > How high is the percentage of requests that fail (in the sense that they > return a faulty result) in existing fielded DHT applications? I do not think this question (as stated) is sufficiently well-defined. What would you consider a faulty result, and (for the purposes of designing a measurement study) how would you can you tell if a result is faulty? Which fielded DHT applications are you thinking of? -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon From dbarrett at quinthar.com Thu Jan 5 00:10:09 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] New project: P2P VPN, sort of... In-Reply-To: <000701c60fc3$2079cb50$6e1f0e05@bigclit> References: <000701c60fc3$2079cb50$6e1f0e05@bigclit> Message-ID: <43BC63E1.1000203@quinthar.com> Sounds like a fantastic project. Just curious, how difficult was it to get the TUN driver up and running? Also, have you thought of abstracting out the P2P/DHT component away from the TUN component, such that someone could use the former without the latter? It seems the P2P/DHT part could be kept platform independent, while the TUN part couldn't. It'd be great to have a drop-in P2P/DHT layer, without needing to install a TUN driver (or without depending on Unix). -david Luca Piccarreta wrote: > Hi all, > my name is Luca Piccarreta, I've implemented a sort of P2P application > (based on a KAD network) > with an embedded VPN (well.... not yet private :) based on a TUN > driver, and a ridiculous name server which map DNS requests to > Kad queries. > In the end, the application should be a big firewall opener, on top > of which it should be easy to build P2P applications, or to connect to > computers behind NAT/firewalls. > Of course, all the code has been written in a hurry, but I think that with > the help of someone it could become a very nice application. > If you want an idea of what it should become, have at look at Hamachi > (http://www.hamachi.cc), and add on top of that the ability to refer to > peers with friendly name (say http://name_of_an_host.kad) > > What's there: > - KAD network (own flavour, not compatible with Emule or whatever) > - TUN interface and forwarding (got from OpenVPN TAP-WIN32 driver > and bits and pieces of code) > - Nameservice (trivial, but working) > - Linux/WIN32 > - C++ > > What's not there: > - Message signing/encryption > - A nice GUI > - Some users... > - A home page > > The project is at sourceforge (http://sourceforge.net/projects/x-kad) > > Eagerly waiting for volunteers! > Luca. > > _______________________________________________ > 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 lemonobrien at yahoo.com Thu Jan 5 04:14:00 2006 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Actual availability of P2P systems In-Reply-To: <20060104231619.GC2464@cs.uoregon.edu> Message-ID: <20060105041400.52965.qmail@web53607.mail.yahoo.com> sepending on how many are behind firewalls compared to those that are not. Daniel Stutzbach wrote: On Wed, Jan 04, 2006 at 03:03:07PM +0100, Wolfgang M?ller wrote: > How often does it happen in existing P2P netowrks that significant parts of > the network are really unreachable? One could argue that unreachable peers are not actually part of the network, and therefore this happens 0% of the time. ;-) I know what you mean, though: how often are a significant fraction of peers which are running the P2P software unreachable from the largest connected component? I'm not aware of any measurement studies on this topic (perhaps partly because it's difficult to measure). Are you thinking of DHT applications or "unstructured" P2P systems such as Gnutella? In the later case, significant fragmentation is very unlikely due to the high out-degree of most peers. > How high is the percentage of requests that fail (in the sense that they > return a faulty result) in existing fielded DHT applications? I do not think this question (as stated) is sufficiently well-defined. What would you consider a faulty result, and (for the purposes of designing a measurement study) how would you can you tell if a result is faulty? Which fielded DHT applications are you thinking of? -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon _______________________________________________ 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 You don't get no juice unless you squeeze Lemon Obrien, the Third. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060104/6576b47c/attachment.htm From wangyong at software.ict.ac.cn Thu Jan 5 04:25:21 2006 From: wangyong at software.ict.ac.cn (=?gb2312?B?zfXTwg==?=) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] about leaves Message-ID: <20060105042512.875363FC2B@capsicum.zgp.org> aGksRGFuaWVsIFN0dXR6YmFjaA0KCUkgbWVhc3VyZWQgdGhlIGdudXRlbGxhIG5ldHdvcmsgcmVj ZW50bHksIEkgZmluZCB0aGF0IHNvbWUgbGVhdmVzIGhhdmUgbGFyZ2UgZGVncmVlIG1vcmUgdGhh biAxMDAwLCBhY2NvcmRpbmcgdGhlIHJmYyBvZiBnbnV0ZWxsYSwgd2hpY2ggc2F5cyB0aGF0IG9u ZSBsZWFmIG5lZWQgb25seSBjb25uZWN0IHRvIDIgb3IgNCB1bHRyYSBwZWVycywgc28gSSB3b25k ZXIgd2hhdCBraW5kcyBvZiBwZWVyIHRoYXQgaGF2ZSBzdWNoIGEgbGFyZ2UgbnVtYmVyIG9mIHVs dHJhLXBlZXIgcGFyZW50cz8gYXJlIHRoZXkgcmVhbGx5IGV4aXN0aW5nIG9yIGp1c3QgY29tZSB0 ZXN0aW5nIG5vZGVzPw0KDQoJDQoNCj09PT09PT0gMjAwNi0wMS0wNSAwNzoxNjoyMCA9PT09PT09 DQoNCj5PbiBXZWQsIEphbiAwNCwgMjAwNiBhdCAwMzowMzowN1BNICswMTAwLCBXb2xmZ2FuZyBN P2xsZXIgd3JvdGU6DQo+PiBIb3cgb2Z0ZW4gZG9lcyBpdCBoYXBwZW4gaW4gZXhpc3RpbmcgUDJQ IG5ldG93cmtzIHRoYXQgc2lnbmlmaWNhbnQgcGFydHMgb2YgDQo+PiB0aGUgbmV0d29yayBhcmUg cmVhbGx5IHVucmVhY2hhYmxlPw0KPg0KPk9uZSBjb3VsZCBhcmd1ZSB0aGF0IHVucmVhY2hhYmxl IHBlZXJzIGFyZSBub3QgYWN0dWFsbHkgcGFydCBvZiB0aGUNCj5uZXR3b3JrLCBhbmQgdGhlcmVm b3JlIHRoaXMgaGFwcGVucyAwJSBvZiB0aGUgdGltZS4gOy0pDQo+DQo+SSBrbm93IHdoYXQgeW91 IG1lYW4sIHRob3VnaDogaG93IG9mdGVuIGFyZSBhIHNpZ25pZmljYW50IGZyYWN0aW9uIG9mDQo+ cGVlcnMgd2hpY2ggYXJlIHJ1bm5pbmcgdGhlIFAyUCBzb2Z0d2FyZSB1bnJlYWNoYWJsZSBmcm9t IHRoZSBsYXJnZXN0DQo+Y29ubmVjdGVkIGNvbXBvbmVudD8NCj4NCj5JJ20gbm90IGF3YXJlIG9m IGFueSBtZWFzdXJlbWVudCBzdHVkaWVzIG9uIHRoaXMgdG9waWMgKHBlcmhhcHMgcGFydGx5DQo+ YmVjYXVzZSBpdCdzIGRpZmZpY3VsdCB0byBtZWFzdXJlKS4gIEFyZSB5b3UgdGhpbmtpbmcgb2Yg REhUDQo+YXBwbGljYXRpb25zIG9yICJ1bnN0cnVjdHVyZWQiIFAyUCBzeXN0ZW1zIHN1Y2ggYXMg R251dGVsbGE/ICBJbiB0aGUNCj5sYXRlciBjYXNlLCBzaWduaWZpY2FudCBmcmFnbWVudGF0aW9u IGlzIHZlcnkgdW5saWtlbHkgZHVlIHRvIHRoZSBoaWdoDQo+b3V0LWRlZ3JlZSBvZiBtb3N0IHBl ZXJzLg0KPg0KPj4gSG93IGhpZ2ggaXMgdGhlIHBlcmNlbnRhZ2Ugb2YgcmVxdWVzdHMgdGhhdCBm YWlsIChpbiB0aGUgc2Vuc2UgdGhhdCB0aGV5IA0KPj4gcmV0dXJuIGEgZmF1bHR5IHJlc3VsdCkg aW4gZXhpc3RpbmcgZmllbGRlZCBESFQgYXBwbGljYXRpb25zPw0KPg0KPkkgZG8gbm90IHRoaW5r IHRoaXMgcXVlc3Rpb24gKGFzIHN0YXRlZCkgaXMgc3VmZmljaWVudGx5DQo+d2VsbC1kZWZpbmVk LiAgV2hhdCB3b3VsZCB5b3UgY29uc2lkZXIgYSBmYXVsdHkgcmVzdWx0LCBhbmQgKGZvciB0aGUN Cj5wdXJwb3NlcyBvZiBkZXNpZ25pbmcgYSBtZWFzdXJlbWVudCBzdHVkeSkgaG93IHdvdWxkIHlv dSBjYW4geW91IHRlbGwNCj5pZiBhIHJlc3VsdCBpcyBmYXVsdHk/DQo+DQo+V2hpY2ggZmllbGRl ZCBESFQgYXBwbGljYXRpb25zIGFyZSB5b3UgdGhpbmtpbmcgb2Y/DQo+DQo+LS0gDQo+RGFuaWVs IFN0dXR6YmFjaCAgICAgICAgICAgICAgICAgICAgICAgICAgIENvbXB1dGVyIFNjaWVuY2UgUGgu RCBTdHVkZW50DQo+aHR0cDovL3d3dy5iYXJzb29tLm9yZy9+YWd0aG9yciAgICAgICAgICAgICAg ICAgICAgIFVuaXZlcnNpdHkgb2YgT3JlZ29uDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5wMnAtaGFja2VycyBtYWlsaW5nIGxpc3QNCj5wMnAtaGFj a2Vyc0B6Z3Aub3JnDQo+aHR0cDovL3pncC5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnAtaGFja2Vy cw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+SGVy ZSBpcyBhIHdlYiBwYWdlIGxpc3RpbmcgUDJQIENvbmZlcmVuY2VzOg0KPmh0dHA6Ly93d3cubmV1 cm9ncmlkLm5ldC90d2lraS9iaW4vdmlldy9NYWluL1BlZXJUb1BlZXJDb25mZXJlbmNlcw0KPg0K DQo9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0NCgkJCQ0KDQqhoaGhoaGh oaGhoaGhoaGh1sINCsDxo6ENCiANCgkJCQkgDQqhoaGhoaGhoaGhoaGhoaGhzfXTwg0KoaGhoaGh oaGhoaGhoaGhoXdhbmd5b25nQHNvZnR3YXJlLmljdC5hYy5jbg0KoaGhoaGhoaGhoaGhoaGhoaGh oaEyMDA2LTAxLTA1DQoNCg== From wolfgang.mueller at wiai.uni-bamberg.de Thu Jan 5 12:32:06 2006 From: wolfgang.mueller at wiai.uni-bamberg.de (Wolfgang =?iso-8859-1?q?M=FCller?=) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Actual availability of P2P systems In-Reply-To: <20060104231619.GC2464@cs.uoregon.edu> References: <200601041503.07976.wolfgang.mueller@wiai.uni-bamberg.de> <20060104231619.GC2464@cs.uoregon.edu> Message-ID: <200601051332.06678.wolfgang.mueller@wiai.uni-bamberg.de> Hi, Daniel, > One could argue that unreachable peers are not actually part of the > network, and therefore this happens 0% of the time. ;-) Yes, and Gnutella is best, when you share just with yourself. You do not even need a network, then :-D . > I know what you mean, though: how often are a significant fraction of > peers which are running the P2P software unreachable from the largest > connected component? Thanks for improving the precision of my request. Let me go one step further. I think it is rather How many times there is a significant set of peers D such that for all d\in D the following conditions hold: - d was connected (in the sense of successful initial introduction) to the largest connected component (LCC) within the time interval \delta_t - d now *is* disconnected from the LCC - d's user did not launch any leave operation to disconnect d from the LCC - d's is connected to the internet, i.e. knowing the IP address of current members of the LCC, it could connect to the LCC. d has been connected to the internet in this sense all through \delta_t Suggestions for improvement welcome. > I'm not aware of any measurement studies on this topic (perhaps partly > because it's difficult to measure). I guess so, yes, but before I say there is none, I would prefer to know. This is why I ask. > Are you thinking of DHT > applications or "unstructured" P2P systems such as Gnutella? In the > later case, significant fragmentation is very unlikely due to the high > out-degree of most peers. Both. > > How high is the percentage of requests that fail (in the sense that they > > return a faulty result) in existing fielded DHT applications? > I do not think this question (as stated) is sufficiently > well-defined. Parts of the lack of definition is due to my wish to improve recall ;-) . I would prefer to receive some suggestions that do not fit rather than discourage suggestions that would have fit. > What would you consider a faulty result, and (for the > purposes of designing a measurement study) how would you can you tell > if a result is faulty? I would consider a faulty result the event that a key/value pair that has been inserted within the last \delta_t is not reported to be present by a retrieval request. How I could tell? By being the inserter myself. If you want a larger basis (i.e. not just one petty peer in the network as a probe) you can consider using PlanetLab if this is consistent with PlanetLab's rules. > Which fielded DHT applications are you thinking of? Overnet or some others I am not aware of. Cheers, and thanks for your thoughts, Wolfgang -- Dr. Wolfgang M?ller LS Medieninformatik Universit?t Bamberg Check out the SIG MM web site http://www.sigmm.org From bryan.turner at pobox.com Thu Jan 5 16:42:08 2006 From: bryan.turner at pobox.com (Bryan Turner) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] about leaves In-Reply-To: <20060105042512.875363FC2B@capsicum.zgp.org> Message-ID: <200601051642.k05Gg86H019431@rtp-core-2.cisco.com> Hello, In [1], the last paragraph of section 4.1 on page 7, they mention similar odd behavior (highly connected leaves, non-responsive, and don't forward queries). Their footnote suggests that these nodes may be related to the RIAA lawsuits, or some marketing campaign to watch consumer behavior. --Bryan bryan.turner@pobox.com [1] http://www.cs.uoregon.edu/~reza/PUB/imc05.pdf -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of ?? Sent: Wednesday, January 04, 2006 11:25 PM To: Peer-to-peer development. Subject: [p2p-hackers] about leaves hi,Daniel Stutzbach I measured the gnutella network recently, I find that some leaves have large degree more than 1000, according the rfc of gnutella, which says that one leaf need only connect to 2 or 4 ultra peers, so I wonder what kinds of peer that have such a large number of ultra-peer parents? are they really existing or just come testing nodes? From Serguei.Osokine at efi.com Thu Jan 5 19:02:01 2006 From: Serguei.Osokine at efi.com (Serguei Osokine) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] about leaves Message-ID: <4A60C83D027E224BAA4550FB1A2B120EC427E1@fcexmb04.efi.internal> On Thursday, January 05, 2006 Bryan Turner wrote: > Their footnote suggests that these nodes may be related to the > RIAA lawsuits, or some marketing campaign to watch consumer > behavior. Yep. If you want to watch the whole network, that's exactly how you do it. Incidentally, connecting to lots of Ultrapeers will also do wonders for your query reach, but then you'll need a lot of Ultrapeers to hold all the leaves that will connect to multiple Ultrapeers: http://www.grouter.net/gnutella/search.htm#OptimalRedundancyLevel Best wishes - S.Osokine. 5 Jan 2006. -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On Behalf Of Bryan Turner Sent: Thursday, January 05, 2006 8:42 AM To: 'Peer-to-peer development.' Subject: RE: [p2p-hackers] about leaves Hello, In [1], the last paragraph of section 4.1 on page 7, they mention similar odd behavior (highly connected leaves, non-responsive, and don't forward queries). Their footnote suggests that these nodes may be related to the RIAA lawsuits, or some marketing campaign to watch consumer behavior. --Bryan bryan.turner@pobox.com [1] http://www.cs.uoregon.edu/~reza/PUB/imc05.pdf -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of ?? Sent: Wednesday, January 04, 2006 11:25 PM To: Peer-to-peer development. Subject: [p2p-hackers] about leaves hi,Daniel Stutzbach I measured the gnutella network recently, I find that some leaves have large degree more than 1000, according the rfc of gnutella, which says that one leaf need only connect to 2 or 4 ultra peers, so I wonder what kinds of peer that have such a large number of ultra-peer parents? are they really existing or just come testing nodes? _______________________________________________ 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 coderman at gmail.com Thu Jan 5 20:16:35 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] about leaves In-Reply-To: <4A60C83D027E224BAA4550FB1A2B120EC427E1@fcexmb04.efi.internal> References: <4A60C83D027E224BAA4550FB1A2B120EC427E1@fcexmb04.efi.internal> Message-ID: <4ef5fec60601051216o513fafa9m62246afcd603660f@mail.gmail.com> On 1/5/06, Serguei Osokine wrote: > > Yep. If you want to watch the whole network, that's exactly how > you do it. i too used this approach when monitoring queries on gnutella years ago. it works nicely although some recent clients will detect such behavior and disconnect you after a period of time. From wangyong at software.ict.ac.cn Fri Jan 6 00:57:30 2006 From: wangyong at software.ict.ac.cn (=?gb2312?B?zfXTwg==?=) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] about leaves Message-ID: <20060106005719.ACD7A3FC21@capsicum.zgp.org> aGksY29kZXJtYW4NCgl0aGVuLCBJIHdvbmRlciBob3cgdGhlc2UgbGFyZ2UtZGVncmVlIGxlYXZl cyBhZmZlY3QgdGhlIHdoaWxlIGdudXRlbGxhIG5ldHdvcmsgYmVoYXZpb3I/IGNhbiB0aGV5IG1h a2UgdGhlIG92ZXJsYXkgbmV0d29yayBtb3JlIHN0cm9uZ2VyPyBvciwgdGhleSBoYXZlIG5vdGhp bmcgdG8gZG8gd2l0aCB0aGUgYXJjaGl0ZWN0dXJlIG9mIGdudXRlbGxhPw0KCXBzOiB0aGFua3Mg YSBsb3QgZm9yIHJlc3BvbnNlLg0KDQoJDQoNCj09PT09PT0gMjAwNi0wMS0wNiAwNDoxNjozNSDE +tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KDQo+T24gMS81LzA2LCBTZXJndWVpIE9zb2tpbmUgPFNl cmd1ZWkuT3Nva2luZUBlZmkuY29tPiB3cm90ZToNCj4+DQo+PiAgICAgICAgIFllcC4gSWYgeW91 IHdhbnQgdG8gd2F0Y2ggdGhlIHdob2xlIG5ldHdvcmssIHRoYXQncyBleGFjdGx5IGhvdw0KPj4g eW91IGRvIGl0Lg0KPg0KPmkgdG9vIHVzZWQgdGhpcyBhcHByb2FjaCB3aGVuIG1vbml0b3Jpbmcg cXVlcmllcyBvbiBnbnV0ZWxsYSB5ZWFycw0KPmFnby4gIGl0IHdvcmtzIG5pY2VseSBhbHRob3Vn aCBzb21lIHJlY2VudCBjbGllbnRzIHdpbGwgZGV0ZWN0IHN1Y2gNCj5iZWhhdmlvciBhbmQgZGlz Y29ubmVjdCB5b3UgYWZ0ZXIgYSBwZXJpb2Qgb2YgdGltZS4NCj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnAycC1oYWNrZXJzIG1haWxpbmcgbGlzdA0K PnAycC1oYWNrZXJzQHpncC5vcmcNCj5odHRwOi8vemdwLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Ay cC1oYWNrZXJzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5IZXJlIGlzIGEgd2ViIHBhZ2UgbGlzdGluZyBQMlAgQ29uZmVyZW5jZXM6DQo+aHR0cDov L3d3dy5uZXVyb2dyaWQubmV0L3R3aWtpL2Jpbi92aWV3L01haW4vUGVlclRvUGVlckNvbmZlcmVu Y2VzDQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQoNCqGh oaGhoaGhoaGhoaGhoaHWwg0KwPGjoQ0KIA0KCQkJCSANCqGhoaGhoaGhoaGhoaGhoaHN9dPCDQqh oaGhoaGhoaGhoaGhoaGhd2FuZ3lvbmdAc29mdHdhcmUuaWN0LmFjLmNuDQqhoaGhoaGhoaGhoaGh oaGhoaGhoTIwMDYtMDEtMDYNCg0K From coderman at gmail.com Fri Jan 6 02:59:32 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] about leaves In-Reply-To: <20060106005719.ACD7A3FC21@capsicum.zgp.org> References: <20060106005719.ACD7A3FC21@capsicum.zgp.org> Message-ID: <4ef5fec60601051859hda3b80dh5f24161dd6b906d6@mail.gmail.com> T24gMS81LzA2LCDN9dPCIDx3YW5neW9uZ0Bzb2Z0d2FyZS5pY3QuYWMuY24+IHdyb3RlOgo+IGhp LGNvZGVybWFuCj4gICAgICAgICB0aGVuLCBJIHdvbmRlciBob3cgdGhlc2UgbGFyZ2UtZGVncmVl IGxlYXZlcyBhZmZlY3QgdGhlIHdoaWxlIGdudXRlbGxhIG5ldHdvcmsgYmVoYXZpb3I/IGNhbiB0 aGV5IG1ha2UgdGhlIG92ZXJsYXkgbmV0d29yayBtb3JlIHN0cm9uZ2VyPyBvciwgdGhleSBoYXZl IG5vdGhpbmcgdG8gZG8gd2l0aCB0aGUgYXJjaGl0ZWN0dXJlIG9mIGdudXRlbGxhPwoKbXkgcXVl cnkgbG9nZ2luZyBub2RlcyBkaWQgbm90IGZvcndhcmQgLyBvdXRwdXQgZ251dGVsbGEgcXVlcmll cywgb25seQpsb2dnZWQgaW5jb21pbmcgc2VhcmNoIHN0cmluZ3MuICBpIHdvdWxkIGJldCB0aGF0 IG1vc3Qgb2YgdGhlc2UgaGlnaApkZWdyZWUgbm9kZXMgZG8gbm90IHBhcnRpY2lwYXRlIGFjdGl2 ZWx5IGluIHRoZSBuZXR3b3JrIGFuZCB0aHVzIGhhdmUKbGl0dGxlIG9yIG5vdGhpbmcgdG8gZG8g d2l0aCBhcmNoaXRlY3R1cmFsIGNvbnNpZGVyYXRpb25zIG9mIHRoZQpuZXR3b3JrLiAoYXNpZGUg ZnJvbSB0aGUgdHJhZmZpYyB0aGV5IGNvbnN1bWUgbGlzdGVuaW5nIHRvIGFsbCBvZgp0aGVpciBw ZWVycykK From adanar at ics.forth.gr Mon Jan 9 12:05:12 2006 From: adanar at ics.forth.gr (Haris Papadakis) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Refresh cost in structured networks In-Reply-To: <200601051642.k05Gg86H019431@rtp-core-2.cisco.com> References: <200601051642.k05Gg86H019431@rtp-core-2.cisco.com> Message-ID: Hello all, I was wondering, is anyone of you aware of any work that tries to measure the cost of periocally publishing each content in the network, as is usually done in structured p2p systems? Perhaps even compare this cost to flooding in unstructured networks? I have been trying to find something related to this, but haven't come up with something that looks into that particular issue. Charis From agthorr at cs.uoregon.edu Mon Jan 9 18:39:56 2006 From: agthorr at cs.uoregon.edu (Daniel Stutzbach) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Actual availability of P2P systems In-Reply-To: <200601051332.06678.wolfgang.mueller@wiai.uni-bamberg.de> References: <200601041503.07976.wolfgang.mueller@wiai.uni-bamberg.de> <20060104231619.GC2464@cs.uoregon.edu> <200601051332.06678.wolfgang.mueller@wiai.uni-bamberg.de> Message-ID: <20060109183955.GC2936@cs.uoregon.edu> On Thu, Jan 05, 2006 at 01:32:06PM +0100, Wolfgang M?ller wrote: > I would consider a faulty result the event that a key/value pair > that has been inserted within the last \delta_t is not reported to > be present by a retrieval request. > > How I could tell? By being the inserter myself. If you want a larger basis > (i.e. not just one petty peer in the network as a probe) you can consider > using PlanetLab if this is consistent with PlanetLab's rules. I present some measurements like this based on eMule's Kad network in a paper I'll be presenting at INFOCOM 2006, in Section VI: http://www.barsoom.org/~agthorr/papers/infocom-2006-kad.pdf -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon From shudo at computer.org Mon Jan 16 15:21:10 2006 From: shudo at computer.org (shudo@computer.org) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Overlay Weaver: An Overlay Construction Toolkit Message-ID: <20060117.002110.424245970.shudo@aist.go.jp> I'm pleased to announce the initial release of Overlay Weaver. Overlay Weaver: An Overlay Construction Toolkit http://overlayweaver.sf.net/ It supports overlay algorithm designers in addition to application developers. For application developers, the toolkit provides a common API for higher-level services such as distributed hashtable (DHT) and multicast. Applications relying on the common API depend no specific transport protocol, database implementation and routing algorithm. The toolkit provides multiple routing algorithms, Chord, Kademlia, Pastry and Tapestry. These algorithms could be implemented only in hundreds lines of code because of routing layer decomposition. Routing layer under the higher-level services has been decomposed into multiple components, routing driver, routing algorithm and messaging service. The decomposition also facilitates implementation of a new algorithm. A newly implemented algorithm can be tested, evaluated and compared on emulator, which can host thousands of virtual nodes It enables large-scale emulation and fair comparison between algorithms. Features: - Implemented in Java 5. (except part of IPv4 multicast router which is in C.) - Provides multiple routing algorithms, Chord, Kademlia, Pastry and Tapestry. - Two routing drivers respectively performing iterative and recursive routing work with all routing algorithm (except recursive routing with Kademlia). - Provides a distributed environment emulator. It has demonstrated that it can host 4000 (virtual) nodes on a single 32 bit computer with 1 GB memory. - There are multiple implementations of communication layer, with UDP, TCP and emulated messaging layer. Note that the UDP implementation does UDP hole punching. - A visualization tool, Messaging Visualizer provided. It shows nodes and communications just in time and works both on the emulator and a real network. There are screenshots and a demonstration provided on the web site. Please take a look. We have written a paper but now it's in Japanese. I will prepare an English paper in few months. We'd appreciate activities utilizing this toolkit such as application development, algorithm researches, testbed construction and operation. We'll support them. Please contact us or subscribe a mailing list. Thanks, Kazuyuki Shudo, Ph.D. shudo@ni.aist.go.jp, http://www.shudo.net/ Grid Technology Research Center National Institute of Advanced Industrial Science and Technology (AIST) From mottee at gmail.com Mon Jan 16 23:57:34 2006 From: mottee at gmail.com (Priyanka Sinha) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal Message-ID: Hi hmm .. was reading the UIP document, and was wondering whether self certifying identities may well be replaced by normal MAC ids .. or perhaps in the light of security some kind of trusted MAC ids.. am kinda new at thinking abt this stuff.. so would appreciate any comments on this :) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060116/74cdca43/attachment.html From alenlpeacock at gmail.com Tue Jan 17 03:38:44 2006 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] unhappy realization: Kademlia doesn't self-heal In-Reply-To: References: Message-ID: On 1/16/06, Priyanka Sinha wrote: > > Hi > hmm .. was reading the UIP document, and was wondering whether self > certifying identities may well be replaced by normal MAC ids .. or perhaps > in the light of security some kind of trusted MAC ids.. > am kinda new at thinking abt this stuff.. so would appreciate any comments > on this > :) > In large part, the answer depends on what you mean by MAC ID. If you are talking about the internet at large, you are talking about Ethernet MAC addresses, no? These addresses are 100% configurable for most ethernet cards, and thus 100% spoofable. So they'd only be useful if you assume that no malicious nodes will participate in the network (which is, I think you'd agree, a naive assumption)[*1], and only if you don't want to tie any useful information to the ID (such as trust or reputation metrics). Of course if you are talking about wireless LANs, it's a different ballgame. The 802.11 family utilizes the MAC layer precisely to do things like authentication. But even here, the schemes are likely less useful than self-certifying identities. For example, most schemes rely on a shared secret for authentication (WEP keys), and shared secrets certainly don't scale to the scope of most p2p applications. Alen [*1] - the nodes don't even need to be malicious -- when I was in college, the IT department bought some cheap consumer-grade NICs in bulk to distribute to on-campus housing. It turns out that the manufacturer, for whatever reason, shipped hundreds of these NICs with the same MAC address, wreaking general havoc on the initial network deployment. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060116/02688ee5/attachment.htm From rabbi at abditum.com Sat Jan 21 19:53:46 2006 From: rabbi at abditum.com (Len Sassaman) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] CodeCon program announced, early registration deadline nearing Message-ID: The program for CodeCon 2006 has been announced. http://www.codecon.org/2006/program.html CodeCon is the premier showcase of innovative software projects. It is a workshop for developers of real-world applications with working code and active development projects. All presentations will given by one of the lead developers, and accompanied by a functional demo. Highlights of CodeCon 2006 include: iGlance - Open source push-to-talk videoconferencing and screen-sharing Monotone - Low stress, high functionality version control Query By Example - Data mining operations within PostgreSQL Djinni - Efficient approximations to NP-complete problems Elsa/Oink/Cqual++ - A static-time whole-program dataflow analysis for C and C++ Truman - An open-source behavioral malware analysis sandnet VidTorrent/Peers - A scalable real-time p2p streaming protocol The fifth annual CodeCon takes place February 10 - 12, 11:30 - 18:00, at StudioZ (314 11th Street) in San Francisco. Early registration is $63, available online until February 1st, 2006. Registration will be available at the door for $85. Supporting Attendee tickets are also available, and include a one-year membership to the USENIX Association. Please see the CodeCon registration page for details: http://www.codecon.org/2006/registration.html From dbarrett at quinthar.com Sun Jan 22 10:24:57 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] CodeCon program announced, early registration deadline nearing In-Reply-To: Message-ID: <20060122102508.F09563FCA9@capsicum.zgp.org> Hi all, as you might have seen in the announcement I've been honored with the pleasure of presenting iGlance at CodeCon. Anyone who is in town is invited to attend, especially because it was your advice that helped make iGlance happen. See you there! -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Len Sassaman > Sent: Saturday, January 21, 2006 11:54 AM > To: p2p-hackers@zgp.org > Subject: [p2p-hackers] CodeCon program announced,early registration > deadline nearing > > The program for CodeCon 2006 has been announced. > > http://www.codecon.org/2006/program.html > > CodeCon is the premier showcase of innovative software projects. It is a > workshop for developers of real-world applications with working code and > active development projects. All presentations will given by one of the > lead developers, and accompanied by a functional demo. > > > Highlights of CodeCon 2006 include: > > iGlance - Open source push-to-talk videoconferencing and > screen-sharing > Monotone - Low stress, high functionality version control > Query By Example - Data mining operations within PostgreSQL > Djinni - Efficient approximations to NP-complete problems > Elsa/Oink/Cqual++ - A static-time whole-program dataflow analysis for C > and C++ > Truman - An open-source behavioral malware analysis sandnet > VidTorrent/Peers - A scalable real-time p2p streaming protocol > > > The fifth annual CodeCon takes place February 10 - 12, 11:30 - 18:00, at > StudioZ (314 11th Street) in San Francisco. Early registration is $63, > available online until February 1st, 2006. > > Registration will be available at the door for $85. > > Supporting Attendee tickets are also available, and include a one-year > membership to the USENIX Association. Please see the CodeCon registration > page for details: > > http://www.codecon.org/2006/registration.html > > _______________________________________________ > 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 threelions0916 at yahoo.com.cn Mon Jan 23 01:51:20 2006 From: threelions0916 at yahoo.com.cn (Michael Liu) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Overlay Weaver: An Overlay Construction Toolkit References: <20060117.002110.424245970.shudo@aist.go.jp> Message-ID: <001901c61fbf$8390d740$4918080a@cnc.intra> It seems a great toolkit , .I think Overlay Weaver will greatly speed the developing of p2p applications. I have one question, is Overlay Weaver similar to the Jxta ? or it's more powerful than Jxta ? thanks ----- Original Message ----- From: To: Sent: Monday, January 16, 2006 11:21 PM Subject: [p2p-hackers] Overlay Weaver: An Overlay Construction Toolkit > I'm pleased to announce the initial release of Overlay Weaver. > > Overlay Weaver: An Overlay Construction Toolkit > http://overlayweaver.sf.net/ > > It supports overlay algorithm designers in addition to application > developers. > > For application developers, the toolkit provides a common API for > higher-level services such as distributed hashtable (DHT) and > multicast. Applications relying on the common API depend no specific > transport protocol, database implementation and routing algorithm. > > The toolkit provides multiple routing algorithms, Chord, Kademlia, > Pastry and Tapestry. These algorithms could be implemented only in > hundreds lines of code because of routing layer decomposition. Routing > layer under the higher-level services has been decomposed into > multiple components, routing driver, routing algorithm and messaging > service. The decomposition also facilitates implementation of a new > algorithm. A newly implemented algorithm can be tested, evaluated and > compared on emulator, which can host thousands of virtual nodes It > enables large-scale emulation and fair comparison between algorithms. > > Features: > > - Implemented in Java 5. > (except part of IPv4 multicast router which is in C.) > > - Provides multiple routing algorithms, Chord, Kademlia, Pastry and Tapestry. > > - Two routing drivers respectively performing iterative and recursive routing > work with all routing algorithm (except recursive routing with Kademlia). > > - Provides a distributed environment emulator. It has demonstrated > that it can host 4000 (virtual) nodes on a single 32 bit computer > with 1 GB memory. > > - There are multiple implementations of communication layer, > with UDP, TCP and emulated messaging layer. > Note that the UDP implementation does UDP hole punching. > > - A visualization tool, Messaging Visualizer provided. > It shows nodes and communications just in time > and works both on the emulator and a real network. > > There are screenshots and a demonstration provided on the web site. > Please take a look. > > We have written a paper but now it's in Japanese. I will prepare an > English paper in few months. > > We'd appreciate activities utilizing this toolkit such as application > development, algorithm researches, testbed construction and operation. > We'll support them. Please contact us or subscribe a mailing list. > > Thanks, > > Kazuyuki Shudo, Ph.D. shudo@ni.aist.go.jp, http://www.shudo.net/ > Grid Technology Research Center > National Institute of Advanced Industrial Science and Technology (AIST) > > _______________________________________________ > 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 shudo at computer.org Mon Jan 23 02:49:12 2006 From: shudo at computer.org (shudo@computer.org) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Overlay Weaver: An Overlay Construction Toolkit In-Reply-To: <001901c61fbf$8390d740$4918080a@cnc.intra> References: <20060117.002110.424245970.shudo@aist.go.jp> <001901c61fbf$8390d740$4918080a@cnc.intra> Message-ID: <20060123.114912.336473409.shudo@aist.go.jp> Hi Michael, Thanks for your interest in Overlay Weaver. There are mailing lists provided. Please consider joining it (but I've not posted yet). > It seems a great toolkit , .I think Overlay Weaver will greatly speed the developing of p2p applications. > > I have one question, is Overlay Weaver similar to the Jxta ? or it's more powerful than Jxta ? JXTA is oriented to programming interface and protocol, and Overlay Weaver (OW) is more seeds-oriented. The seeds are overlay-related technologies. Structured overlays are more powerful than JXTA's discovery mechanism, I believe. JXTA does routed and fowarded messaging supported by relay peers to get over NA(P)T. OW currently provides only UDP hole punching, which works with lots of routers but not all ones. Advertisement is a common idea to constructs of JXTA, peer, peer group, pipe and so on. OW does not have such higher-level common ideas. There are 2 higher-level services, DHT and Group Manager, and they can work together in the same application and share a routing service. But they are independent services and do not share an unified idea like advertisement. I have been an enthusiast for JXTA for years and support its ideal, providing common protocol for P2P applications. But I've been also disappointed by a few points, especially ad-hoc-ness and scalability. As you may know, JXTA applications requires pre-deployed super peers (rendezvous and relay peers). A normal (edge) peer can turn into a super peer but we cannot rely on the transform mechanism when deploying an application. It is not very ad-hoc when deployed in a large-scale. JXTA's discovery mechanism called SRDI is DHT-like but less scalable in principle. There have been a strong requirement for JXTA J2SE to support multiple discovery mechanism and JXTA core members have asserted it's the case. But I have not been convinced. JXTA project set a scalability target in a paper in 2002, in which a super peer hosts about 1,000 normal (edge) peers and several hundreds of super peers coordinates. But early in 2004, I found that a super peer can host only about 2 dozens of normal peers in case of frequent messaging. I guess that very limited people have tested JXTA with dozens of computers. Thanks, > ----- Original Message ----- > From: > To: > Sent: Monday, January 16, 2006 11:21 PM > Subject: [p2p-hackers] Overlay Weaver: An Overlay Construction Toolkit > > > I'm pleased to announce the initial release of Overlay Weaver. > > > > Overlay Weaver: An Overlay Construction Toolkit > > http://overlayweaver.sf.net/ > > > > It supports overlay algorithm designers in addition to application > > developers. > > > > For application developers, the toolkit provides a common API for > > higher-level services such as distributed hashtable (DHT) and > > multicast. Applications relying on the common API depend no specific > > transport protocol, database implementation and routing algorithm. > > > > The toolkit provides multiple routing algorithms, Chord, Kademlia, > > Pastry and Tapestry. These algorithms could be implemented only in > > hundreds lines of code because of routing layer decomposition. Routing > > layer under the higher-level services has been decomposed into > > multiple components, routing driver, routing algorithm and messaging > > service. The decomposition also facilitates implementation of a new > > algorithm. A newly implemented algorithm can be tested, evaluated and > > compared on emulator, which can host thousands of virtual nodes It > > enables large-scale emulation and fair comparison between algorithms. > > > > Features: > > > > - Implemented in Java 5. > > (except part of IPv4 multicast router which is in C.) > > > > - Provides multiple routing algorithms, Chord, Kademlia, Pastry and Tapestry. > > > > - Two routing drivers respectively performing iterative and recursive routing > > work with all routing algorithm (except recursive routing with Kademlia). > > > > - Provides a distributed environment emulator. It has demonstrated > > that it can host 4000 (virtual) nodes on a single 32 bit computer > > with 1 GB memory. > > > > - There are multiple implementations of communication layer, > > with UDP, TCP and emulated messaging layer. > > Note that the UDP implementation does UDP hole punching. > > > > - A visualization tool, Messaging Visualizer provided. > > It shows nodes and communications just in time > > and works both on the emulator and a real network. > > > > There are screenshots and a demonstration provided on the web site. > > Please take a look. > > > > We have written a paper but now it's in Japanese. I will prepare an > > English paper in few months. > > > > We'd appreciate activities utilizing this toolkit such as application > > development, algorithm researches, testbed construction and operation. > > We'll support them. Please contact us or subscribe a mailing list. > > > > Thanks, Kazuyuki Shudo, Ph.D. shudo@ni.aist.go.jp, http://www.shudo.net/ Grid Technology Research Center National Institute of Advanced Industrial Science and Technology (AIST) From behnel_ml at gkec.informatik.tu-darmstadt.de Mon Jan 23 14:44:00 2006 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Overlay Weaver: An Overlay Construction Toolkit In-Reply-To: <20060117.002110.424245970.shudo@aist.go.jp> References: <20060117.002110.424245970.shudo@aist.go.jp> Message-ID: <43D4EBB0.8090809@gkec.informatik.tu-darmstadt.de> shudo@computer.org schrieb: > I'm pleased to announce the initial release of Overlay Weaver. > > Overlay Weaver: An Overlay Construction Toolkit > http://overlayweaver.sf.net/ > > It supports overlay algorithm designers in addition to application > developers. You might be interested in OverML and the SLOSL Overlay Workbench. http://www.dvs1.informatik.tu-darmstadt.de/research/OverML/ http://developer.berlios.de/projects/slow/ Stefan From philip_matthews at magma.ca Thu Jan 26 15:09:10 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? Message-ID: I am wondering if anyone is aware of work on NAT-friendly DHT algorithms? In other words, a DHT algorithm that works with the peers are located behind NATs. From what I have seen. most DHT algorithms assume that any peer is directly reachable from any other peer, which is not true when peers are located behind NATs. Both Chord and Kademlia, for example, seem to make this assumption. - Philip From p2p-hackers at squix.ch Thu Jan 26 15:49:38 2006 From: p2p-hackers at squix.ch (Dani Eichhorn) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: References: Message-ID: <8B3941F4-8B1A-46ED-884D-6FE7FBEFD664@squix.ch> Hi Philip I'm working on this topic for my diploma thesis. My first priority goal is to implement a NAT traversal library that works independently from any p2p routing algorithm. But I'm aware that a perfectly designed algorithm would be much more efficient than this workaround. I don't know, if you know about this library: http:// nutss.gforge.cis.cornell.edu/stunt.php which is an architecture that provides endpoint-to-endpoint TCP connections, yet using one or several central server(s). I'm trying to adapt it for distributed applications, like DHT based frameworks. If you already have a solution in mind, I'd be glad to discuss it with you.. Dani Am 26.01.2006 um 16:09 schrieb Philip Matthews: > I am wondering if anyone is aware of work on NAT-friendly DHT > algorithms? > In other words, a DHT algorithm that works with the peers are > located behind NATs. > > From what I have seen. most DHT algorithms assume that any peer is > directly reachable > from any other peer, which is not true when peers are located > behind NATs. > Both Chord and Kademlia, for example, seem to make this assumption. > > - Philip > _______________________________________________ > 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 piccarre at elet.polimi.it Thu Jan 26 15:59:40 2006 From: piccarre at elet.polimi.it (Luca Piccarreta) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: References: Message-ID: <43D8F1EC.5030903@elet.polimi.it> At x-kad we're developing a Kademlia based DHT network. We're definitely considering the NAT issue, but it's still not clear if natted peers can actively contribute to the DHT protocol. Most natted peers can be contacted through UDP hole punching, but opening a UDP hole requires time, and the support of a helper non natted peer. In a routing DHT (e.g. if A wants to send a message to B, it sends it to the node C nearest to B it knows of. C will repeat the process), a natted node could open UDP holes with all its neighbours. In a non routing DHT, like Kademlia, in the course of any search (the most important primitive of the protocol) every peer might send messages to node he never heard of before. (e.g if A wants to send a message to B, it asks C, the node nearest to A it knows of, about how to contact B. B will send addresses D,E,F... and the process will repeat). Say that D is natted, and that A never talked before to D, A could think of opening a UDP hole with the help of E (not natted). But... if DHT is all about every node helping finding one another, did D, in these example be any help, or just a "problem"? My answer is that for non-routing network natted nodes are just a problem, and they can possibly actively contribute to data storage, but not to searches. I hope I was clear, and I'd appreciate if someone more expert could clarify better. Luca. Philip Matthews ha scritto: > I am wondering if anyone is aware of work on NAT-friendly DHT algorithms? > In other words, a DHT algorithm that works with the peers are located > behind NATs. > > From what I have seen. most DHT algorithms assume that any peer is > directly reachable > from any other peer, which is not true when peers are located behind > NATs. > Both Chord and Kademlia, for example, seem to make this assumption. > > - Philip > _______________________________________________ > 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 agthorr at cs.uoregon.edu Thu Jan 26 16:31:43 2006 From: agthorr at cs.uoregon.edu (Daniel Stutzbach) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: References: Message-ID: <20060126163141.GA1588@cs.uoregon.edu> On Thu, Jan 26, 2006 at 10:09:10AM -0500, Philip Matthews wrote: > I am wondering if anyone is aware of work on NAT-friendly DHT > algorithms? > In other words, a DHT algorithm that works with the peers are located > behind NATs. I believe all of the widely-deployed DHTs use un-NATed peers to make up the DHT and allow NATed peers to act as DHT clients (they can issue queries and publish information, but they don't do any routing). I know eMule's Kad network does this at minimum. -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon From matthew at matthew.at Thu Jan 26 17:08:05 2006 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: Message-ID: <037001c6229b$1591a6a0$0202fea9@matthewdesk> Philip Matthews: > I am wondering if anyone is aware of work on NAT-friendly DHT > algorithms? > In other words, a DHT algorithm that works with the peers are > located behind NATs. We're working on that here at amicima. One of the functions provided by our MFPGroup layer is DHT-style routing, and it is based on our existing (and open-source) MFPNet work that provides NAT traversal. > From what I have seen. most DHT algorithms assume that any > peer is directly reachable from any other peer... Most of the first round of DHT algorithms are research projects that don't solve a number of real-world problems. This is starting to change, and I think you'll be seeing more "usable in real products" algorithms and implementations in the near future. We, for instance, are tackling full participation by behind-NAT peers, cryptographic control of membership, high churn rate, and application-level multicast in our project. Which is probably why it hasn't shipped quite yet :) Matthew Kaufman matthew@matthew.at http://www.amicima.com From philip_matthews at magma.ca Thu Jan 26 20:15:08 2006 From: philip_matthews at magma.ca (Philip Matthews) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <8B3941F4-8B1A-46ED-884D-6FE7FBEFD664@squix.ch> References: <8B3941F4-8B1A-46ED-884D-6FE7FBEFD664@squix.ch> Message-ID: Dani: Thanks for your reply. I have given some thought to this topic, but I don't have a solution yet. Right now, I am just looking to see what others might have done. - Philip On 26-Jan-06, at 10:49 , Dani Eichhorn wrote: > Hi Philip > > I'm working on this topic for my diploma thesis. My first priority > goal is to implement a NAT traversal library that works > independently from any p2p routing algorithm. But I'm aware that a > perfectly designed algorithm would be much more efficient than this > workaround. > I don't know, if you know about this library: http:// > nutss.gforge.cis.cornell.edu/stunt.php > which is an architecture that provides endpoint-to-endpoint TCP > connections, yet using one or several central server(s). I'm trying > to adapt it for distributed applications, like DHT based frameworks. > > If you already have a solution in mind, I'd be glad to discuss it > with you.. > > Dani > > Am 26.01.2006 um 16:09 schrieb Philip Matthews: > >> I am wondering if anyone is aware of work on NAT-friendly DHT >> algorithms? >> In other words, a DHT algorithm that works with the peers are >> located behind NATs. >> >> From what I have seen. most DHT algorithms assume that any peer is >> directly reachable >> from any other peer, which is not true when peers are located >> behind NATs. >> Both Chord and Kademlia, for example, seem to make this assumption. >> >> - Philip >> _______________________________________________ >> 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 shudo at computer.org Fri Jan 27 05:49:40 2006 From: shudo at computer.org (shudo@computer.org) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: References: Message-ID: <20060127.144940.02292633.shudo@aist.go.jp> > From: Philip Matthews > Date: Thu, 26 Jan 2006 10:09:10 -0500 > I am wondering if anyone is aware of work on NAT-friendly DHT > algorithms? > In other words, a DHT algorithm that works with the peers are located > behind NATs. There will be 2 points of view. From the first standpoint, NAT traversal can be performed independently of a DHT algorithm. From another standpoint, an advanced DHT algorithm will be able to deal with such heterogeneity, in which even a NATted node can take a role on an overlay. As pointed out, it is common to introduce super-peers which host NATted peers. And an advanced algorithm, like HeterPastry, may adapt to such heterogeneous environemnt. UDP messaging service of Overlay Weaver implements UDP hole punching. The technique works with a lot of routers, but not all ones. The technique is not very reliable. Overlay Weaver: An Overlay Construction Toolkit http://overlayweaver.sf.net/ Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ From Bernard.Traversat at Sun.COM Fri Jan 27 07:21:40 2006 From: Bernard.Traversat at Sun.COM (Bernard Traversat) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: References: Message-ID: <43D9CA04.1060801@sun.com> Philip Matthews wrote: > I am wondering if anyone is aware of work on NAT-friendly DHT > algorithms? > In other words, a DHT algorithm that works with the peers are located > behind NATs. > > From what I have seen. most DHT algorithms assume that any peer is > directly reachable > from any other peer, which is not true when peers are located behind > NATs. > Both Chord and Kademlia, for example, seem to make this assumption. You may want to check JXTA (www.jxta.org). JXTA is implementing a loosely-coupled DHT with NAT/Firewall traversal support. Hth, B. > > - Philip > _______________________________________________ > 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 piccarre at elet.polimi.it Fri Jan 27 10:26:45 2006 From: piccarre at elet.polimi.it (Luca Piccarreta) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <20060127.144940.02292633.shudo@aist.go.jp> References: <20060127.144940.02292633.shudo@aist.go.jp> Message-ID: <43D9F565.4040306@elet.polimi.it> Forgive me, but I still don't have the picture clear. One peer might need to contact another one: 1) Because it wants to ask something only that peer knows (e.g., get a file from that peer, or make a phone call) 2) Because it wants to ask something that other peers may know (e.g., routing informations) I also made a distinction between routed network and non-routed network: 1) A peer exchanges messages with a small subset of nodes in the overlay network. This small subset will manage delivery to unknown peers 2) A peer exchanges search messages with possibly all peers in the network. Search is done by interrogating a sequence of peers (determined by analyzing peers answer) in order to reach the information desired (Kademlia) I said that the scheme 2) can not take advantage of natted nodes for finding informations. Well, of course it can... but it's not worth it. The UDP hole opening traffic (or the relay traffic) requested to the non natted peers might be more than the search traffic offloaded to the natted peers. Is anyone really thinking of using UDP hole punching for key searches in Kademlia-style networks? In this case, can a rapid sketch be made? For the moment I stick in my position, that is a separation between a low bw traffic for searches, managed by non natted peers, and a perhaps high bw traffic for more advanced services (like file storage or even storage) I had to work with a NAT with a 5 seconds UDP hole timeout... how can one think of opening more than a dozen of UDP holes if you have to keep them alive so frequently? And what about NATs changing mapped ports whenever we "forget" to keep alive to UDP hole? I think that if effort is to be dedicated to the NAT issue, it is to be dedicated to "many NAT layers" network schemes, in which a peer might have perhaps two or three addresses... Luca. shudo@computer.org ha scritto: >> From: Philip Matthews >> Date: Thu, 26 Jan 2006 10:09:10 -0500 >> > > >> I am wondering if anyone is aware of work on NAT-friendly DHT >> algorithms? >> In other words, a DHT algorithm that works with the peers are located >> behind NATs. >> > > There will be 2 points of view. From the first standpoint, NAT > traversal can be performed independently of a DHT algorithm. From > another standpoint, an advanced DHT algorithm will be able to deal > with such heterogeneity, in which even a NATted node can take a role > on an overlay. > > As pointed out, it is common to introduce super-peers which host > NATted peers. And an advanced algorithm, like HeterPastry, may adapt > to such heterogeneous environemnt. > > UDP messaging service of Overlay Weaver implements UDP hole punching. > The technique works with a lot of routers, but not all ones. The > technique is not very reliable. > > Overlay Weaver: An Overlay Construction Toolkit > http://overlayweaver.sf.net/ > > > Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ > > _______________________________________________ > 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 p2p-hackers at squix.ch Fri Jan 27 10:44:23 2006 From: p2p-hackers at squix.ch (Dani Eichhorn) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <43D9F565.4040306@elet.polimi.it> References: <20060127.144940.02292633.shudo@aist.go.jp> <43D9F565.4040306@elet.polimi.it> Message-ID: I know that a lot of you guys don't like one taking reference to the Skype network, because it is closed source. But according to the reverse engeneering done on it's protocol, the Skype guys happened to solve this problem. OK, they introduced a supernode level and natted peers have to be connected to them but still, they even pass through quiet hardcore firewalls by using common ports like the http port 80. That's what I'd like to have in a peer to peer framework: the user just doesn't have to worry about beeing natted or not. I guess there's not a single strategy to solve this issue, but quiet a bunch of it, like UDP AND TCP hole punching, UPnP device discovery and so on... I suppose that in the future the share of unnatted peers will even decrease, since during the transition from IPv4 to IPv6 will increase the need to NAT devices. And which p2p networks are going to run then, when you call natted peers a problem and don't have a solution for it? Dani Am 27.01.2006 um 11:26 schrieb Luca Piccarreta: > Forgive me, but I still don't have the picture clear. > One peer might need to contact another one: > 1) Because it wants to ask something only that peer knows > (e.g., get a file from that peer, or make a phone call) > 2) Because it wants to ask something that other peers may know > (e.g., routing informations) > > I also made a distinction between routed network and non-routed > network: > 1) A peer exchanges messages with a small subset of nodes in the > overlay network. This small subset will manage delivery to unknown > peers > 2) A peer exchanges search messages with possibly all peers in the > network. > Search is done by interrogating a sequence of peers (determined by > analyzing > peers answer) in order to reach the information desired (Kademlia) > > I said that the scheme 2) can not take advantage of natted nodes > for finding > informations. Well, of course it can... but it's not worth it. The > UDP hole > opening traffic (or the relay traffic) requested to the non natted > peers might > be more than the search traffic offloaded to the natted peers. > Is anyone really thinking of using UDP hole punching for key > searches in > Kademlia-style networks? > In this case, can a rapid sketch be made? > > For the moment I stick in my position, that is a separation > between a low bw > traffic for searches, managed by non natted peers, and a perhaps > high bw > traffic for more advanced services (like file storage or even > storage) > > I had to work with a NAT with a 5 seconds UDP hole timeout... how > can one > think of opening more than a dozen of UDP holes if you have to keep > them alive > so frequently? And what about NATs changing mapped ports whenever we > "forget" to keep alive to UDP hole? > > I think that if effort is to be dedicated to the NAT issue, it is > to be dedicated to > "many NAT layers" network schemes, in which a peer might have > perhaps two or > three addresses... > > Luca. > > shudo@computer.org ha scritto: >>> From: Philip Matthews >>> Date: Thu, 26 Jan 2006 10:09:10 -0500 >>> >> >> >>> I am wondering if anyone is aware of work on NAT-friendly DHT >>> algorithms? >>> In other words, a DHT algorithm that works with the peers are >>> located >>> behind NATs. >>> >> >> There will be 2 points of view. From the first standpoint, NAT >> traversal can be performed independently of a DHT algorithm. From >> another standpoint, an advanced DHT algorithm will be able to deal >> with such heterogeneity, in which even a NATted node can take a role >> on an overlay. >> >> As pointed out, it is common to introduce super-peers which host >> NATted peers. And an advanced algorithm, like HeterPastry, may adapt >> to such heterogeneous environemnt. >> >> UDP messaging service of Overlay Weaver implements UDP hole punching. >> The technique works with a lot of routers, but not all ones. The >> technique is not very reliable. >> >> Overlay Weaver: An Overlay Construction Toolkit >> http://overlayweaver.sf.net/ >> >> >> Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ >> >> _______________________________________________ >> 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 piccarre at elet.polimi.it Fri Jan 27 12:25:19 2006 From: piccarre at elet.polimi.it (Luca Piccarreta) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: References: <20060127.144940.02292633.shudo@aist.go.jp> <43D9F565.4040306@elet.polimi.it> Message-ID: <43DA112F.9060006@elet.polimi.it> Hi Dani, > I know that a lot of you guys don't like one taking reference to the > Skype network, because it is closed source. But according to the > reverse engeneering done on it's protocol, the Skype guys happened to > solve this problem. OK, they introduced a supernode level and natted > peers have to be connected to them but still, they even pass through > quiet hardcore firewalls by using common ports like the http port 80. > That's what I'd like to have in a peer to peer framework: the user > just doesn't have to worry about beeing natted or not. I guess there's > not a single strategy to solve this issue, but quiet a bunch of it, > like UDP AND TCP hole punching, UPnP device discovery and so on... I think Skype does exactly what I said, a flat P2P network between non natted peers, and a relay/udp hole approach between natted peers. I think that Skype really worries about having phone calls not relayed, but I think that natted peers do not contribute to users lookup (actually I think that users lookup is handled by Skype servers, and the whole P2P stuff is just a relay/udp hole opener framework) > I suppose that in the future the share of unnatted peers will even > decrease, since during the transition from IPv4 to IPv6 will increase > the need to NAT devices. And which p2p networks are going to run then, > when you call natted peers a problem and don't have a solution for it? ... what about Skype then? About my "no solution"... I'll stick with Kademlia, I'll follow the same Skype approach, I'll try and keep the traffic so low that even super nodes won't have much to complain, and I'll try and see what comes next. Even with this very dumb approach natted peers will be able to store data, to be contacted, to search for data. They will use the DHT, they won't contribute to it. I see the DHT network as a graph. some nodes are connected, some nodes are not. Some nodes can be connected through UDP holes, some nodes can not. But opening a UDP hole it's worth it *only if the traffic that is going to flow through the UDP hole is much greater than the traffic required to open it*. In the case of Kademlia searches, IMO, this last assertion simply doesn't hold. Luca. > Dani > > Am 27.01.2006 um 11:26 schrieb Luca Piccarreta: > >> Forgive me, but I still don't have the picture clear. >> One peer might need to contact another one: >> 1) Because it wants to ask something only that peer knows >> (e.g., get a file from that peer, or make a phone call) >> 2) Because it wants to ask something that other peers may know >> (e.g., routing informations) >> >> I also made a distinction between routed network and non-routed network: >> 1) A peer exchanges messages with a small subset of nodes in the >> overlay network. This small subset will manage delivery to unknown >> peers >> 2) A peer exchanges search messages with possibly all peers in the >> network. >> Search is done by interrogating a sequence of peers (determined by >> analyzing >> peers answer) in order to reach the information desired (Kademlia) >> >> I said that the scheme 2) can not take advantage of natted nodes for >> finding >> informations. Well, of course it can... but it's not worth it. The >> UDP hole >> opening traffic (or the relay traffic) requested to the non natted >> peers might >> be more than the search traffic offloaded to the natted peers. >> Is anyone really thinking of using UDP hole punching for key searches in >> Kademlia-style networks? >> In this case, can a rapid sketch be made? >> >> For the moment I stick in my position, that is a separation between >> a low bw >> traffic for searches, managed by non natted peers, and a perhaps high bw >> traffic for more advanced services (like file storage or even >> storage) >> >> I had to work with a NAT with a 5 seconds UDP hole timeout... how can >> one >> think of opening more than a dozen of UDP holes if you have to keep >> them alive >> so frequently? And what about NATs changing mapped ports whenever we >> "forget" to keep alive to UDP hole? >> >> I think that if effort is to be dedicated to the NAT issue, it is to >> be dedicated to >> "many NAT layers" network schemes, in which a peer might have perhaps >> two or >> three addresses... >> >> Luca. >> >> shudo@computer.org ha scritto: >>>> From: Philip Matthews >>>> Date: Thu, 26 Jan 2006 10:09:10 -0500 >>>> >>> >>> >>>> I am wondering if anyone is aware of work on NAT-friendly DHT >>>> algorithms? >>>> In other words, a DHT algorithm that works with the peers are located >>>> behind NATs. >>>> >>> >>> There will be 2 points of view. From the first standpoint, NAT >>> traversal can be performed independently of a DHT algorithm. From >>> another standpoint, an advanced DHT algorithm will be able to deal >>> with such heterogeneity, in which even a NATted node can take a role >>> on an overlay. >>> >>> As pointed out, it is common to introduce super-peers which host >>> NATted peers. And an advanced algorithm, like HeterPastry, may adapt >>> to such heterogeneous environemnt. >>> >>> UDP messaging service of Overlay Weaver implements UDP hole punching. >>> The technique works with a lot of routers, but not all ones. The >>> technique is not very reliable. >>> >>> Overlay Weaver: An Overlay Construction Toolkit >>> http://overlayweaver.sf.net/ >>> >>> >>> Kazuyuki Shudo shudo@computer.org http://www.shudo.net/ >>> >>> _______________________________________________ >>> 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 gbildson at limepeer.com Fri Jan 27 16:54:32 2006 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <43DA112F.9060006@elet.polimi.it> Message-ID: I expect that most of us would agree that Luca has it right. Unless the natted host opens itself up globally and permanently to UDP and/or TCP traffic after being punched, it will be of little use with lookups. Thanks -greg From matthew at matthew.at Fri Jan 27 17:08:36 2006 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: Message-ID: <039201c62364$529f2120$0202fea9@matthewdesk> Greg Bildson: > I expect that most of us would agree that Luca has it right. > Unless the natted host opens itself up globally and > permanently to UDP and/or TCP traffic after being punched, it > will be of little use with lookups. ...for those DHT designs that use iterative lookups exclusively (and IP addresses to describe node locations) Matthew Kaufman matthew@matthew.at http://www.amicima.com From piccarre at elet.polimi.it Fri Jan 27 23:17:41 2006 From: piccarre at elet.polimi.it (Luca Piccarreta) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <43DA112F.9060006@elet.polimi.it> References: <20060127.144940.02292633.shudo@aist.go.jp> <43D9F565.4040306@elet.polimi.it> <43DA112F.9060006@elet.polimi.it> Message-ID: <43DAAA15.9020802@elet.polimi.it> Hi all, I looked again the previous mails I sent....(thanks Philip) I was freely using the NAT word for "endpoint-filtered NAT". So, correction... 1) NAT in itself (just address translation)-> not a big problem 2) "endpoint-independent filtering" -> not a big problem 3) "endpoint-dependent filtering" ->big trouble for Kademlia. Luca. From saikat at cs.cornell.edu Fri Jan 27 23:40:26 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <43DAAA15.9020802@elet.polimi.it> References: <20060127.144940.02292633.shudo@aist.go.jp> <43D9F565.4040306@elet.polimi.it> <43DA112F.9060006@elet.polimi.it> <43DAAA15.9020802@elet.polimi.it> Message-ID: <1138405226.1447.20.camel@localhost.localdomain> On Sat, 2006-01-28 at 00:17 +0100, Luca Piccarreta wrote: > 1) NAT in itself (just address translation)-> not a big problem > 2) "endpoint-independent filtering" -> not a big problem > 3) "endpoint-dependent filtering" ->big trouble for Kademlia. FWIW, many major vendors refuse to implement anything other than #3. There may still be vendors that are willing to consider #2 advertising "application transparency", but a majority of the NATs are going to have the more stringent setting #3. The RFC does not prefer one over the other; developers clearly prefer #2, vendors prefer #3 [NAT-RFC]. In fact, #3-type NATs already outnumbers #2-type NATs by a factor of 16! [TCP-NAT] Furthermore as more and more applications become NAT-aware; "application transparency" will become an increasingly thin ground for vendors to compete on. I would expect the proportion of #3-NATs to increase beyond the 94% mark from last year. [NAT-RFC] http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-04.txt [TCP-NAT] http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060127/c2c1dbb9/attachment.pgp From sbest at best.com Sat Jan 28 00:20:58 2006 From: sbest at best.com (Scott C. Best) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Re: Work on NAT-friendly DHTs? In-Reply-To: <20060127165440.E3C9C3FD6B@capsicum.zgp.org> References: <20060127165440.E3C9C3FD6B@capsicum.zgp.org> Message-ID: <20060128001449.T43255@kaboodle.org> Dani, Philip: Heyaz. Similar to stunt, the echoWare DLL is intended to enable endpoint-to-endpoint TCP via a central server (ie, an "echoServer" piece of shareware). It's most popular use right now is as part of a VNC-based remote-support platform. More info on echoWare here: http://www.echogent.com/tech.htm Please let me know if I can provide further details. cheers, Scott > Thanks for your reply. > > I have given some thought to this topic, but I don't have a solution > yet. > Right now, I am just looking to see what others might have done. > > - Philip > > On 26-Jan-06, at 10:49 , Dani Eichhorn wrote: > >> Hi Philip >> >> I'm working on this topic for my diploma thesis. My first priority >> goal is to implement a NAT traversal library that works >> independently from any p2p routing algorithm. But I'm aware that a >> perfectly designed algorithm would be much more efficient than this >> workaround. >> I don't know, if you know about this library: http:// >> nutss.gforge.cis.cornell.edu/stunt.php >> which is an architecture that provides endpoint-to-endpoint TCP >> connections, yet using one or several central server(s). I'm trying >> to adapt it for distributed applications, like DHT based frameworks. >> >> If you already have a solution in mind, I'd be glad to discuss it >> with you.. >> >> Dani From piccarre at elet.polimi.it Sat Jan 28 00:42:28 2006 From: piccarre at elet.polimi.it (Luca Piccarreta) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <1138405226.1447.20.camel@localhost.localdomain> References: <20060127.144940.02292633.shudo@aist.go.jp> <43D9F565.4040306@elet.polimi.it> <43DA112F.9060006@elet.polimi.it> <43DAAA15.9020802@elet.polimi.it> <1138405226.1447.20.camel@localhost.localdomain> Message-ID: <43DABDF4.7080503@elet.polimi.it> Hi Saikat, thanks for the note. I really hope you're not right! :) From a commercial point of view network providers don't like P2P, at least, they prefer P2P to stay inside their network. It's "subsidization": servers pay for bandwidth, client pay much less. P2P is trying to subvert the client-server paradygm... So, I wouldn't really be surprised if network provider /corporate NATs would implement endpoint-dependent filtering (#3). After all, it is coherent with the client/server model. Residential NATs (wireless adsl routers, or whatever) have bundled #3 model for improved security, I guess. I can see no other reason for that, definitely not a technical one. The role of the NAT should just be routing packets to the most likely packet destination. The role of a firewall is filtering unsolicited packets. Model #3 is, to my eyes, NAT+firewall. But unsolicited packet filtering is already built in windows, nowadays... Who knows! And about ipv6... yes the switch from ipv4 to ipv6 will be likely made through NATs usage, but what model? #2 or #3? My fear is that network providers, very often coincident with telephony providers, don't really like the idea of ubiquitous P2P. Who would pay for phone calls? Who would pay for VideoTelephony? Voice traffic is in many cases already over IP, and is paid so much more than data traffic (in terms of MBytes). So if they can do something to stop P2P, or confine it in their network, they will.... (I talk from experience, in Italy there is a fiber provider, 10MBits/s: P2P is fantastic, get a movie in 10 minutes... but the firewall is... #3. There was some voice that file sharing servers were hosted by the provider itself! If they made it possible to make P2P with outside the network, their outbound pipes would be saturated immediately) Just a bunch of confused thoughts.... Luca. Saikat Guha ha scritto: > On Sat, 2006-01-28 at 00:17 +0100, Luca Piccarreta wrote: > >> 1) NAT in itself (just address translation)-> not a big problem >> 2) "endpoint-independent filtering" -> not a big problem >> 3) "endpoint-dependent filtering" ->big trouble for Kademlia. >> > > FWIW, many major vendors refuse to implement anything other than #3. > There may still be vendors that are willing to consider #2 advertising > "application transparency", but a majority of the NATs are going to have > the more stringent setting #3. > > The RFC does not prefer one over the other; developers clearly prefer > #2, vendors prefer #3 [NAT-RFC]. In fact, #3-type NATs already > outnumbers #2-type NATs by a factor of 16! [TCP-NAT] > > Furthermore as more and more applications become NAT-aware; "application > transparency" will become an increasingly thin ground for vendors to > compete on. I would expect the proportion of #3-NATs to increase beyond > the 94% mark from last year. > > [NAT-RFC] > http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-04.txt > > [TCP-NAT] http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/ > > cheers, > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 saikat at cs.cornell.edu Sat Jan 28 01:14:14 2006 From: saikat at cs.cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Work on NAT-friendly DHTs? In-Reply-To: <43DABDF4.7080503@elet.polimi.it> References: <20060127.144940.02292633.shudo@aist.go.jp> <43D9F565.4040306@elet.polimi.it> <43DA112F.9060006@elet.polimi.it> <43DAAA15.9020802@elet.polimi.it> <1138405226.1447.20.camel@localhost.localdomain> <43DABDF4.7080503@elet.polimi.it> Message-ID: <1138410854.1447.34.camel@localhost.localdomain> On Sat, 2006-01-28 at 01:42 +0100, Luca Piccarreta wrote: > The role of the NAT should just be routing [...] > The role of a firewall is filtering unsolicited packets. > Model #3 is, to my eyes, NAT+firewall. Agreed; nevertheless NATs are necessary to extend the address space (for now), and firewalls are necessary (for security). The logical separation of "pure-NAT" and "pure-firewall" is moot; both are required middle-boxes and vendors will combine them into one convenient product. If they don't, you'll end up with two separate middle-boxes with the same combined effect anyway. > that file sharing servers were hosted by the provider > itself! If they made it possible to make P2P with outside the network, > their outbound pipes would be saturated immediately) File-sharing content it highly cacheable (not zipf, not dynamic, etc). There are entire business models behind the idea where your ISP can steer P2P to internal hosts when possible, and allow outbound connections only on the first fetch of an object (http://www.cachelogic.com/). cheers, -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060127/07ecc460/attachment.pgp From olau at cs.aau.dk Mon Jan 30 13:29:54 2006 From: olau at cs.aau.dk (Ole Laursen) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Network library? Message-ID: Hi, What can people here recommend for a network library for C, C++, Java or C#? It should support an event-driven style of programming and preferably have a messaging interface ("send this string to X", "received this string from Y") with support for TLS. I've going to use it for a LAN so NAT-hole punching and UDP support is not important. -- Ole Laursen http://www.cs.aau.dk/~olau/ From jbj at forbidden.co.uk Mon Jan 30 14:49:43 2006 From: jbj at forbidden.co.uk (Jeremy James) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Network library? In-Reply-To: References: Message-ID: <43DE2787.8060903@forbidden.co.uk> Ole Laursen wrote: > What can people here recommend for a network library for C, C++, Java > or C#? It should support an event-driven style of programming and > preferably have a messaging interface ("send this string to X", > "received this string from Y") with support for TLS. > > I've going to use it for a LAN so NAT-hole punching and UDP support is > not important. And while you're about it, I'm looking for a library with an identical specification under Python. Being event-based would suggest twisted as being a good base (as well as having TLS etc on-hand), although I haven't found a good library yet (yes, I know about Khashmir [1], but that's just a DHT, and I need a routing/messaging interface). I've had several attempts with Kenosis [2] to get it working, but only been able to get it running once under a version of python on one of my machines, let alone getting round to doing any development. This is a shame, since one of its goals on the website is to 'Just Work'. If I can't find a suitable library, I'll write my own, but would appreciate any suggestions of standards to use (or other language libraries to port) to make it cross-library and cross-platform compatible. Best wishes, Jeremy [1] http://khashmir.sourceforge.net/ [2] http://kenosis.sourceforge.net/ From solipsis at pitrou.net Mon Jan 30 16:06:01 2006 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Python network library In-Reply-To: <43DE2787.8060903@forbidden.co.uk> References: <43DE2787.8060903@forbidden.co.uk> Message-ID: <1138637161.5407.5.camel@fsol> Le lundi 30 janvier 2006 ? 14:49 +0000, Jeremy James a ?crit : > And while you're about it, I'm looking for a library with an identical > specification under Python. Being event-based would suggest twisted as > being a good base (as well as having TLS etc on-hand), although I > haven't found a good library yet (yes, I know about Khashmir [1], but > that's just a DHT, and I need a routing/messaging interface). Twisted is almost the de facto standard library for non-trivial network applications with Python. Of course some people prefer writing their own (this is what Bittorrent does, although ironically it has taken a bit of code from Twisted AFAIK), but if you are looking for something widely supported then Twisted is the best bet. You'll probably find that Twisted makes your programming much easier than having to deal with all the low-level stuff yourself. regards Antoine. From olau at cs.aau.dk Mon Jan 30 16:30:21 2006 From: olau at cs.aau.dk (Ole Laursen) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Network library? In-Reply-To: <43DE2787.8060903@forbidden.co.uk> References: <43DE2787.8060903@forbidden.co.uk> Message-ID: Jeremy James writes: > And while you're about it, I'm looking for a library with an identical > specification under Python. Being event-based would suggest twisted as > being a good base (as well as having TLS etc on-hand), although I > haven't found a good library yet (yes, I know about Khashmir [1], but > that's just a DHT, and I need a routing/messaging interface). Try the Netstring protocol in Twisted. I've tried it for a prototype. If you program a connection pool on top of it, it works reasonable well. If you are interested, I can probably dig up some code somewhere. -- Ole Laursen http://www.cs.aau.dk/~olau/ From agthorr at cs.uoregon.edu Mon Jan 30 17:46:11 2006 From: agthorr at cs.uoregon.edu (Daniel Stutzbach) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Python network library In-Reply-To: <1138637161.5407.5.camel@fsol> References: <43DE2787.8060903@forbidden.co.uk> <1138637161.5407.5.camel@fsol> Message-ID: <20060130174610.GC2304@cs.uoregon.edu> On Mon, Jan 30, 2006 at 05:06:01PM +0100, Antoine Pitrou wrote: > Twisted is almost the de facto standard library for non-trivial network > applications with Python. > Of course some people prefer writing their own (this is what Bittorrent > does, although ironically it has taken a bit of code from Twisted > AFAIK), but if you are looking for something widely supported then > Twisted is the best bet. When Bram Cohen started working on BitTorrent, Twisted wasn't around (or hadn't released version 1.0 yet, at any rate). > You'll probably find that Twisted makes your programming much easier > than having to deal with all the low-level stuff yourself. Twisted is the modern luxury car of network programing, making Berkeley sockets look like a Model-T. :-) -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon From nigini at gmail.com Tue Jan 31 11:46:59 2006 From: nigini at gmail.com (Nigini Oliveira) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Codes for Error Correction in P2P Nets Message-ID: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> Hello All. I'm researching these days on some kind of codes that helps the distribution of data at networks (Error Correcting Codes). I would like to know if someone have good references (digital in preference) about how the real systems implements these codes and related ideas. For example: How are the files divided in pices to be shared? And how the pices are rebuild togheter? Thanks. -- Nigini Abilio Oliveira Mestrando em Computa??o UFCG - DSC - COPIN www.nigini.com.br nigini@gmail.com nigini@dsc.ufcg.edu.br -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060131/ae76b128/attachment.html From justin at specialbusservice.com Tue Jan 31 11:53:13 2006 From: justin at specialbusservice.com (Justin Cormack) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Codes for Error Correction in P2P Nets In-Reply-To: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> References: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> Message-ID: <9FC61E72-329B-4F48-BFE6-0ECA3C9D935E@specialbusservice.com> On 31 Jan 2006, at 11:46, Nigini Oliveira wrote: > Hello All. > > I'm researching these days on some kind of codes that helps the > distribution of data at networks (Error Correcting Codes). I would > like to know if someone have good references (digital in > preference) about how the real systems implements these codes and > related ideas. For example: How are the files divided in pices to > be shared? And how the pices are rebuild togheter? > There is some good stuff on http://www.digitalfountain.com/ j From mgp at ucla.edu Tue Jan 31 19:19:42 2006 From: mgp at ucla.edu (Michael Parker) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Codes for Error Correction in P2P Nets In-Reply-To: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> References: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> Message-ID: <20060131111942.x6mca4oyswscc0c0@mail.ucla.edu> A very good overview of all network coding for the purposes of data distribution (i.e., making digital fountains) can be found at: www.eecs.harvard.edu/~michaelm/postscripts/itw2004.pdf Some of the more interesting and practical codes, such as Raptor codes (discussed at the end of that paper), are covered by patents. Another network coding that is comparable to Raptor codes is Online codes. The following paper, by the creator of Online codes, presents an efficient algorithm for downloading large files using them: http://mnl.cs.stonybrook.edu/home/karthik/BitTorrent/papers/incentives/toread/rateless_codes.ps IIRC, the creator of Online codes -- Petar Maymounkov -- started a company Rateless and was going to patent them. But Online codes fell into the scope of Digital Fountain's patents, who own the Raptor codes. So I don't know who owns the patents for Online codes anymore, but rest assured they're patented :( - Mike Quoting Nigini Oliveira : > Hello All. > > I'm researching these days on some kind of codes that helps the distribution > of data at networks (Error Correcting Codes). I would like to know if > someone have good references (digital in preference) about how the real > systems implements these codes and related ideas. For example: How are the > files divided in pices to be shared? And how the pices are rebuild togheter? > > Thanks. > > -- > Nigini Abilio Oliveira > Mestrando em Computa??o > UFCG - DSC - COPIN > www.nigini.com.br > nigini@gmail.com > nigini@dsc.ufcg.edu.br > From wesley at felter.org Tue Jan 31 20:03:52 2006 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Codes for Error Correction in P2P Nets In-Reply-To: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> References: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> Message-ID: <43DFC2A8.3030702@felter.org> Nigini Oliveira wrote: > I'm researching these days on some kind of codes that helps the > distribution of data at networks (Error Correcting Codes). I would like > to know if someone have good references (digital in preference) about > how the real systems implements these codes and related ideas. For > example: How are the files divided in pices to be shared? And how the > pices are rebuild togheter? http://www.cs.utk.edu/~plank/plank/papers/papers.html http://www.inrialpes.fr/planete/people/roca/mcl/mcl.html http://pdos.csail.mit.edu/~petar/pubs.html http://research.microsoft.com/~pablo/avalanche.aspx http://bramcohen.livejournal.com/1416.html This looks like the last available version of Swarmcast source code: http://prdownloads.sourceforge.net/swarmcast/swarmcast-bourbon-11.zip Wes Felter - wesley@felter.org From luigi at diacronic.org Tue Jan 31 20:20:36 2006 From: luigi at diacronic.org (=?iso-8859-1?Q?Luigi_De_Don=E0?=) Date: Sat Dec 9 22:13:09 2006 Subject: R: [p2p-hackers] Codes for Error Correction in P2P Nets In-Reply-To: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> Message-ID: Hi all, here materials about FEC from a pioneer : Luigi Rizzo (University of Pisa ? ITALY) : http://info.iet.unipi.it/~luigi/fec.html Luigi De Don? _____ Da: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] Per conto di Nigini Oliveira Inviato: marted? 31 gennaio 2006 12.47 A: p2p-hackers@zgp.org Oggetto: [p2p-hackers] Codes for Error Correction in P2P Nets Hello All. I'm researching these days on some kind of codes that helps the distribution of data at networks (Error Correcting Codes). I would like to know if someone have good references (digital in preference) about how the real systems implements these codes and related ideas. For example: How are the files divided in pices to be shared? And how the pices are rebuild togheter? Thanks. -- Nigini Abilio Oliveira Mestrando em Computa??o UFCG - DSC - COPIN www.nigini.com.br nigini@gmail.com nigini@dsc.ufcg.edu.br -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060131/ca76fe57/attachment.htm From alenlpeacock at gmail.com Tue Jan 31 21:51:13 2006 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:09 2006 Subject: [p2p-hackers] Codes for Error Correction in P2P Nets In-Reply-To: <43DFC2A8.3030702@felter.org> References: <94fec2490601310346m3999cb19n2519b520446c5fb2@mail.gmail.com> <43DFC2A8.3030702@felter.org> Message-ID: On 1/31/06, Wes Felter wrote: > ... > http://www.inrialpes.fr/planete/people/roca/mcl/mcl.html > ... > The MCL stuff (LDPC/LDGM) will be particularly attractive if you are looking for something that appears to be unencumbered by patent claims. Alen -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060131/9fb705af/attachment.html