From travis at redswoosh.net Mon May 1 08:50:36 2006 From: travis at redswoosh.net (Travis Kalanick) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Please help me update my address book In-Reply-To: <4453ACB6.1020201@bitzi.com> Message-ID: <200605010859.k418xW1A026897@be9.noc0.redswoosh.com> Sorry guys. I thought I had filtered out but Plaxo seems to have missed it and p2p-hackers slipped through. As a point of fact, this happened once before more than a year ago. I do apologize as I understand this is an abuse of the list and the great dialogue we have here. I will take the p2p-hackers email completely out of my contacts to make sure it doesn't happen again. Gordon, I'm wondering what's more abusive, the mistake on Plaxo, or your gratuitous spam you sent to all as a response. But don't fret, while p2p-hackers has been removed, I'll make sure to keep you up to date on my contact info as you seem to enjoy it so much. :) Gordon, if you have more to say on the subject, please spare the list and email me privately. Thanks, T -----Original Message----- From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Gordon Mohr (@ Bitzi) Sent: Saturday, April 29, 2006 11:13 AM To: Peer-to-peer development. Subject: Re: [p2p-hackers] Please help me update my address book Ah, like the turning of the leaves, the Travis Kalanick Plaxo message (and followup apology) is part of the wonderful and eternal cycle of life here at p2p-hackers. :) - Gordon Travis Kalanick wrote: > Peer-to-peer, > > I'm updating my address book. Please take a moment to update your latest > contact information. I use Plaxo to manage my personal address book. > > Thanks for your help, and please don't hesitate to use this as an excuse > to send me a note. > > Travis Kalanick > travis@redswoosh.net > Red Swoosh, Inc. > > > > > Click the buttons below to change or confirm your info > > > Peer-to-peer development. > no title > no company > no work address > > > p2p-hackers@zgp.org > no web page > IM: none > > tel: none > fax: none > mobile: none > pager: none > > > > Is this information correct? > > > > > > P.S. I've attached my current information in a vcard. If you get Plaxo > too, we'll stay in touch automatically. > > If you do not wish to receive update request emails from Travis > Kalanick, click here > to > opt-out. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 eugen at leitl.org Mon May 1 16:49:14 2006 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Please help me update my address book In-Reply-To: <200605010859.k418xW1A026897@be9.noc0.redswoosh.com> References: <4453ACB6.1020201@bitzi.com> <200605010859.k418xW1A026897@be9.noc0.redswoosh.com> Message-ID: <20060501164914.GJ22800@leitl.org> List owner, this Travis Kalanick person has been spamming many lists I'm on with his Plaxo crap. Repeatedly and unrepentantly. This apology is a disingenous lie, and I suggest he should be removed and banned from the list. On Mon, May 01, 2006 at 01:50:36AM -0700, Travis Kalanick wrote: > > Sorry guys. I thought I had filtered out but Plaxo seems to have missed it > and p2p-hackers slipped through. > > As a point of fact, this happened once before more than a year ago. I do > apologize as I understand this is an abuse of the list and the great > dialogue we have here. I will take the p2p-hackers email completely out of > my contacts to make sure it doesn't happen again. > > Gordon, I'm wondering what's more abusive, the mistake on Plaxo, or your > gratuitous spam you sent to all as a response. But don't fret, while > p2p-hackers has been removed, I'll make sure to keep you up to date on my > contact info as you seem to enjoy it so much. :) > > Gordon, if you have more to say on the subject, please spare the list and > email me privately. > > Thanks, > > T > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Gordon Mohr (@ Bitzi) > Sent: Saturday, April 29, 2006 11:13 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Please help me update my address book > > Ah, like the turning of the leaves, the Travis Kalanick Plaxo > message (and followup apology) is part of the wonderful and > eternal cycle of life here at p2p-hackers. :) > > - Gordon > > Travis Kalanick wrote: > > Peer-to-peer, > > > > I'm updating my address book. Please take a moment to update your latest > > contact information. I use Plaxo to manage my personal address book. > > > > Thanks for your help, and please don't hesitate to use this as an excuse > > to send me a note. > > > > Travis Kalanick > > travis@redswoosh.net > > Red Swoosh, Inc. > > > > > > > > > > Click the buttons below to change or confirm your info > > > t=web> > > > > Peer-to-peer development. > > no title > > no company > > no work address > > > > > > p2p-hackers@zgp.org > > no web page > > IM: none > > > > tel: none > > fax: none > > mobile: none > > pager: none > > > > > > > > Is this information correct? > > > > > > > > > > > > P.S. I've attached my current information in a vcard. If you get Plaxo > > too, we'll stay in touch automatically. > > > > If you do not wish to receive update request emails from Travis > > Kalanick, click here > > to > > opt-out. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 -- Eugen* Leitl leitl http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: Digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060501/4d81607a/attachment.pgp From gojomo at bitzi.com Mon May 1 22:44:17 2006 From: gojomo at bitzi.com (Gordon Mohr) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Please help me update my address book In-Reply-To: <200605010859.k418xW1A026897@be9.noc0.redswoosh.com> References: <200605010859.k418xW1A026897@be9.noc0.redswoosh.com> Message-ID: <44568F41.8040806@bitzi.com> Ah, the seasons. It's happened twice here before: 12/7/2004 and 3/29/2005. Plus once or twice on another list we both frequent (Pho -- I think I ribbed you there once about this, too.) No biggie. I wouldn't even call it abusive. Just a little funny. - Gordon Travis Kalanick wrote: > Sorry guys. I thought I had filtered out but Plaxo seems to have missed it > and p2p-hackers slipped through. > > As a point of fact, this happened once before more than a year ago. I do > apologize as I understand this is an abuse of the list and the great > dialogue we have here. I will take the p2p-hackers email completely out of > my contacts to make sure it doesn't happen again. > > Gordon, I'm wondering what's more abusive, the mistake on Plaxo, or your > gratuitous spam you sent to all as a response. But don't fret, while > p2p-hackers has been removed, I'll make sure to keep you up to date on my > contact info as you seem to enjoy it so much. :) > > Gordon, if you have more to say on the subject, please spare the list and > email me privately. > > Thanks, > > T > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Gordon Mohr (@ Bitzi) > Sent: Saturday, April 29, 2006 11:13 AM > To: Peer-to-peer development. > Subject: Re: [p2p-hackers] Please help me update my address book > > Ah, like the turning of the leaves, the Travis Kalanick Plaxo > message (and followup apology) is part of the wonderful and > eternal cycle of life here at p2p-hackers. :) > > - Gordon > > Travis Kalanick wrote: >> Peer-to-peer, >> >> I'm updating my address book. Please take a moment to update your latest >> contact information. I use Plaxo to manage my personal address book. >> >> Thanks for your help, and please don't hesitate to use this as an excuse >> to send me a note. >> >> Travis Kalanick >> travis@redswoosh.net >> Red Swoosh, Inc. >> >> >> >> >> Click the buttons below to change or confirm your info >> > t=web> >> Peer-to-peer development. >> no title >> no company >> no work address >> >> >> p2p-hackers@zgp.org >> no web page >> IM: none >> >> tel: none >> fax: none >> mobile: none >> pager: none >> >> >> >> Is this information correct? >> >> >> >> >> >> P.S. I've attached my current information in a vcard. If you get Plaxo >> too, we'll stay in touch automatically. >> >> If you do not wish to receive update request emails from Travis >> Kalanick, click here >> to >> opt-out. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 Tue May 2 10:38:07 2006 From: shudo at computer.org (Kazuyuki Shudo) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Overlay Weaver 0.2.1 released In-Reply-To: <20060117.002110.424245970.shudo@aist.go.jp> References: <20060117.002110.424245970.shudo@aist.go.jp> Message-ID: <20060502.193807.844019685.shudo@localhost> Hi all, Overlay Weaver 0.2.1 is available now. It implements an additional routing (DHT) algorithm Koorde in addition to Chord, Kademlia, Pastry, and Tapestry. I hope you enjoy it. > Subject: [p2p-hackers] Overlay Weaver: An Overlay Construction Toolkit > From: shudo@computer.org > To: p2p-hackers@zgp.org > Date: Tue, 17 Jan 2006 00:21:10 +0900 (JST) > 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 2006@shudo.net http://www.shudo.net/ From Arnaud.Legout at sophia.inria.fr Wed May 3 10:25:47 2006 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" Message-ID: <4458852B.5080300@sophia.inria.fr> Hello, we have a new paper called "rarest first and choke algorithms are enough" that is about an experimental evaluation of the two core BitTorrent algorithms on real torrents. A. Legout, G. Urvoy-Keller, and P. Michiardi. Rarest First and Choke Algorithms Are Enough. Technical Report (inria-00001111, version 1 - 13 February 2006), INRIA, Sophia Antipolis, February 2006. http://hal.inria.fr/inria-00001111/en Comments are welcomed. Regards, Arnaud Legout. -- Arnaud Legout, Ph.D. INRIA Sophia Antipolis - Plan?te Phone : 00.33.4.92.38.78.15 2004 route des lucioles - BP 93 Fax : 00.33.4.92.38.79.78 06902 Sophia Antipolis CEDEX E-mail: arnaud.legout@sophia.inria.fr FRANCE Web : http://www-sop.inria.fr/planete/Arnaud.Legout/index.html From brturn at gmail.com Wed May 3 17:57:09 2006 From: brturn at gmail.com (Bryan Turner) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: <4458852B.5080300@sophia.inria.fr> References: <4458852B.5080300@sophia.inria.fr> Message-ID: Arnaud, Thanks for the new paper, there is a lot of nice data here. The presented graphs and analysis indeed suggest that the BitTorrent protocol's choices achieve near-optimal data distribution in its paradigm (single file, block-based content distribution). I agree with your suggestions for fairness criteria, and my own suggestions are similar (my suggestion is for a reputation-based system to model leechers and free-riders). However, I disagree with several conclusions you make along the way. A brief overview: - Byte-for-byte fairness is not appropriate - Network Coding is not justified Fairness: I am unconvinced by the arguments against byte-for-byte fairness. Your evidence to support this is that tit-for-tat does not take into account the excess capacity of some torrents (ie: more seeders than leechers). Yet this situation is equivalent under byte-for-byte and choking rules. Leechers are upholding the byte-for-byte policy (seeders cannot, as you mention) and thus only leechers are restricting their upload capacities to free-riders, and rightly so. Seeds (who hold the excess capacity) are distributing this capacity fairly to all peers. Thus, choking and byte-for-byte are equivalent in this regard - free riders receive a share of the bandwidth equal to the fair distribution given by seeders in both cases. The more important case, when excess capacity is not available, free riders should be eliminated or diminished. Because leecher participation cannot be proven, the only other method of measurement is via equal exchange of services. Byte-for-byte is one such measurement (reputation systems are another). In this scenario, free riders will only receive a small credit from the leechers in the swarm before having to resort to hand-outs from the seeds. With the seeds giving fair capacity to the swarm, the free riders will receive very little of the swarm capacity, while the participating leechers will receive fair resources. Free riders always receive more resources under choking than under exchange measurement models. Network Coding: On the topic of Network Coding [1], I did not see any evidence in your paper refuting the network coding literature. Please correct me if I missed it, but it appears your only rebuttal is in the poor modeling of BitTorrent, not in the application of network coding techniques. From this I don't see how you conclude that network coding is not justified? I agree that most of the simulation literature does not model BitTorrent correctly, but this doesn't negate the positive results of the network coding trials, only their comparisons to BitTorrent. In section 4-A, pp 6-7, you suggest that source or network coding may not propose interesting pieces to peers during the startup phase. I counter that this is exactly what network coding solves - every packet has an innovation rate based on the network flows from the local node to the source(s). Assuming a densely connected graph with fair sharing from the seeder, it is unlikely that any packet is not innovative during the startup phase. Unless the local node's bandwidth is many multiples of the seeder, a problem which is not specific to network coding. Network Coding is superior to Rarest First and other BitTorrent-like protocols for several reasons: 1) The innovation rate is the min-cut of all flows from the local node to the source(s), which is likely to be much larger than BitTorrent's default of 4 active connections. 2) BitTorrent transfers pieces in blocks-at-a-time, but only advertises in piece-at-a-time. This injects a significant delay between downloading of an innovative byte and sharing of that byte (on average, one half the download time of an entire piece). Network coding imposes no such delay. 3) There is no first-blocks or last-blocks problem with network coding, they are entirely non-issues. Large portions of your paper are devoted to these issues which simply don't occur under network coding. 4) The meta-network utilization is higher for network coding. That is, since BitTorrent cannot align to the underlying physical connections of the network elements, it is impossible to maximally utilize them. Network coding (using an innovation rate tracking algorithm) can rapidly align to the structure of the physical network, eliminating cross-core retransmissions. This saves a significant amount of ISP bandwidth and reduces the overall burden of supporting filesharing services on the internet. Of course, network coding does have cons also: - Typically larger memory footprint - Typically larger CPU requirements (falling rapidly with new research) - Typically more complex supporting protocols (innovation tracking, security checks, etc) Is the full implementation of Network Coding superior enough to BitTorrent that it offers compelling reasons for migration to it as a solution? Your paper argues that BitTorrent is "good enough", and I tend to agree. Please discuss! :-) --Bryan bryan.turner@pobox.com [1] Network Coding: An Instant Primer - http://infoscience.epfl.ch/search.py?recid=64508 On 5/3/06, Arnaud Legout wrote: > > Hello, > > we have a new paper called "rarest first and choke algorithms are enough" > that is about an experimental evaluation of the two core BitTorrent > algorithms > on real torrents. > > A. Legout, G. Urvoy-Keller, and P. Michiardi. Rarest First and Choke > Algorithms Are Enough. Technical Report > (inria-00001111, version 1 - 13 February 2006), INRIA, Sophia Antipolis, > February 2006. > http://hal.inria.fr/inria-00001111/en > > Comments are welcomed. > > Regards, > Arnaud Legout. > > -- > Arnaud Legout, Ph.D. > > INRIA Sophia Antipolis - Plan?te Phone : 00.33.4.92.38.78.15 > 2004 route des lucioles - BP 93 Fax : 00.33.4.92.38.79.78 > 06902 Sophia Antipolis CEDEX E-mail: arnaud.legout@sophia.inria.fr > FRANCE Web : > http://www-sop.inria.fr/planete/Arnaud.Legout/index.html > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060503/b0e8c616/attachment.html From ryanp at cs.cornell.edu Wed May 3 21:10:39 2006 From: ryanp at cs.cornell.edu (Ryan S. Peterson) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona Message-ID: <44591C4F.50703@cs.cornell.edu> Hello, We're writing to announce Corona, a new system that you can use to monitor websites and RSS feeds through instant messages. Corona is a peer-to-peer publish-subscribe system for the web. You contact Corona via IM and tell it which web pages and RSS feeds you would like to track. Corona nodes periodically poll these web pages, determine if there are any updates, and send the updates to subscribers using short instant messages. You can use Corona to: o monitor blogs: you will get IMs from Corona shortly after your favorite blogs have new content. o track data sources: get an IM whenever there are new torrents posted to your favorite site, when new podcasts are available, or when new stories get posted. You can get to Slashdot stories before anyone else. o keep up with news: subscribe to a news channel (eg CNN) and have the day's breaking news delivered to you as they happen. At its core, Corona employs hundreds of servers distributed geographically around the globe, builds a self-organizing overlay for event monitoring, and performs a distributed mathematical optimization to determine exactly how often to check each feed in order to achieve the lowest update latency given a bandwidth budget. The Corona website: http://www.cs.cornell.edu/people/egs/beehive/corona/ describes the inner workings of the system. To give it a try, simply add "CornellCorona" as your buddy in AIM, YIM, or MSN Messenger. Send it the message "subscribe www.cnn.com CNN" to get started, or give it any other URL you'd like to monitor. To send us feedback, type the word "feedback" followed by anything you'd like to tell us. Type "help" for a complete list of what Corona can do. Corona is a non-commercial project. There are no ads and no malware or other software bundled with it; in fact, no software is installed on your machine at all. It's a totally free service we are running to showcase our research. We hope you find it as useful and addictive as we have. Thank you, Ryan Peterson & the Corona team From solipsis at pitrou.net Wed May 3 23:29:47 2006 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <44591C4F.50703@cs.cornell.edu> References: <44591C4F.50703@cs.cornell.edu> Message-ID: <1146698987.5731.6.camel@fsol> Hi, Le mercredi 03 mai 2006 ? 17:10 -0400, Ryan S. Peterson a ?crit : > We're writing to announce Corona, a new system that you can use > to monitor websites and RSS feeds through instant messages. > > Corona is a peer-to-peer publish-subscribe system for the web. I'm not sure exactly how this is a peer-to-peer system, since there is clearly a conceptual (and actual) distinction between clients and servers. Moreover, end users don't seem to participate in the overlay network at all. Am I mistaken ? Is it "peer-to-peer" in the same way that Akamai is ? (apart from that, trying to solve the "RSS is a resource hog" problem is a good idea ;-)) From ryanp at cs.cornell.edu Thu May 4 02:42:33 2006 From: ryanp at cs.cornell.edu (Ryan S. Peterson) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <1146698987.5731.6.camel@fsol> References: <44591C4F.50703@cs.cornell.edu> <1146698987.5731.6.camel@fsol> Message-ID: <44596A19.1000607@cs.cornell.edu> Hi Antoine, Corona is P2P because of its internal structure: a logical ring of nodes that polls websites and RSS feeds cooperatively, detects updates, and sends the updates to clients. You're right that those nodes do not include the end users. However, the end users reap the benefits of Corona's P2P internals: hundreds of nodes poll sites in a globally optimal manner to get updates to users as fast as possible without overloading the network. Ryan Antoine Pitrou wrote: > Hi, > > Le mercredi 03 mai 2006 ? 17:10 -0400, Ryan S. Peterson a ?crit : > >>We're writing to announce Corona, a new system that you can use >>to monitor websites and RSS feeds through instant messages. >> >>Corona is a peer-to-peer publish-subscribe system for the web. > > > I'm not sure exactly how this is a peer-to-peer system, since there is > clearly a conceptual (and actual) distinction between clients and > servers. > Moreover, end users don't seem to participate in the overlay network at > all. > Am I mistaken ? > Is it "peer-to-peer" in the same way that Akamai is ? > > (apart from that, trying to solve the "RSS is a resource hog" problem is > a good idea ;-)) > > > > _______________________________________________ > 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 wesley at felter.org Wed May 3 22:13:54 2006 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <44591C4F.50703@cs.cornell.edu> References: <44591C4F.50703@cs.cornell.edu> Message-ID: <44592B22.6030509@felter.org> Ryan S. Peterson wrote: > Hello, > > We're writing to announce Corona, a new system that you can use > to monitor websites and RSS feeds through instant messages. What do you think about PubSub and syndication over XMPP? Wes Felter - wesley@felter.org From networksimulator at gmail.com Thu May 4 03:36:16 2006 From: networksimulator at gmail.com (Ranus) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: Message-ID: <000d01c66f2b$ebae8dc0$ccc96fa6@thinkingfish> My thoughts on the two issues Bryan brings: On fairness Both are saying something true. The point is whether the experiments carried out capture any situation that seeders are scarce. But generally I don't think free-riders can be eliminated even with a byte-for-byte fairness heuristic. For example, free-riders contributes nothing, but if their downloading bandwidths are also small (compare with other leechers), the fair share offered by seeders can well saturate this capacity. Also joining peers without any information of the free riders and optimistic unchoking inevitably feed the free riders. [1] tries to replace optimistic unchoking by estimate the bandwidth between peers, how well does this work? I don't know if any better approaches can solve this problem. The good thing is, bitTorrent introduce seeders to provide extra resources. And if we want to prove/disprove the current algorithm is not efficient esp. when uploading capacity is rare, two things should be demonstrated: 1. whether peers can pick up optimal remote downloaders in the neighborhood quickly. 2. If they can do 1, how much performance loss they undertake by the current optimistic unchoking algorithm; if they cannot, how far from optimal do we expect the downloader selection. On Network Coding I am not really familiar with network coding, the only example in P2P I read is "Network Coding for Large Scale Content Distribution" [2]. But network coding often requires a global view or good heuristics on what to generate. In [2], to generate highly needed (innovative in this article) needs communication among the neighbors. Anybody knows some real-world, large-scale P2P system that provides realistic data? Nice article, Arnaud, I think I've read your previous article on BitTorrent months ago. Very solid data, and I'm curious on your methodology in choosing the sessions (as they should be representative). [1] AR Bharambe, C. Herley, and VN Padmanabhan, "Analyzing and. improving bittorrent performance," Technical Report, MSR-TR-2005-03 [2] http://research.microsoft.com/~pablo/papers/nc_contentdist.pdf -- Ranus Yue Tsinghua University _____ From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On Behalf Of Bryan Turner Sent: Thursday, May 04, 2006 1:57 AM To: Peer-to-peer development. Subject: Re: [p2p-hackers] paper "rarest first and choke algorithms are enough" Arnaud, Thanks for the new paper, there is a lot of nice data here. The presented graphs and analysis indeed suggest that the BitTorrent protocol's choices achieve near-optimal data distribution in its paradigm (single file, block-based content distribution). I agree with your suggestions for fairness criteria, and my own suggestions are similar (my suggestion is for a reputation-based system to model leechers and free-riders). However, I disagree with several conclusions you make along the way. A brief overview: - Byte-for-byte fairness is not appropriate - Network Coding is not justified Fairness: I am unconvinced by the arguments against byte-for-byte fairness. Your evidence to support this is that tit-for-tat does not take into account the excess capacity of some torrents (ie: more seeders than leechers). Yet this situation is equivalent under byte-for-byte and choking rules. Leechers are upholding the byte-for-byte policy (seeders cannot, as you mention) and thus only leechers are restricting their upload capacities to free-riders, and rightly so. Seeds (who hold the excess capacity) are distributing this capacity fairly to all peers. Thus, choking and byte-for-byte are equivalent in this regard - free riders receive a share of the bandwidth equal to the fair distribution given by seeders in both cases. The more important case, when excess capacity is not available, free riders should be eliminated or diminished. Because leecher participation cannot be proven, the only other method of measurement is via equal exchange of services. Byte-for-byte is one such measurement (reputation systems are another). In this scenario, free riders will only receive a small credit from the leechers in the swarm before having to resort to hand-outs from the seeds. With the seeds giving fair capacity to the swarm, the free riders will receive very little of the swarm capacity, while the participating leechers will receive fair resources. Free riders always receive more resources under choking than under exchange measurement models. Network Coding: On the topic of Network Coding [1], I did not see any evidence in your paper refuting the network coding literature. Please correct me if I missed it, but it appears your only rebuttal is in the poor modeling of BitTorrent, not in the application of network coding techniques. From this I don't see how you conclude that network coding is not justified? I agree that most of the simulation literature does not model BitTorrent correctly, but this doesn't negate the positive results of the network coding trials, only their comparisons to BitTorrent. In section 4-A, pp 6-7, you suggest that source or network coding may not propose interesting pieces to peers during the startup phase. I counter that this is exactly what network coding solves - every packet has an innovation rate based on the network flows from the local node to the source(s). Assuming a densely connected graph with fair sharing from the seeder, it is unlikely that any packet is not innovative during the startup phase. Unless the local node's bandwidth is many multiples of the seeder, a problem which is not specific to network coding. Network Coding is superior to Rarest First and other BitTorrent-like protocols for several reasons: 1) The innovation rate is the min-cut of all flows from the local node to the source(s), which is likely to be much larger than BitTorrent's default of 4 active connections. 2) BitTorrent transfers pieces in blocks-at-a-time, but only advertises in piece-at-a-time. This injects a significant delay between downloading of an innovative byte and sharing of that byte (on average, one half the download time of an entire piece). Network coding imposes no such delay. 3) There is no first-blocks or last-blocks problem with network coding, they are entirely non-issues. Large portions of your paper are devoted to these issues which simply don't occur under network coding. 4) The meta-network utilization is higher for network coding. That is, since BitTorrent cannot align to the underlying physical connections of the network elements, it is impossible to maximally utilize them. Network coding (using an innovation rate tracking algorithm) can rapidly align to the structure of the physical network, eliminating cross-core retransmissions. This saves a significant amount of ISP bandwidth and reduces the overall burden of supporting filesharing services on the internet. Of course, network coding does have cons also: - Typically larger memory footprint - Typically larger CPU requirements (falling rapidly with new research) - Typically more complex supporting protocols (innovation tracking, security checks, etc) Is the full implementation of Network Coding superior enough to BitTorrent that it offers compelling reasons for migration to it as a solution? Your paper argues that BitTorrent is "good enough", and I tend to agree. Please discuss! :-) --Bryan bryan.turner@pobox.com [1] Network Coding: An Instant Primer - http://infoscience.epfl.ch/search.py?recid=64508 On 5/3/06, Arnaud Legout wrote: Hello, we have a new paper called "rarest first and choke algorithms are enough" that is about an experimental evaluation of the two core BitTorrent algorithms on real torrents. A. Legout, G. Urvoy-Keller, and P. Michiardi. Rarest First and Choke Algorithms Are Enough. Technical Report (inria-00001111, version 1 - 13 February 2006), INRIA, Sophia Antipolis, February 2006. http://hal.inria.fr/inria-00001111/en Comments are welcomed. Regards, Arnaud Legout. -- Arnaud Legout, Ph.D. INRIA Sophia Antipolis - Plan?te Phone : 00.33.4.92.38.78.15 2004 route des lucioles - BP 93 Fax : 00.33.4.92.38.79.78 06902 Sophia Antipolis CEDEX E-mail: arnaud.legout@sophia.inria.fr FRANCE Web : http://www-sop.inria.fr/planete/Arnaud.Legout/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060504/99f4b3ec/attachment.htm From Arnaud.Legout at sophia.inria.fr Thu May 4 09:04:40 2006 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: References: <4458852B.5080300@sophia.inria.fr> Message-ID: <4459C3A8.2060303@sophia.inria.fr> Hi Bryan, first thanks a lot for your comments. I am answering them inline. Bryan Turner wrote: > Arnaud, > > Thanks for the new paper, there is a lot of nice data here. The > presented graphs and analysis indeed suggest that the BitTorrent > protocol's choices achieve near-optimal data distribution in its > paradigm (single file, block-based content distribution). I agree > with your suggestions for fairness criteria, and my own suggestions > are similar (my suggestion is for a reputation-based system to model > leechers and free-riders). the first point I want to make clear is that we place ourselves in the context of P2P file delivery in the current Internet. This context has one important implications: there is a good network connectivity and everybody can discuss with everybody (2 NATed peers cannot communicate with each other directly, but this is not a network issue, this is an end user issue) You will see in the following why this is important. That should be clear in the paper, if it was not tell me so that I can improve the argumentation. > > However, I disagree with several conclusions you make along the > way. A brief overview: > - Byte-for-byte fairness is not appropriate I still claim that in the context of P2P file transfer (see below) > - Network Coding is not justified in our context. Network coding can be a good solution in the context of ad-hoc networks, or in any other network where connectivity is a problem, i.e., when local rarest first does not work optimally. Note, however, that network coding requires significant computing capabilities that a sensor network or an ad hoc network based on basic terminals (e.g., mobile phones) cannot afford for now. There are other scenarios where network coding can help. But, I still claim that in the current Internet and on a representative set of reat torrents we monitored, network coding would not improve the performance significantly enough to be justified. > > Fairness: > > I am unconvinced by the arguments against byte-for-byte fairness. > Your evidence to support this is that tit-for-tat does not take into > account the excess capacity of some torrents (ie: more seeders than > leechers). Yet this situation is equivalent under byte-for-byte and > choking rules. Leechers are upholding the byte-for-byte policy > (seeders cannot, as you mention) and thus only leechers are > restricting their upload capacities to free-riders, and rightly so. > Seeds (who hold the excess capacity) are distributing this capacity > fairly to all peers. Thus, choking and byte-for-byte are equivalent > in this regard - free riders receive a share of the bandwidth equal to > the fair distribution given by seeders in both cases. I am not sure I understand your point. Byte-for-byte (BFB) algorithm and choke algorithm (CA) are far from being equivalent. In all the studies that mention BFB I am aware of, they never mention the case of seeds. They simply say that peers must not receive more than they give. This is the definition of BFB. You can introduce a threshold, but it does not change the main idea and there is no proposed solution to define a dynamic threshold. It is not correct to say that peers must not receive more than they send. As I wrote in the report, leechers have an asymmetric capacity most of the time and seeds offer capacity for free. With BFB you cannot benefit from this excess capacity. The only one solution is to define a dynamic threshold, but this is an optimization problem that is not solved, and I believe to be very hard to solve practically, for no benefit compared to CA. Remember that the main (and single argument) in all the studies that discuss BFB solutions is that free riders can get a high service from a torrent. This problem in all the studies I am aware of comes from the old choke algorithm in seed state that favors fast downloaders. With the new choke algorithm in seed state all the observed unfairness disappear (in the sense of the fairness I define in the paper). > > The more important case, when excess capacity is not available, > free riders should be eliminated or diminished. Because leecher > participation cannot be proven, the only other method of measurement > is via equal exchange of services. Byte-for-byte is one such > measurement (reputation systems are another). In this scenario, free > riders will only receive a small credit from the leechers in the swarm > before having to resort to hand-outs from the seeds. With the seeds > giving fair capacity to the swarm, the free riders will receive very > little of the swarm capacity, while the participating leechers will > receive fair resources. CA gives the same result from our measurements. It guarantees that a peer cannot receive more from a torrent than a peer that contributes more than him. Here again, with BFB we will not use all the capacity of the torrent because it is based on a fairness criterion that is not correct in a P2P architecture. > > Free riders always receive more resources under choking than under > exchange measurement models. and that is fine as long as they do not receive more than someone that contributes. I understand that you argue in favor of global efficiency. It is true that if you do not give anything to free riders, you will have more capacity for the ones that contributes. But it is not clear that they can make use of it, and it is not clear that giving a small service to free riders impact the overall torrent. I have shown a long time ago in the context of multicast that it is possible to define a policy that gives more to multicast users without significantly decreasing the performance of unicast ones. Even if the context is different, I believe that the issue is equivalent. > > Network Coding: > > On the topic of Network Coding [1], I did not see any evidence in > your paper refuting the network coding literature. Please correct me > if I missed it, but it appears your only rebuttal is in the poor > modeling of BitTorrent, not in the application of network coding > techniques. From this I don't see how you conclude that network > coding is not justified? I agree that most of the simulation > literature does not model BitTorrent correctly, but this doesn't > negate the positive results of the network coding trials, only their > comparisons to BitTorrent. That is not my point. We claim that we cannot gain a significant performance improvement using network coding in the context we are studying. As I said at the beginning of this email network coding is undoubtedly useful in a number of situations, not in our context. However, the context we are studying is very important and there are tons of persons believing that they can improve a P2P client for file sharing over the Internet using network coding techniques. This is not true and this is due to a misunderstanding of the dynamics of BitTorrent that I hope the paper help to understand better. > > In section 4-A, pp 6-7, you suggest that source or network coding > may not propose interesting pieces to peers during the startup phase. > I counter that this is exactly what network coding solves - every > packet has an innovation rate based on the network flows from the > local node to the source(s). Assuming a densely connected graph with > fair sharing from the seeder, it is unlikely that any packet is not > innovative during the startup phase. Unless the local node's > bandwidth is many multiples of the seeder, a problem which is not > specific to network coding. You did not get the point. consider a seed with a finite upload capacity C Bytes/s and a file to send of size S Bytes. Then the seed needs in the best case S/C seconds to send the entire content. Whatever coding technique you use you cannot do it faster. We identified that when the performance of a torrent is not optimal, then it is in a transient phase. That means that the seed has not yet sent a copy of each piece. If you use network coding of whatever coding you can imagine, we will not improve that fact that information is missing in the torrent and that is this missing information that causes the decrease in performance. > > Network Coding is superior to Rarest First and other > BitTorrent-like protocols for several reasons: > 1) The innovation rate is the min-cut of all flows from the local node > to the source(s), which is likely to be much larger than BitTorrent's > default of 4 active connections. > 2) BitTorrent transfers pieces in blocks-at-a-time, but only > advertises in piece-at-a-time. This injects a significant delay > between downloading of an innovative byte and sharing of that byte (on > average, one half the download time of an entire piece). Network > coding imposes no such delay. > 3) There is no first-blocks or last-blocks problem with network > coding, they are entirely non-issues. Large portions of your paper > are devoted to these issues which simply don't occur under network coding. > 4) The meta-network utilization is higher for network coding. That > is, since BitTorrent cannot align to the underlying physical > connections of the network elements, it is impossible to maximally > utilize them. Network coding (using an innovation rate tracking > algorithm) can rapidly align to the structure of the physical network, > eliminating cross-core retransmissions. This saves a significant > amount of ISP bandwidth and reduces the overall burden of supporting > filesharing services on the internet. All you say is theory and is true, but the real difference between network coding and rarest first depends on the context. All I can tell you is that measurements show that in the context I am discussing there is not significant differences between network coding and Rarest Fist. > Is the full implementation of Network Coding superior enough to > BitTorrent that it offers compelling reasons for migration to it as a > solution? Your paper argues that BitTorrent is "good enough", and I > tend to agree. I do not believe it makes sense to say that one solution is superior to another one in all cases. In our specific context, the rarest first and choke algorithms are enough, but not superior with respect to performance. But they are much simpler. In other contexts Network Coding will be superior. The point of the paper is to show which kind of performance we can achieve using rarest first and choke algorithms, and to stop legends that say that there is always last pieces problems problems or fairness issues. These legends, as we show with the notion of transient phase, are due to a misunderstanding of the very complex dynamics of P2P protocols. Regards, Arnaud. From Arnaud.Legout at sophia.inria.fr Thu May 4 10:32:00 2006 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: <000d01c66f2b$ebae8dc0$ccc96fa6@thinkingfish> References: <000d01c66f2b$ebae8dc0$ccc96fa6@thinkingfish> Message-ID: <4459D820.4050709@sophia.inria.fr> Hi, Ranus wrote: > My thoughts on the two issues Bryan brings: > On fairness > Both are saying something true. The point is whether the experiments > carried out capture any situation that seeders are scarce. yes. You can see in the paper that there are torrents with 0 or only 1 seed. > But generally I don't think free-riders can be eliminated even with a > byte-for-byte fairness heuristic. For example, free-riders contributes > nothing, but if their downloading bandwidths are also small (compare > with other leechers), the fair share offered by seeders can well > saturate this capacity. Also joining peers without any information of > the free riders and optimistic unchoking inevitably feed the free > riders. [1] tries to replace optimistic unchoking by estimate the > bandwidth between peers, how well does this work? I don't know if any > better approaches can solve this problem. Ashwin Bharambe et al. [1] did a very nice study on BitTorrent. We agree on several points, even if we used a different methodology (simulations versus experimentations). However, the results on fairness (that justify the proposed policies) was performed with the old choke algorithm in seed state. With the new choke algorithm in seed state, I do not believe the problems to hold. > The good thing is, bitTorrent introduce seeders to provide extra > resources. And if we want to prove/disprove the current algorithm is > not efficient esp. when uploading capacity is rare, two things should > be demonstrated: > 1. whether peers can pick up optimal remote downloaders in the > neighborhood quickly. > 2. If they can do 1, how much performance loss they undertake by the > current optimistic unchoking algorithm; if they cannot, how far from > optimal do we expect the downloader selection. You are right, but this is an extremely complex problem to model. > On Network Coding > I am not really familiar with network coding, the only example in P2P > I read is "Network Coding for Large Scale Content Distribution" [2]. > But network coding often requires a global view or good heuristics on > what to generate. In [2], to generate highly needed (innovative in > this article) needs communication among the neighbors. Anybody knows > some real-world, large-scale P2P system that provides realistic data? Network coding does not require a global view of the network, you simply always generate new blocks of data as a linear combination of all the blocks you have. You choose the coefficient randomly and send them with the block. I simplify a lot, of course, but this is the idea. Thanks a lot for the comments, Arnaud. From agthorr at cs.uoregon.edu Thu May 4 13:21:00 2006 From: agthorr at cs.uoregon.edu (Daniel Stutzbach) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: <4459C3A8.2060303@sophia.inria.fr> References: <4458852B.5080300@sophia.inria.fr> <4459C3A8.2060303@sophia.inria.fr> Message-ID: <20060504132059.GE1660@cs.uoregon.edu> On Thu, May 04, 2006 at 11:04:40AM +0200, Arnaud Legout wrote: > We identified that when the performance of a torrent is not optimal, > then it is in a transient phase. That means that the seed has not yet > sent a copy of each piece. If you use network coding of whatever coding > you can imagine, we will not improve that fact that information is missing > in the torrent and that is this missing information that causes the > decrease in performance. Coding may be able to recover the missing information more quickly when the system is in a transient phase. I can think of two scenarios where this may occur: 1) Early in the life of the torrent when the seed has uploaded each piece only once or twice. However, due to the fact that many users abort their downloads, some of these uploaded pieces will be missing and the seed does not know which pieces were reproduced into the rest of the system and which were not. Coding may allow the system to get out of the transient phase more rapidly since the seed does not risk uploading redundant information. 2) Late in the life of the torrent when all the seeds have departed. Coding improves the probability that the set of remaining peers have enough information among themselves to reproduce the whole file (and become new seeds), thus extending the life of the torrent. -- Daniel Stutzbach Computer Science Ph.D Student http://www.barsoom.org/~agthorr University of Oregon From bob.harris.spamcontrol at gmail.com Thu May 4 14:45:45 2006 From: bob.harris.spamcontrol at gmail.com (Bob Harris) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: <20060504132059.GE1660@cs.uoregon.edu> References: <4458852B.5080300@sophia.inria.fr> <4459C3A8.2060303@sophia.inria.fr> <20060504132059.GE1660@cs.uoregon.edu> Message-ID: Personally, I don't get these "X is enough, no need for Y" claims for software (X = bittorrent as is, Y = coding in this case). If you can have X _and_ Y, that's clearly better than X. Someone else is going to implement Y, and they'll do it just once, so it's no skin off of anyone's back. The two cases mentioned below (even though they are not in steady state) seem like ample justification for coding. Bob On 5/4/06, Daniel Stutzbach wrote: > > On Thu, May 04, 2006 at 11:04:40AM +0200, Arnaud Legout wrote: > > We identified that when the performance of a torrent is not optimal, > > then it is in a transient phase. That means that the seed has not yet > > sent a copy of each piece. If you use network coding of whatever coding > > you can imagine, we will not improve that fact that information is > missing > > in the torrent and that is this missing information that causes the > > decrease in performance. > > Coding may be able to recover the missing information more quickly > when the system is in a transient phase. I can think of two scenarios > where this may occur: > > 1) Early in the life of the torrent when the seed has uploaded each > piece only once or twice. However, due to the fact that many users > abort their downloads, some of these uploaded pieces will be > missing and the seed does not know which pieces were reproduced > into the rest of the system and which were not. Coding > may allow the system to get out of the transient phase more rapidly > since the seed does not risk uploading redundant information. > > 2) Late in the life of the torrent when all the seeds have departed. > Coding improves the probability that the set of remaining > peers have enough information among themselves to reproduce the > whole file (and become new seeds), thus extending the life of the > torrent. > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060504/7b953d67/attachment.html From bob.harris.spamcontrol at gmail.com Thu May 4 14:49:40 2006 From: bob.harris.spamcontrol at gmail.com (Bob Harris) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <44591C4F.50703@cs.cornell.edu> References: <44591C4F.50703@cs.cornell.edu> Message-ID: Nice, something new! About time someone fixed RSS! Bob On 5/3/06, Ryan S. Peterson wrote: > > Hello, > > We're writing to announce Corona, a new system that you can use > to monitor websites and RSS feeds through instant messages. > > Corona is a peer-to-peer publish-subscribe system for the web. > You contact Corona via IM and tell it which web pages and RSS > feeds you would like to track. Corona nodes periodically poll these > web pages, determine if there are any updates, and send the updates > to subscribers using short instant messages. You can use Corona to: > o monitor blogs: you will get IMs from Corona shortly after > your favorite blogs have new content. > o track data sources: get an IM whenever there are new > torrents posted to your favorite site, when new podcasts > are available, or when new stories get posted. You can > get to Slashdot stories before anyone else. > o keep up with news: subscribe to a news channel (eg CNN) > and have the day's breaking news delivered to you as they > happen. > > At its core, Corona employs hundreds of servers distributed > geographically around the globe, builds a self-organizing > overlay for event monitoring, and performs a distributed > mathematical optimization to determine exactly how often > to check each feed in order to achieve the lowest > update latency given a bandwidth budget. The Corona website: > http://www.cs.cornell.edu/people/egs/beehive/corona/ > describes the inner workings of the system. > > To give it a try, simply add "CornellCorona" as your buddy in AIM, > YIM, or MSN Messenger. Send it the message "subscribe www.cnn.com CNN" > to get started, or give it any other URL you'd like to monitor. To send > us feedback, type the word "feedback" followed by anything you'd like > to tell us. Type "help" for a complete list of what Corona can do. > > Corona is a non-commercial project. There are no ads and no malware or > other software bundled with it; in fact, no software is installed on > your machine at all. It's a totally free service we are running to > showcase our research. We hope you find it as useful and addictive as > we have. > > Thank you, > Ryan Peterson & the Corona team > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060504/76baf3bc/attachment.htm From solipsis at pitrou.net Thu May 4 15:20:13 2006 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: References: <44591C4F.50703@cs.cornell.edu> Message-ID: <1146756014.5734.36.camel@fsol> Le jeudi 04 mai 2006 ? 10:49 -0400, Bob Harris a ?crit : > Nice, something new! About time someone fixed RSS! The obvious "fix" was really to use subscribe-by-email or subscribe-by-IM, with the original Web site sending notifications to subscribed users. But apparently lots of people want to build layers of cruft instead of this simple scheme ;-)) SMTP probably isn't hype enough, and e-mail is so boooring ("look I have a blog, and you can even read it with RSS!"). From jrydberg at gnu.org Thu May 4 15:38:58 2006 From: jrydberg at gnu.org (Johan Rydberg) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: (Bob Harris's message of "Thu, 4 May 2006 10:49:40 -0400") References: <44591C4F.50703@cs.cornell.edu> Message-ID: <87ejz9ajfx.fsf@night.trouble.net> "Bob Harris" writes: > Nice, something new! About time someone fixed RSS! FeedTree brings news feed updates to users, instead of the other way around. FeedTree users work together to share the latest Web feed updates. News arrives immediately, instead of on a polling schedule, making RSS as instantaneous as e-mail. http://feedtree.net/ ~j From solipsis at pitrou.net Thu May 4 16:15:17 2006 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <87ejz9ajfx.fsf@night.trouble.net> References: <44591C4F.50703@cs.cornell.edu> <87ejz9ajfx.fsf@night.trouble.net> Message-ID: <1146759318.5734.38.camel@fsol> Le jeudi 04 mai 2006 ? 17:38 +0200, Johan Rydberg a ?crit : > News arrives immediately, instead of on a polling schedule, > making RSS as instantaneous as e-mail. Yet another proof of what I was saying in my previous post ;-)) From Arnaud.Legout at sophia.inria.fr Thu May 4 16:30:10 2006 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: <20060504132059.GE1660@cs.uoregon.edu> References: <4458852B.5080300@sophia.inria.fr> <4459C3A8.2060303@sophia.inria.fr> <20060504132059.GE1660@cs.uoregon.edu> Message-ID: <445A2C12.8040800@sophia.inria.fr> Hi Daniel, I do agree with you, but what you are talking about is more related to torrent survivability than to the torrent regular operation. I see a torrent as a way to transmit to a large audience a popular content. If this is not the case then it makes more sense to use a client server architecture. A good way to guarantee the torrent survivability is to mix a client server architecture with a BitTorrent file transfer. This is not the solution to everything, but at least it is simple and efficient. Regards, Arnaud. From Arnaud.Legout at sophia.inria.fr Thu May 4 16:49:08 2006 From: Arnaud.Legout at sophia.inria.fr (Arnaud Legout) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: References: <4458852B.5080300@sophia.inria.fr> <4459C3A8.2060303@sophia.inria.fr> <20060504132059.GE1660@cs.uoregon.edu> Message-ID: <445A3084.1080508@sophia.inria.fr> Hello Bob, Bob Harris wrote: > Personally, I don't get these "X is enough, no need for Y" > claims for software I am not not talking about software, I am talking about algorithms. I do not want to refrain anybody to implement a P2P client based on network coding. I am simply providing new information on the dynamics of the rarest first and choke algorithms and I point out misunderstanding on the dynamics of these algorithms. If you want to implement a P2P file transfer client based on network coding go ahead. That would be nice to have a real client that can be experimentally compared to BT. > back. The two cases mentioned below (even though they are not > in steady state) seem like ample justification for coding. Yes, there are tons of justifications to implement a client based on network coding. Regards, Arnaud. From mfreed at cs.nyu.edu Thu May 4 17:45:11 2006 From: mfreed at cs.nyu.edu (Michael J Freedman) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] CFP: Workshop on Real, Large Distributed Systems Message-ID: Hi p2p-hackers, This year's WORLDS conference just released its call-for-papers. As many members of this list are actively building or otherwise involved with "real, large distributed systems", the workshop is a great fit for our community. So, please consider submitting your real, experimental systems--the systems themselves, position papers, analysis, or lessons learned--to WORLDS this year. Submissions should be at most 5 pages in length and are due July 7. --mike -------------------------- WORLDS '06 Call for Papers 3rd Workshop on Real, Large Distributed Systems (WORLDS '06) November 5, 2006 Seattle, WA, USA Sponsored by USENIX, the Advanced Computing Systems Association Co-located with the 7th Symposium on Operating Systems Design and Implementation (OSDI '06), which takes place November 6-8, 2006. Important Dates Paper submissions due: July 7, 2006, 11:59 p.m. PDT Notification to authors: August 8, 2006 Demo submissions due: September 7, 2006 Final papers due: September 8, 2006 Workshop Organizers Program Co-Chairs David Andersen, Carnegie Mellon University Neil Spring, University of Maryland Preliminary Program Committee Mike Afergan, Akamai Mike Dahlin, University of Texas, Austin Marc Fiuczynski, Princeton University Michael Freedman, New York University Krishna Gummadi, Max Planck Institute for Software Systems Dina Katabi, Massachusetts Institute of Technology Jay Lepreau, University of Utah Dan Rubenstein, Columbia University Martin Swany, University of Delaware Matt Welsh, Harvard University Janet Wiener, Hewlett-Packard Ming Zhang, Microsoft Research Workshop Overview The 3rd Workshop on Real, Large Distributed Systems will bring together people who are exploring the new challenges of building widely distributed networked systems and who lean toward the "rough consensus and running code" school of systems building. WORLDS is a place to share new ideas, experiences, and work in progress, with an emphasis on systems that actually run in the wide area and the specific challenges they present for designers and researchers. Workshop means the emphasis is on focused, fresh ideas and experience. Talks will be short (about 15 minutes long) to leave plenty of time for general discussion. Attendance will consist of contributors to the workshop and a subset of the OSDI attendees, with the number of non-contributors limited to encourage lively discussion between the participants. Real means that the workshop will concentrate on systems designed to run on a real platform for a period of time. Such systems might be research projects, teaching exercises, or more permanent services, but they should address technical issues of actual widely distributed systems. We also welcome papers that explore the extent to which results obtained from simulation or testbed deployments retain validity when transferred to more representative network environments. Large refers to the numerical and geographical dimensions of the system: WORLDS emphasizes distributed systems that span a significant portion of the globe and are spread over a large number of sites. Submitting a Paper Submissions should be at most 5 U.S. letter pages long, two-column format, using 10-point type on 12-point (single-spaced) leading within a 6.5" x 9" text block. Participants will be invited based on their ability to convince the program committee that they have built, are building, or are experimenting with a Real, Large Distributed System and have useful ideas, tools, experience, data, or research directions to share with the community that will stimulate discussion at the workshop. Submit your paper via the Web form, which will be available here soon. Online copies of the position papers will be made available before the workshop to registered attendees and will be added to the USENIX proceedings library after the workshop. Participants may update their papers to incorporate workshop feedback. USENIX policy on simultaneous paper submission: Simultaneous submission of the same work to multiple venues, submission of previously published work, and plagiarism constitute dishonesty or fraud. USENIX, like other scientific and technical conferences and journals, prohibits these practices and may, on the recommendation of a program chair, take action against authors who have committed them. In some cases, program committees may share information about submitted papers with other conference chairs and journal editors to ensure the integrity of papers under consideration. If a violation of these principles is found, sanctions may include, but are not limited to, barring the authors from submitting to or participating in USENIX conferences for a set period, contacting the authors' institutions, and publicizing the details of the case. Authors uncertain whether their submission meets USENIX's guidelines should contact the program chairs, worlds06chairs@usenix.org, or the USENIX office, submissionspolicy@usenix.org. Demo Session This year, WORLDS will again feature a demo session in which researchers will have the opportunity to demonstrate the real, running distributed systems they have built. Authors who have their full 5-page workshop papers accepted will automatically be granted the opportunity to present a demo. Others who wish to present a demo should submit a single-page demo description that (a) concretely describes the research problem solved by the system to be demonstrated and (b) concretely describes what will be shown at the demo. Submit your demo via the Web form, which will be available here soon. Awards We expect to offer both a best paper award and a best demo award. From wesley at felter.org Fri May 5 00:18:07 2006 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <1146756014.5734.36.camel@fsol> References: <44591C4F.50703@cs.cornell.edu> <1146756014.5734.36.camel@fsol> Message-ID: <2A315780-CFE7-4E2B-822D-AAAE7EF4A953@felter.org> On May 4, 2006, at 10:20 AM, Antoine Pitrou wrote: > Le jeudi 04 mai 2006 ? 10:49 -0400, Bob Harris a ?crit : >> Nice, something new! About time someone fixed RSS! > > The obvious "fix" was really to use subscribe-by-email or > subscribe-by-IM, with the original Web site sending notifications to > subscribed users. This would only reduce bandwidth to O(N) for N subscribers, which many people don't consider to be a fix. Only systems like FeedTree and Corona provide fanout to potentially reduce the bandwidth to O(1). Wes Felter - wesley@felter.org - http://felter.org/wesley/ From solipsis at pitrou.net Fri May 5 10:36:14 2006 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <2A315780-CFE7-4E2B-822D-AAAE7EF4A953@felter.org> References: <44591C4F.50703@cs.cornell.edu> <1146756014.5734.36.camel@fsol> <2A315780-CFE7-4E2B-822D-AAAE7EF4A953@felter.org> Message-ID: <1146825374.5655.7.camel@fsol> Le jeudi 04 mai 2006 ? 19:18 -0500, Wes Felter a ?crit : > Only systems like FeedTree > and Corona provide fanout to potentially reduce the bandwidth to O(1). Really? I don't know how you can achieve O(1) given you still have to send an individual message to each of the N subscribers. It's mathematically unlikely, to say the least... Or maybe it's a special kind of O(1). ;-) From wesley at felter.org Fri May 5 14:32:07 2006 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <1146825374.5655.7.camel@fsol> References: <44591C4F.50703@cs.cornell.edu> <1146756014.5734.36.camel@fsol> <2A315780-CFE7-4E2B-822D-AAAE7EF4A953@felter.org> <1146825374.5655.7.camel@fsol> Message-ID: <445B61E7.7010803@felter.org> Antoine Pitrou wrote: > Le jeudi 04 mai 2006 ? 19:18 -0500, Wes Felter a ?crit : >> Only systems like FeedTree >> and Corona provide fanout to potentially reduce the bandwidth to O(1). > > Really? I don't know how you can achieve O(1) given you still have to > send an individual message to each of the N subscribers. It's > mathematically unlikely, to say the least... Sorry, what I meant to say was O(1) bandwidth at the publisher. Obviously the bandwidth at the subscribers is O(N). Wes Felter - wesley@felter.org From m.rogers at cs.ucl.ac.uk Fri May 5 15:46:16 2006 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] paper "rarest first and choke algorithms are enough" In-Reply-To: <4459C3A8.2060303@sophia.inria.fr> References: <4458852B.5080300@sophia.inria.fr> <4459C3A8.2060303@sophia.inria.fr> Message-ID: <445B7348.1070008@cs.ucl.ac.uk> Arnaud Legout wrote: > Byte-for-byte (BFB) algorithm and choke algorithm (CA) are far from > being equivalent. > In all the studies that mention BFB I am aware of, they never mention > the case of seeds. They simply say that peers must not receive more than > they give. > This is the definition of BFB. You can introduce a threshold, but it > does not change the main idea and there is no proposed solution > to define a dynamic threshold. It seems to me that you're comparing apples to oranges if you assume that byte-for-byte fairness between downloaders means there can't be any seeds. Specifying different behaviours for downloaders and seeds - as the choke algorithm does - wouldn't require a dynamic threshold. SWIFT is a mechanism that uses approximate byte-for-byte fairness between downloaders while assuming that seeds will upload to anyone: http://mnl.cs.stonybrook.edu/home/vinay/papers/swift-p2pecon.pdf Cheers, Michael From ryanp at cs.cornell.edu Fri May 5 18:33:48 2006 From: ryanp at cs.cornell.edu (Ryan S. Peterson) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Corona In-Reply-To: <44592B22.6030509@felter.org> References: <44591C4F.50703@cs.cornell.edu> <44592B22.6030509@felter.org> Message-ID: <445B9A8C.7030506@cs.cornell.edu> Hi Wes, Using XMPP as a standard chat/presence protocol would be great for something like Corona and pubsub in general. The specific protocol used for sending updates to users is not central to Corona's operation, but having a standard, open protocol for sending updates to users could separate such systems from the limitations imposed by commercial chat protocols. Ryan Wes Felter wrote: > Ryan S. Peterson wrote: > >> Hello, >> >> We're writing to announce Corona, a new system that you can use >> to monitor websites and RSS feeds through instant messages. > > > What do you think about PubSub and syndication over XMPP? > > Wes Felter - wesley@felter.org > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences From ash at wiredreach.com Sat May 6 14:09:45 2006 From: ash at wiredreach.com (Ash Maurya) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud Message-ID: Hi all, Wanted to share a new service we just launched called BoxCloud: A dead simple way to share files with people you know. The part we are really excited about is the ability to share files with others right from your desktop but have them view them over a browser - with no additional software required. We strongly believe blurring the boundaries between the desktop and the web (User Centric Web or P2PWeb) needs to happen and creates more interesting opportunities for mash-ups. Head on over to http://www.boxcloud.com if you are interested... Regards, Ash --- Founder, WiredReach company: http://www.wiredreach.com weblog: http://www.wiredjournal.com From sback at sback.it Sat May 6 15:01:03 2006 From: sback at sback.it (Sback) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: References: Message-ID: <445CBA2F.7000601@sback.it> Ash Maurya wrote: > Hi all, > > Wanted to share a new service we just launched called BoxCloud: A dead > simple way to share files with people you know. > > The part we are really excited about is the ability to share files > with others right from your desktop but have them view them over a > browser - with no additional software required. We strongly believe > blurring the boundaries between the desktop and the web (User Centric > Web or P2PWeb) needs to happen and creates more interesting > opportunities for mash-ups. Head on over to http://www.boxcloud.com if > you are interested... Nice! But... what about source code? I think hackers are interested in software but more in source code. Bye, Sback From ash at wiredreach.com Sat May 6 15:34:07 2006 From: ash at wiredreach.com (Ash Maurya) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: <445CBA2F.7000601@sback.it> References: <445CBA2F.7000601@sback.it> Message-ID: <2F79EA6A-F1EF-4CAE-9C5C-C52934B8FCED@wiredreach.com> Should have mentioned that BoxCloud is a WiredReach application which is open source. Ash On May 6, 2006, at 10:01 AM, Sback wrote: > Ash Maurya wrote: >> Hi all, >> >> Wanted to share a new service we just launched called BoxCloud: A >> dead simple way to share files with people you know. >> >> The part we are really excited about is the ability to share files >> with others right from your desktop but have them view them over a >> browser - with no additional software required. We strongly >> believe blurring the boundaries between the desktop and the web >> (User Centric Web or P2PWeb) needs to happen and creates more >> interesting opportunities for mash-ups. Head on over to http:// >> www.boxcloud.com if you are interested... > Nice! But... what about source code? I think hackers are interested > in software but more in source code. > > Bye, > Sback > _______________________________________________ > 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 dmolnar at gmail.com Sat May 6 20:46:40 2006 From: dmolnar at gmail.com (David Molnar) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Call for Papers: WPES 2006 Message-ID: <3ad50dea0605061346w430d3648gb7e444f32d5bfdee@mail.gmail.com> Hey everyone, The 2006 Workshop on Privacy in the Electronic Society (WPES) is looking for papers. Over the last few years, WPES has seen a wide variety of contributions, covering technical, legal, and social aspects of electronic privacy. We're pretty sure p2p-hackers, or people known by p2p-hackers, will have something to say here, so we're soliciting you all to say it to us! Deadline: 2 June 2006 Where: Alexandria, Virginia, USA When: 30 October 2006 More info, including the full call for papers & (eventually) how to submit: http://www.freehaven.net/wpes2006/index.html -David Molnar (Disclosure: program committee member) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060506/a5e38e02/attachment.html From greg at capepaterson.com Sun May 7 23:45:56 2006 From: greg at capepaterson.com (Greg Rolan) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Real-world UPnP stats In-Reply-To: <444D1F47.1070905@hamachi.cc> References: <444D1F47.1070905@hamachi.cc> Message-ID: <445E86B4.3010601@capepaterson.com> Hi Alex, Maybe I'm telling you something you already know, so forgive me if this is obvious to you - but it's recently new to me. I've been using the sbbi-upnplib (www.sbbi.net) to provide uPnP support for our client and hit a problem whereby our office DSL router would return 200's etc. but would not actually map ports or return valid data for the external address etc. This was odd as the software worked for other devices we had tested on. After some debugging & tracing with the sbbi guy we solved the issue. It turns out that this router advertises both an IP device and a PPP device, and while both devices advertise the requisite WAN services and respond correctly to the requests, it is only the PPP device that actually services the requests (and our code only used the IP device by default). Depending on how you have coded the uPnP support this may be part of the issue. Anyway, if this is new to you, I hope it helps. regards, Greg. > We've recently added UPnP support to our client software and > now I got some server-side stats and they are most interesting. > > Check this out - > > Roughly a half of all clients that reported success talking to > their 'routers' and establishing TCP/UDP port mappings were > still inaccessible from an outside via their mapped ports. > > Our UPnP code is written from scratch, so if the client says that > ports are mapped, there was in fact a 200 response for respective > SOAP request from the router. > > I was expecting some degree of failures due to double NAT'ing, > additional firewalling, etc .. but 50% ? > > Anyone care to comment or compare this to their own numbers ? > > Alex > > > _______________________________________________ > 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 > > -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.392 / Virus Database: 268.5.5/333 - Release Date: 5/5/2006 From adam at cypherspace.org Mon May 8 00:19:09 2006 From: adam at cypherspace.org (Adam Back) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] avoiding uplink saturation / co-existing with other apps? Message-ID: <20060508001909.GA15626@bitchcake.off.net> Hi I believe this problem affects many p2p clients particularly on asymmetric DSL links: - the uplink becomes saturated with the following negative implications: - tcp ack flow-control packets acknowledging data coming down to the the relatively unused downlink suffer congestion due to the saturated downlink, consequently tcp performance for the downlink degrades even though there is spare bandwidth. - the link becomes unusable for the predominantly download focussed (small requests large responses) other protocols the users apps are using: http, pop etc. Is this something one should be worrying about, or will tcp "take care of it" gracefully? It seemed to me that at least for a while bittorrent suffered from this problem. Anyone have a tried and tested algorithm/method to address this? Like auto-detecting and backing off a bit? Some p2p apps ask the user what bandwidth they'd like to allow and then bandwidth limit to that rate. However I think this is not ideal because: - many users wont know what their uplink speed is - if you are not using your link perhaps you'd like to let the p2p app take over - if you do what to use the link for other purposes (web browsing, mail) you probably want this app to take precedence over the p2p app -- providing services to other users. I did see some earlier discussion of UDP based flow control protocols "playing well with TCP" being discussed for non-TCP based apps -- where the hope was that the UDP flow control would be designed such that TCP had precedence. However for people who are using TCP for the p2p app that doesnt help. Generally what you'd like I think is QoS and to give the p2p app "bulk" precedence for other peoples traffic. Comments, things others have tried, info about how well that worked? Adam From ardagna at dti.unimi.it Mon May 8 07:13:23 2006 From: ardagna at dti.unimi.it (Claudio Ardagna) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] CFP - LAST REMINDER: 2ND INTERNATIONAL WORKSHOP ON SECURITY AND TRUST MANAGEMENT (STM'06) Message-ID: <010901c6726e$e4efd610$1e00000a@Berlino> [Apologies if you receive multiple copies of this message] CALL FOR PAPERS *********************************************************************************************** 2ND INTERNATIONAL WORKSHOP ON SECURITY AND TRUST MANAGEMENT (STM'06) Hamburg,Germany - September 20, 2006 (in conjunction with ESORICS 2006) http://www.hec.unil.ch/STM06/ *********************************************************************************************** STM (Security and Trust Management) is a recently established working group of ERCIM (European Research Consortium in Informatics and Mathematics). STM 2006 is the second workshop in this series, and has the following aims: - to investigate the foundations and applications of security and trust in ICT - to study the deep interplay between trust management and common security issues such as confidentiality, integrity and availability - to identify and promote new areas of research connected with security management, e.g. dynamic and mobile coalition management (e.g., P2P, MANETs, Web/GRID services) - to identify and promote new areas of research connected with trust management, e.g. reputation, recommendation, collaboration etc - to provide a platform for presenting and discussing emerging ideas and trends Topics of interest include but are not limited to: - semantics and computational models for security and trust - security and trust management architectures, mechanisms and policies - networked systems security - privacy and anonymity - Identity management - ICT for securing digital as well as physical assets - cryptography The primary focus is on high-quality original unpublished research, case studies, and implementation experiences. We encourage submissions discussing the application and deployment of security technologies in practice. Paper submissions. Submitted papers must not substantially overlap papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers must have authors' affiliation and contact information on the first page. Papers are limited to 12 pages in ENTCS style format (using the generic template). Excessively long papers will be returned without review. Accepted papers will be published in a post-workshop ENTCS volume. To submit a paper, please visit http://www.easychair.org/STM06/ . For more information contact stm06@dti.unimi.it Papers must be received by the deadline of May 15, 2006. IMPORTANT DATES Paper submission due: May 15, 2006 Acceptance notification: June 26, 2006 Final Papers due: August 20, 2006 GENERAL CHAIRS Solange Ghernaouti H?lie Univ. Lausanne, CH email: sgh@unil.ch Ulrich Ultes-Nitsche Univ. Fribourg, CH email: uun@unifr.ch PROGRAM CO-CHAIRS Sandro Etalle University of Twente, NL email: sandro.etalle@utwente.nl Pierangela Samarati Universita' di Milano - Italy email: samarati@dti.unimi.it PUBLICATION CHAIR Sara Foresti Universita' di Milano - Italy email: foresti@dti.unimi.it PUBLICITY CHAIR Claudio A. Ardagna Universita' di Milano - Italy email: ardagna@dti.unimi.it PROGRAM COMMITTEE: Viajy Atluri, Rutgers Univ., USA Joris Claessens, Microsoft EMIC, DE Sabrina De Capitani di Vimercati, Univ. Milano, IT Theo Dimitrakos, British Telecom, UK Mara Isabel Gonz?lez Vasco, Univ. Rey Juan Carlos, SP Stefanos Gritzalis, Univ. of Aegean, GR Peter Herrmann, NTNU, NO Valerie Issarny, INRIA, FR Guenter Karjoth, IBM Research, CH Antonio Lioy, Politecnico di Torino, IT Javier Lopez, Univ. Malaga, SP Fabio Martinelli, IIT-CNR, IT Sjouke Mauw, Technical Univ. Eindhoven, NL Daniel Olmedilla, L3S, GR Babak Sadighi, SICS, SE Luca Vigano', ETH Zurich, CH Will Winsborough, Univ. Texas at S. Antonio, USA Ting Yu, North Carolina State Univ., USA Alec Yasinsac, Florida State Univ., USA This call for papers and additional information about the conference can be found at http://www.hec.unil.ch/STM06 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060508/565d1ba9/attachment.htm From coderman at gmail.com Mon May 8 09:35:39 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] avoiding uplink saturation / co-existing with other apps? In-Reply-To: <20060508001909.GA15626@bitchcake.off.net> References: <20060508001909.GA15626@bitchcake.off.net> Message-ID: <4ef5fec60605080235l7384999dv2f309237142cab9b@mail.gmail.com> On 5/7/06, Adam Back wrote: > ... > Is this something one should be worrying about, or will tcp "take care > of it" gracefully? unless the application performs throttling in userspace (which is often poor; tricks like send/recv buffer sizing, nagle, etc can be used to improve accuracy) the TCP stack will try and optimize across all tcp sessions fairly. when many concurrent recv streams are active this implies not only latency and low bandwidth per stream but also likely invokes queuing at the DSL/cable ISP which can be as high as 2 seconds round trip. [this is a highly simplified example but common] overall your link is being well used, but per application / tcp session throughput is sluggish and constrained. > It seemed to me that at least for a while bittorrent suffered from > this problem. losing your ssh / vpn session in a flood of bittorrent neighbors is definitely painful without shaping. :) > Anyone have a tried and tested algorithm/method to address this? traffic shaping in kernel / upstream before the ISP works best in my experience but does require a decent kernel (linux/bsd/*nix/cisco/*) for shaping at your host/router. if you need to rely on throttling at the application layer the use of small send buffers and disabled nagle gives you better consistency/accuracy when writing data at a regular interval on the socket. there are variations on this theme like LD_PRELOAD override of socket api and DiffServ/DSCP tagging which have their own particular strengths. > Generally what you'd like I think is QoS and to give the p2p app > "bulk" precedence for other peoples traffic. i suppose this is an open ended question (the ideal distribution of bandwidth among services on a link) but the following is my favorite configuration: - shape egress traffic such that buffering latency is avoided upstream to ISP - prioritize interactive traffic (ssh, not scp; vpn; rtp; chat; etc) - group bulk traffic into classes (p2p, backup, ftp, torrent, ?) utilizing spare capacity above an optional minimum throughput - leave large packets and other unclassified payload in a middle / unprioritized queue. i prefer iptables classifiers with the MARK target which is used by tc to configure the shaped queues and thresholds associated with each MARK. regarding user interaction, i'd love to see a learning mode applied to common/conservative traffic classification and shaping so that real world link capability as monitored over time was used to set more relevant thresholds / classification. this has the same limitations as explicit shaping but would be much more usable and let p2p / network application clients focus on features instead of poor traffic heuristics. you can find specific examples of "traffic shaping" for p2p in the archives and via google. citeseer has a huge number of papers on these subjects as well. From dbarrett at quinthar.com Tue May 9 05:28:38 2006 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: Message-ID: <20060509054031.53BB03FC59@capsicum.zgp.org> Looks very cool! Can you give a quick overview of how it works? I see you have Mac, Win, and (soon) Linux ports. Are you using Java, or what language? You have some servers in place, clearly, to send out emails and manage the webserver. Do you use these servers as a central rendezvous service, or do you have some DHT to connect peers? What other neat things are going on under the hood? -david > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > Behalf Of Ash Maurya > Sent: Saturday, May 06, 2006 7:10 AM > To: Peer-to-peer development. > Subject: [p2p-hackers] Introducing BoxCloud > > Hi all, > > Wanted to share a new service we just launched called BoxCloud: A > dead simple way to share files with people you know. > > The part we are really excited about is the ability to share files > with others right from your desktop but have them view them over a > browser - with no additional software required. We strongly believe > blurring the boundaries between the desktop and the web (User Centric > Web or P2PWeb) needs to happen and creates more interesting > opportunities for mash-ups. Head on over to http://www.boxcloud.com > if you are interested... > > Regards, > > Ash > --- > Founder, WiredReach > company: http://www.wiredreach.com > weblog: http://www.wiredjournal.com > _______________________________________________ > 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 bayardo at alum.mit.edu Tue May 9 06:53:48 2006 From: bayardo at alum.mit.edu (Roberto Bayardo) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: <20060509054031.53BB03FC59@capsicum.zgp.org> References: <20060509054031.53BB03FC59@capsicum.zgp.org> Message-ID: <93a05d860605082353i2ac80072q1ed4aeba3655feec@mail.gmail.com> You guys should really integrate this with IM instead of e-mail. Since the user has to be online to support the transfer, e-mail doesn't seem to be the best delivery mechanism for your notifications. We did this a while back in YouServ with the "SecureLink" plugin: http://www.bayardo.org/ps/www2005_2.pdf. Unfortunately I could never get it outside the confines of IBM. Sounds like BoxCloud is a very similar idea, only using a centralized server to always act as a trusted relay. I guess you're hoping the adsense clicks will allow you to recoup the bandwidth costs? On 5/8/06, David Barrett wrote: > Looks very cool! Can you give a quick overview of how it works? > > I see you have Mac, Win, and (soon) Linux ports. Are you using Java, or > what language? > > You have some servers in place, clearly, to send out emails and manage the > webserver. Do you use these servers as a central rendezvous service, or do > you have some DHT to connect peers? > > What other neat things are going on under the hood? > > -david > > > -----Original Message----- > > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org] On > > Behalf Of Ash Maurya > > Sent: Saturday, May 06, 2006 7:10 AM > > To: Peer-to-peer development. > > Subject: [p2p-hackers] Introducing BoxCloud > > > > Hi all, > > > > Wanted to share a new service we just launched called BoxCloud: A > > dead simple way to share files with people you know. > > > > The part we are really excited about is the ability to share files > > with others right from your desktop but have them view them over a > > browser - with no additional software required. We strongly believe > > blurring the boundaries between the desktop and the web (User Centric > > Web or P2PWeb) needs to happen and creates more interesting > > opportunities for mash-ups. Head on over to http://www.boxcloud.com > > if you are interested... > > > > Regards, > > > > Ash > > --- > > Founder, WiredReach > > company: http://www.wiredreach.com > > weblog: http://www.wiredjournal.com > > _______________________________________________ > > 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 ash at wiredreach.com Tue May 9 13:22:19 2006 From: ash at wiredreach.com (Ash Maurya) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: <93a05d860605082353i2ac80072q1ed4aeba3655feec@mail.gmail.com> References: <20060509054031.53BB03FC59@capsicum.zgp.org> <93a05d860605082353i2ac80072q1ed4aeba3655feec@mail.gmail.com> Message-ID: <9BBC9A84-86B4-4A88-A99E-0CD0494CB265@wiredreach.com> Hi Roberto - Yes, I remember coming across YouServ. However, if I remember right this was only an intranet (LAN) solution - I may be wrong. Our goal was to reach average email users because they are the ones that struggle the most with transferring large files but your point is well taken on the availability limitation. We are working on a number of clustering, swarming and hardware options that will allow users to overcome this limitation. We are hoping adsense will cover some costs (not all). We are counting on the other premium services for that... Best, Ash On May 9, 2006, at 1:53 AM, Roberto Bayardo wrote: > You guys should really integrate this with IM instead of e-mail. Since > the user has to be online to support the transfer, e-mail doesn't seem > to be the best delivery mechanism for your notifications. > > We did this a while back in YouServ with the "SecureLink" plugin: > http://www.bayardo.org/ps/www2005_2.pdf. Unfortunately I could never > get it outside the confines of IBM. Sounds like BoxCloud is a very > similar idea, only using a centralized server to always act as a > trusted relay. I guess you're hoping the adsense clicks will allow > you to recoup the bandwidth costs? > > > On 5/8/06, David Barrett wrote: >> Looks very cool! Can you give a quick overview of how it works? >> >> I see you have Mac, Win, and (soon) Linux ports. Are you using >> Java, or >> what language? >> >> You have some servers in place, clearly, to send out emails and >> manage the >> webserver. Do you use these servers as a central rendezvous >> service, or do >> you have some DHT to connect peers? >> >> What other neat things are going on under the hood? >> >> -david >> >> > -----Original Message----- >> > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers- >> bounces@zgp.org] On >> > Behalf Of Ash Maurya >> > Sent: Saturday, May 06, 2006 7:10 AM >> > To: Peer-to-peer development. >> > Subject: [p2p-hackers] Introducing BoxCloud >> > >> > Hi all, >> > >> > Wanted to share a new service we just launched called BoxCloud: A >> > dead simple way to share files with people you know. >> > >> > The part we are really excited about is the ability to share files >> > with others right from your desktop but have them view them over a >> > browser - with no additional software required. We strongly believe >> > blurring the boundaries between the desktop and the web (User >> Centric >> > Web or P2PWeb) needs to happen and creates more interesting >> > opportunities for mash-ups. Head on over to http://www.boxcloud.com >> > if you are interested... >> > >> > Regards, >> > >> > Ash >> > --- >> > Founder, WiredReach >> > company: http://www.wiredreach.com >> > weblog: http://www.wiredjournal.com >> > _______________________________________________ >> > 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 >> > _______________________________________________ > 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 ash at wiredreach.com Tue May 9 13:15:26 2006 From: ash at wiredreach.com (Ash Maurya) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: <20060509054031.53BB03FC59@capsicum.zgp.org> References: <20060509054031.53BB03FC59@capsicum.zgp.org> Message-ID: Hi David - This is Java app built over the WiredReach Platform (http:// www.wiredreach.org) which in turn is built over several open source technologies: Eclipse, JXTA, Smack, Jena, Jetty, etc. Our goal really is to bring p2p like functionality to people that either cannot use p2p in their networks (IT depts), or are scared of it (negative press). We figured that by taking a p2pweb approach we eliminate half the battle. In addition to email and webserver functionality, the central servers also provide user authentication, discovery and p2pweb gateway functionality - serving effectively as a central rendezvous service that can resolve a web url to one or machine endpoints. DHT is used to connect peers already in JXTA and we additionally plan on using it to locate content in the network. There is currently a limitation that requires a user's machine to be online to serve up a file. We would like to treat all content as first level objects in the network and allow them to be served from one or machines either owned or leased by the user and/or his contacts. Would love to hear any other feedback/questions you may have... Cheers, Ash On May 9, 2006, at 12:28 AM, David Barrett wrote: > Looks very cool! Can you give a quick overview of how it works? > > I see you have Mac, Win, and (soon) Linux ports. Are you using > Java, or > what language? > > You have some servers in place, clearly, to send out emails and > manage the > webserver. Do you use these servers as a central rendezvous > service, or do > you have some DHT to connect peers? > > What other neat things are going on under the hood? > > -david > >> -----Original Message----- >> From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers- >> bounces@zgp.org] On >> Behalf Of Ash Maurya >> Sent: Saturday, May 06, 2006 7:10 AM >> To: Peer-to-peer development. >> Subject: [p2p-hackers] Introducing BoxCloud >> >> Hi all, >> >> Wanted to share a new service we just launched called BoxCloud: A >> dead simple way to share files with people you know. >> >> The part we are really excited about is the ability to share files >> with others right from your desktop but have them view them over a >> browser - with no additional software required. We strongly believe >> blurring the boundaries between the desktop and the web (User Centric >> Web or P2PWeb) needs to happen and creates more interesting >> opportunities for mash-ups. Head on over to http://www.boxcloud.com >> if you are interested... >> >> Regards, >> >> Ash >> --- >> Founder, WiredReach >> company: http://www.wiredreach.com >> weblog: http://www.wiredjournal.com >> _______________________________________________ >> 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 bayardo at alum.mit.edu Tue May 9 14:21:10 2006 From: bayardo at alum.mit.edu (Roberto Bayardo) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: <9BBC9A84-86B4-4A88-A99E-0CD0494CB265@wiredreach.com> References: <20060509054031.53BB03FC59@capsicum.zgp.org> <93a05d860605082353i2ac80072q1ed4aeba3655feec@mail.gmail.com> <9BBC9A84-86B4-4A88-A99E-0CD0494CB265@wiredreach.com> Message-ID: <93a05d860605090721j471009a0keb9f4eb8676068@mail.gmail.com> There really wasn't anything inherently LAN specific about YouServ. In fact it was always my goal to run a WWW-wide deployment. It was run only within the IBM intranet because (sadly) I couldn't get approval to deploy it more widely or open source the software. The IBM intranet is more a microcosm of the internet than a LAN, with lots of VPN based users (many on dialup), NATs, firewalls, and slow international links. I had a few limited WWW accessible nodes that were integrated with AdSense for the purpose of demos, but nothing beyond that. Best of luck with BoxCloud. Something like built in BitTorrent support would be a great feature. I'm looking forward to seeing how your system develops. Cheers, Roberto On 5/9/06, Ash Maurya wrote: > Hi Roberto - > > Yes, I remember coming across YouServ. However, if I remember right > this was only an intranet (LAN) solution - I may be wrong. Our goal > was to reach average email users because they are the ones that > struggle the most with transferring large files but your point is > well taken on the availability limitation. We are working on a number > of clustering, swarming and hardware options that will allow users to > overcome this limitation. We are hoping adsense will cover some costs > (not all). We are counting on the other premium services for that... > > Best, > > Ash > > On May 9, 2006, at 1:53 AM, Roberto Bayardo wrote: > > > You guys should really integrate this with IM instead of e-mail. Since > > the user has to be online to support the transfer, e-mail doesn't seem > > to be the best delivery mechanism for your notifications. > > > > We did this a while back in YouServ with the "SecureLink" plugin: > > http://www.bayardo.org/ps/www2005_2.pdf. Unfortunately I could never > > get it outside the confines of IBM. Sounds like BoxCloud is a very > > similar idea, only using a centralized server to always act as a > > trusted relay. I guess you're hoping the adsense clicks will allow > > you to recoup the bandwidth costs? > > > > > > On 5/8/06, David Barrett wrote: > >> Looks very cool! Can you give a quick overview of how it works? > >> > >> I see you have Mac, Win, and (soon) Linux ports. Are you using > >> Java, or > >> what language? > >> > >> You have some servers in place, clearly, to send out emails and > >> manage the > >> webserver. Do you use these servers as a central rendezvous > >> service, or do > >> you have some DHT to connect peers? > >> > >> What other neat things are going on under the hood? > >> > >> -david > >> > >> > -----Original Message----- > >> > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers- > >> bounces@zgp.org] On > >> > Behalf Of Ash Maurya > >> > Sent: Saturday, May 06, 2006 7:10 AM > >> > To: Peer-to-peer development. > >> > Subject: [p2p-hackers] Introducing BoxCloud > >> > > >> > Hi all, > >> > > >> > Wanted to share a new service we just launched called BoxCloud: A > >> > dead simple way to share files with people you know. > >> > > >> > The part we are really excited about is the ability to share files > >> > with others right from your desktop but have them view them over a > >> > browser - with no additional software required. We strongly believe > >> > blurring the boundaries between the desktop and the web (User > >> Centric > >> > Web or P2PWeb) needs to happen and creates more interesting > >> > opportunities for mash-ups. Head on over to http://www.boxcloud.com > >> > if you are interested... > >> > > >> > Regards, > >> > > >> > Ash > >> > --- > >> > Founder, WiredReach > >> > company: http://www.wiredreach.com > >> > weblog: http://www.wiredjournal.com > >> > _______________________________________________ > >> > 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 > >> > > _______________________________________________ > > 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 tidiemme at gmail.com Tue May 9 14:32:11 2006 From: tidiemme at gmail.com (TiDi) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] 10K TCP connection Message-ID: <881eb26b0605090732p6f5fd1e0j54cc0eb2f769c5ac@mail.gmail.com> Hi I'm looking for (opensource) projects that can handle about 10K simultaneous TCP connections... Any idea? The platform doesn't matter Thanx TiDi -- -----BEGIN GEEK CODE BLOCK----- Version: 3.12 GCS d--- s: a- C++(++++) BLSU+++$ P+ L+++(++++) E--- W+ N++ o K- w++ O- M+ V PS++> PE++ Y++ PGP t 5 X R+> !tv b+ DI D+++> G++> e h-- r z ------END GEEK CODE BLOCK------ From justin at specialbusservice.com Tue May 9 14:44:51 2006 From: justin at specialbusservice.com (Justin Cormack) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] 10K TCP connection In-Reply-To: <881eb26b0605090732p6f5fd1e0j54cc0eb2f769c5ac@mail.gmail.com> References: <881eb26b0605090732p6f5fd1e0j54cc0eb2f769c5ac@mail.gmail.com> Message-ID: <4DCBD63B-FCAA-407D-A234-E720B119A221@specialbusservice.com> On 9 May 2006, at 15:32, TiDi wrote: > Hi > I'm looking for (opensource) projects that can handle about 10K > simultaneous TCP connections... http://www.kegel.com/c10k.html Lots of links there. Justin From coderman at gmail.com Tue May 9 15:14:30 2006 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] 10K TCP connection In-Reply-To: <881eb26b0605090732p6f5fd1e0j54cc0eb2f769c5ac@mail.gmail.com> References: <881eb26b0605090732p6f5fd1e0j54cc0eb2f769c5ac@mail.gmail.com> Message-ID: <4ef5fec60605090814l2d210c79v3349d20ea9512450@mail.gmail.com> On 5/9/06, TiDi wrote: > ... > I'm looking for (opensource) projects that can handle about 10K > simultaneous TCP connections... libevent http://monkey.org/~provos/libevent/ :) From adamfisk at gmail.com Tue May 9 22:33:33 2006 From: adamfisk at gmail.com (Adam Fisk) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Introducing BoxCloud In-Reply-To: References: <20060509054031.53BB03FC59@capsicum.zgp.org> Message-ID: Very interesting project, Ash. I've been working on a project that shares many similar features, although we decided about a year ago to do everything over a SIP-based platform instead of building on the work at JXTA. Very interesting you're using XMPP for presence and messaging -- certainly makes sense. Seems like our share a great deal both technologically and ideologically. Roberto's work at YouServ certainly influenced our thinking in terms of using browser and straight HTTP servers, and we're also leveraging open source projects like Jetty. I'll be sending out updates to this list shortly as well. Might be interesting to share some code in the future. Best of Luck! -Adam On 5/9/06, Ash Maurya wrote: > > Hi David - > > This is Java app built over the WiredReach Platform (http:// > www.wiredreach.org) which in turn is built over several open source > technologies: Eclipse, JXTA, Smack, Jena, Jetty, etc. > > Our goal really is to bring p2p like functionality to people that > either cannot use p2p in their networks (IT depts), or are scared of > it (negative press). We figured that by taking a p2pweb approach we > eliminate half the battle. In addition to email and webserver > functionality, the central servers also provide user authentication, > discovery and p2pweb gateway functionality - serving effectively as a > central rendezvous service that can resolve a web url to one or > machine endpoints. > > DHT is used to connect peers already in JXTA and we additionally plan > on using it to locate content in the network. There is currently a > limitation that requires a user's machine to be online to serve up a > file. We would like to treat all content as first level objects in > the network and allow them to be served from one or machines either > owned or leased by the user and/or his contacts. > > Would love to hear any other feedback/questions you may have... > > Cheers, > > Ash > > > On May 9, 2006, at 12:28 AM, David Barrett wrote: > > > Looks very cool! Can you give a quick overview of how it works? > > > > I see you have Mac, Win, and (soon) Linux ports. Are you using > > Java, or > > what language? > > > > You have some servers in place, clearly, to send out emails and > > manage the > > webserver. Do you use these servers as a central rendezvous > > service, or do > > you have some DHT to connect peers? > > > > What other neat things are going on under the hood? > > > > -david > > > >> -----Original Message----- > >> From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers- > >> bounces@zgp.org] On > >> Behalf Of Ash Maurya > >> Sent: Saturday, May 06, 2006 7:10 AM > >> To: Peer-to-peer development. > >> Subject: [p2p-hackers] Introducing BoxCloud > >> > >> Hi all, > >> > >> Wanted to share a new service we just launched called BoxCloud: A > >> dead simple way to share files with people you know. > >> > >> The part we are really excited about is the ability to share files > >> with others right from your desktop but have them view them over a > >> browser - with no additional software required. We strongly believe > >> blurring the boundaries between the desktop and the web (User Centric > >> Web or P2PWeb) needs to happen and creates more interesting > >> opportunities for mash-ups. Head on over to http://www.boxcloud.com > >> if you are interested... > >> > >> Regards, > >> > >> Ash > >> --- > >> Founder, WiredReach > >> company: http://www.wiredreach.com > >> weblog: http://www.wiredjournal.com > >> _______________________________________________ > >> 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 > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20060509/9979e323/attachment.html From luigi at diacronic.org Wed May 10 19:26:17 2006 From: luigi at diacronic.org (=?iso-8859-1?Q?Luigi_De_Don=E0?=) Date: Sat Dec 9 22:13:16 2006 Subject: [p2p-hackers] Merkle Hash Trees + live stream Message-ID: <443D25F800C3B8A6@ms004msg.mail.fw> (added by postmaster@fastwebnet.it) Hi all, I would like to use a type of Merkle Hash Trees for verifying the integrity of a live stream delivered using an application level multicast distribution tree. Any applicative ideas? Luigi De Don? From lists at user-land.org Wed May 10 20:29:07 2006 From: lists at user-land.org (Philippe Landau) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] USA Preparing the Takedown of P2P Message-ID: <4461D680.1000805@user-land.org> US plans to 'fight the net' revealed (2006-01) http://news.bbc.co.uk/2/hi/americas/4655196.stm From influencing public opinion through new media to designing "computer network attack" weapons, the US military is learning to fight an electronic war. The declassified document is called "Information Operations Roadmap". Wrecking the Internet: Turning Gold into Lead (by Robert Storey 2006-05) http://distrowatch.com/weekly.php?issue=20060508#opinion The COPE Act would do away with the requirement for net neutrality, thus turning America's Internet into a "private network." This would permit ISPs and telecom companies to dish out Internet access to the highest bidder. Under such a regime, AOL could, for example, block access to MSN, or Verizon could throttle your Skype bandwidth because it competes with their own voice-over-IP service. Even worse, a wealthy political party could pay ISPs to block access to a rival party's web sites and blogs. Emailing lists could also be throttled. It's not hard to imagine proprietary software companies paying to block access to DistroWatch, or prevent you from downloading the latest Ubuntu or Fedora release. [...] Opposition to the COPE Act is being coordinated by Save the Internet. http://savetheinternet.com/ The telecom/cable industry is pulling out all stops to polish this turd. Their "coalition" has the Orwellian title Hands Off the Internet - their thoroughly misleading web site can be found here. The telecoms have lots of cash, and are handing out campaign contributions (otherwise known as "bribes") by the bucketful in order to get the COPE Act passed. Geeks of the world - especially US-based geeks - need to put down their cups of espresso for a moment and get busy fighting this thing. [...] Kind regards Philippe -- http://distrowatch.com/weekly.php?issue=20060508#opinion Not everyone realizes that the USA invented the Internet. Even fewer people realize that the USA is on the verge of wrecking it. This is not an exaggeration. Some nasty new legislation currently under debate in the US Congress could make the Internet as bland as day-old yogurt. Those who do not live in the USA should not be smug. There is a famous old saying that when America sneezes, the rest of the world catches pneumonia. The USA has a history of exporting its bad laws. Most geeks are familiar with the notorious DMCA and software patents. Thanks to the DMCA, DVDs are region-coded and it's illegal to buy mod-chips for an Xbox. Thanks to software patents, most Linux distros do not have video codecs or an MP3 player. The fact that this execrable legislation originated in America did not prevent its rottenness from spreading around the world. To understand what is at stake, you should become familiar with the term net neutrality. The basic concept of net neutrality is that Internet content should be dished out in a non-discriminatory fashion. Thus, your ISP should not be preventing you from accessing DistroWatch, nor should your bandwidth be throttled when you try to use BitTorrent or Skype. In this sense, the network is neutral - it does not play favorites. All this would change (for USA residents) if the US Congress passes the Communications Opportunity, Promotion, and Enhancement (COPE) Act of 2006. This odious new law is the brainchild of telecom and cable TV companies. Chief ogres include Verizon, Comcast, BellSouth and AT&T. Their incentive for pushing this legal abomination is the opportunity to make a lot of money. The COPE Act would do away with the requirement for net neutrality, thus turning America's Internet into a "private network." This would permit ISPs and telecom companies to dish out Internet access to the highest bidder. Under such a regime, AOL could, for example, block access to MSN, or Verizon could throttle your Skype bandwidth because it competes with their own voice-over-IP service. Even worse, a wealthy political party could pay ISPs to block access to a rival party's web sites and blogs. Emailing lists could also be throttled. It's not hard to imagine proprietary software companies paying to block access to DistroWatch, or prevent you from downloading the latest Ubuntu or Fedora release. COPE "If we fail, the Internet will deteriorate to the point of near uselessness." If the COPE Act is passed, the USA - which likes to boast of being a "bastion of freedom" - could ironically wind up with an Internet befitting a Third World dictatorship. However, the damage would not be limited to residents of the USA. The fact is that about 50% of the content on the Internet originates in America, even more if you're talking only about English-language content. Do a Google search on almost any topic - from "motorcycle repair" to "allergies" - and see how much of the hits are American-based web sites. The web sites themselves could be hosted on servers outside the USA, but server location is not the issue. Rather, deprived of their US-readership or US-based advertising revenue, many sites would have to fold. Would the Internet be as useful to you if Wikipedia or Google folded? For that matter, it's hard to see how DistroWatch (which is not US-based) could survive if we lost our American audience and advertisers. There is a lot more I could write about on this topic, but there are others who have already done so (and do it better than me). Some excellent articles about this brewing fiasco appeared recently in The Nation, Raw Story and The Free Press. Sadly, I have seen nothing mentioned on the popular geek web sites that I visit everyday (which is why I'm writing this article). Can anything to done to prevent this disaster (especially since the COPE Act seems to have the support of the Bush administration)? Fortunately, in this case I believe there is hope, though it's going to be a bitter fight. Although we are up against powerful, well-moneyed lobbyists from the telecom industry, we also have some heavyweight supporters, among them Amazon and Google. Opposition to the COPE Act is being coordinated by Save the Internet. If you are a US resident, you should visit their web site and sign their petition. Even more important, they also have a neat little form for sending a message to your representatives and senators - just type in your message, zip code and address, and it will get sent to the proper person (you needn't even know who your representatives are). All such messages should be short and to the point. Basically, what I said in my message was: 1. I oppose the Communications Opportunity, Promotion, and Enhancement (COPE) Act of 2006 in its present form. 2. I support the efforts to amend the act by Representatives Markey, Boucher, Eshoo and Inslee, and Senators Olympia Snowe and Byron Dorgan. 3. I am in favor of Net Neutrality. The telecom/cable industry is pulling out all stops to polish this turd. Their "coalition" has the Orwellian title Hands Off the Internet - their thoroughly misleading web site can be found here. The telecoms have lots of cash, and are handing out campaign contributions (otherwise known as "bribes") by the bucketful in order to get the COPE Act passed. Geeks of the world - especially US-based geeks - need to put down their cups of espresso for a moment and get busy fighting this thing. If we fail, the Internet will deteriorate to the point of near uselessness and we might as well put our computers in storage. In that case, we'll have to all find new hobbies. Possible candidates include knitting and flower arranging. From sam at neurogrid.com Thu May 11 10:02:25 2006 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:13:17 2006 Subject: [p2p-hackers] Call for paper MSOP2P Message-ID: <44630468.60002@neurogrid.com> --------------------------------------------------------------------- CALL FOR PAPERS --------------------------------------------------------------------- First International Workshop on Modeling, Simulation and Optimization of Peer-to-peer environments (MSOP2P) http://lifc.univ-fcomte.fr/~bourgeoi/msop2p.html In conjunction with Euromicro PDP 2007 7-9 February 2007 in Naples, Italy http://www.na.icar.cnr.it/~pdp2007 --------------------------------------------------------------------- WORKSHOP OVERVIEW --------------------------------------------------------------------- Peer-to-Peer (P2P) systems allow to gather a wide range of computers into a single environment. Performance of such environments is difficult to evaluate due to the heterogeneity and to the number of computers participating in the system. Therefore, modeling and simulation are now becoming more and more used in order to optimize the behavior of P2P environments. The International Workshop on Modeling, Simulation and Optimization of Peer-to-peer environments (MSOP2P) aims to bring together researchers and practitioners from academia, industry and government to advance the state of the art in modeling, simulating and optimizing P2P environments. The workshop will also represent an occasion to share, to learn and to discuss the latest results in this field of research. Topics of interest include, but are not limited to: * Modeling of P2P systems * Performance evaluation of P2P systems * Simulation of P2P systems * Traffic management for P2P computing systems * Algorithms for computing and performance implications in P2P environments * Analytical modeling of Peer-to-Peer systems * Quantitative analysis of Peer-to-Peer infrastructure and overlay networks * Emulation of P2P systems * Protocols for resource management/discovery/reservation/scheduling and their evaluation * Workload characterization for P2P systems --------------------------------------------------------------------- IMPORTANT DATES --------------------------------------------------------------------- June 30th, 2006 Full papers submission deadline September 29th, 2006 Paper notification October 27th, 2006 Camera-ready papers --------------------------------------------------------------------- SUBMISSION GUIDELINES --------------------------------------------------------------------- Prospective authors should submit a full paper not exceeding 5000 words in length and including a 150-200 word abstract. To facilitate an anonymous reviewing process, the first page of the paper should contain only the title and abstract. Proceedings will be published by IEEE Computer Society Press. Best papers will be selected for special issues of Elsevier Journal of Systems Architecture and InderScience International Journal of Computational Science and Engineering. Papers must be submitted through the conference submission system (http://www.pdp2007.it/sub.html) with an indication of the name of the workshop. --------------------------------------------------------------------- PROGRAM COMMITTEE --------------------------------------------------------------------- The Program Committee includes the following people. Program Chairs: Julien Bourgeois, University of Franche-Comte (France) Giovanni Chiola, Universita' di Genova (Italy) Program Committee members: Didier El Baz, CNRS (France) Michele Colajanni, Universita' di Modena e Reggio Emilia (Italy) Vasilios Darlagiannis, EPFL (Switzerland) Gilles Fedak, INRIA Futurs (France) Adriana Iamnitchi, University of South Florida (USA) Sam Joseph, University of Hawaii (USA)