From wharms at bfs.de Wed Jun 1 09:22:21 2005 From: wharms at bfs.de (walter harms) Date: Sat Dec 9 22:12:54 2006 Subject: [p2p-hackers] MTU in the real world In-Reply-To: <429C3818.5030606@quinthar.com> References: <429C3818.5030606@quinthar.com> Message-ID: <429D7E4D.8050701@bfs.de> i had problems with firewalls (at least once) with MTU 1500 and larger. obscure features (like ching mtu) are not good tested and can cause problems in strange places. a veriation would be to change the mtu with every packet an see what happens. so you can optimise for every connection. re, walter David Barrett wrote: > I've read in multiple places that it's best to have a UDP MTU of under > 1500 bytes. However, it sounds like most of this is based on > theoretical analysis, and not on real-world experience. > > With this in mind, have you tried using a MTU bigger than 1500 bytes and > been bitten by it? Basically, do you know of any emperical analysis (of > any level of formality) of a real-world UDP application that supports or > refutes the 1500 byte rule of thumb? > > Furthermore, I've read that if you "connect" your UDP socket to the > remote side and then start sending large packets and backing off slowly, > the socket layer will compute the "real" MTU between two endpoints, and > you can obtain it through "getsockopt". Do you know of anyone who's > tried this, and the results? > > -david > _______________________________________________ > 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 john.casey at gmail.com Wed Jun 1 10:56:57 2005 From: john.casey at gmail.com (John Casey) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] MTU in the real world In-Reply-To: <429D7E4D.8050701@bfs.de> References: <429C3818.5030606@quinthar.com> <429D7E4D.8050701@bfs.de> Message-ID: OK. so we can also surmize from this that if we want to send a large chunk of data that we are better off using TCP ?? and to only use UDP for small messages ?? On 6/1/05, walter harms wrote: > > i had problems with firewalls (at least once) with MTU 1500 and larger. > obscure features (like ching mtu) are not good tested and can cause > problems in strange places. a veriation would be to change the mtu with > every packet an see what happens. so you can optimise for every connection. From justin at specialbusservice.com Wed Jun 1 11:03:47 2005 From: justin at specialbusservice.com (Justin Cormack) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] MTU in the real world In-Reply-To: References: <429C3818.5030606@quinthar.com> <429D7E4D.8050701@bfs.de> Message-ID: On 1 Jun 2005, at 11:56, John Casey wrote: > OK. so we can also surmize from this that if we want to send a large > chunk of data that we are better off using TCP ?? and to only use UDP > for small messages ?? The best (perhaps only sensible) situation for using UDP is where your messages match UDP ones, ie they are small (say 1k payload plus some headers) and it doesnt matter if some are lost (ie you dont even need retry - eg if using error correcting codes or whatever). If you want to use UDP, design your protocol around this (or vice versa). Otherwise you will just be reinventing TCP in UDP. j From eugen at leitl.org Wed Jun 1 11:14:33 2005 From: eugen at leitl.org (Eugen Leitl) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] MTU in the real world In-Reply-To: References: <429C3818.5030606@quinthar.com> <429D7E4D.8050701@bfs.de> Message-ID: <20050601111433.GZ3361@leitl.org> On Wed, Jun 01, 2005 at 12:03:47PM +0100, Justin Cormack wrote: > The best (perhaps only sensible) situation for using UDP is where > your messages match UDP ones, ie they are small (say 1k payload plus > some headers) and it doesnt matter if some are lost (ie you dont even > need retry - eg if using error correcting codes or whatever). If you > want to use UDP, design your protocol around this (or vice versa). > Otherwise you will just be reinventing TCP in UDP. A good use of UDP would be for fanning out of a search query to a global P2P search engine (using an amplification cascade) -- it would fit into few 100 Bytes, needs no ACK, and it could be lossy (nobody expects deterministic results from a search engine). Given a query amplification rate of 1:10, and a spidering rate of 1:1000 (each P2P node is responsible for spidering 1000 others) and a reasonable global graph connectivity (not too much redundancy) that could be quite usable. -- Eugen* Leitl leitl ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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: 189 bytes Desc: Digital signature Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050601/a63a2c9b/attachment.pgp From will at memefeeder.com Wed Jun 1 12:50:50 2005 From: will at memefeeder.com (Will Morton) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] MTU in the real world In-Reply-To: References: <429C3818.5030606@quinthar.com> <429D7E4D.8050701@bfs.de> Message-ID: <6CFE03A0-DA5B-47D3-9F69-327EBD34404F@memefeeder.com> On 1 Jun 2005, at 12:03, Justin Cormack wrote: > > The best (perhaps only sensible) situation for using UDP is where > your messages match UDP ones, ie they are small (say 1k payload > plus some headers) and it doesnt matter if some are lost (ie you > dont even need retry - eg if using error correcting codes or > whatever). If you want to use UDP, design your protocol around this > (or vice versa). Otherwise you will just be reinventing TCP in UDP. > As previously discussed here, you may well want to do exactly this in order to do NAT penetration. W -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2388 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050601/129e34f5/smime.bin From coderman at gmail.com Wed Jun 1 18:38:04 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] MTU in the real world In-Reply-To: <20050601111433.GZ3361@leitl.org> References: <429C3818.5030606@quinthar.com> <429D7E4D.8050701@bfs.de> <20050601111433.GZ3361@leitl.org> Message-ID: <4ef5fec605060111383449be35@mail.gmail.com> On 6/1/05, Eugen Leitl wrote: > A good use of UDP would be for fanning out of a search query to a global P2P search > engine (using an amplification cascade) -- it would fit into few 100 Bytes, > needs no ACK, and it could be lossy (nobody expects deterministic results > from a search engine). I used UDP for my fully decentralized search implementation because it was so lightweight and could support many concurrent logical connections between peers (high node degree was required to make search effective). As for using UDP over consumer internet links I found that some Windows NAT's would simply drop any NAT'd UDP packets over MTU [that is to say, the Windows NAT would not reassemble fragmented UDP datagrams]. Most NAT's seemed to handle larger packets fine, so MTU discovery would probably be worth the effort. From PaulLambert at AirgoNetworks.Com Wed Jun 1 20:13:41 2005 From: PaulLambert at AirgoNetworks.Com (Paul Lambert) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] RE: MTU in the real world Message-ID: <3FFBC907DD03A34CA4410C5C745DEB1206AA63F0@wnimail.WoodsideNet.Com> In April I was trying to use Turbo Tax and kept getting 'server errors' when trying to download a software update. The root cause was my Dlink home router and Intuit MTU configuration. My router needed to have the MTU increased to 1496. I assume many thousnads of MTU ignorant TurboTax users were unable to submit their taxes in a timely manner (Intuit did offer to send a CD). So ... MTU size does matter. It's better to optimize for interoperability and not performance. Paul From dbarrett at quinthar.com Wed Jun 1 20:53:36 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] MTU in the real world In-Reply-To: <4ef5fec605060111383449be35@mail.gmail.com> References: <429C3818.5030606@quinthar.com> <429D7E4D.8050701@bfs.de> <20050601111433.GZ3361@leitl.org> <4ef5fec605060111383449be35@mail.gmail.com> Message-ID: <429E2050.2070104@quinthar.com> coderman wrote: > As for using UDP over consumer internet links I found that some > Windows NAT's would simply drop any NAT'd UDP packets over MTU [that > is to say, the Windows NAT would not reassemble fragmented UDP > datagrams]. Most NAT's seemed to handle larger packets fine, so MTU > discovery would probably be worth the effort. By this do you mean the Windows NAT would drop any UDP packet over 1492 bytes? What was the cutoff-point? From dbarrett at quinthar.com Wed Jun 1 20:55:06 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] RE: MTU in the real world In-Reply-To: <3FFBC907DD03A34CA4410C5C745DEB1206AA63F0@wnimail.WoodsideNet.Com> References: <3FFBC907DD03A34CA4410C5C745DEB1206AA63F0@wnimail.WoodsideNet.Com> Message-ID: <429E20AA.5000700@quinthar.com> Paul Lambert wrote: > > My router needed to have the MTU increased to 1496. What was its original setting? -david From dbarrett at quinthar.com Mon Jun 6 01:50:36 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts Message-ID: <42A3ABEC.8070000@quinthar.com> Ok, next question: What kind of keepalive period do you used to maintain the holes you so meticulously punched? I'm in the process of testing my NAT hole-punching solution, and I'm finding erratic behavior that I *think* is caused by my holes closing on me. (Ie, I'm able to receive from a peer for a time, and then I cannot.) So I'm implementing a keepalive, but I'm unsure of what period to use. For now I'm just using a fixed 20-second period, but I have no idea if that's high or low. Another option is to have some kind of adaptive solution that tracks elapsed time between sent and received data (thus estimating the last known 'good' window), but that's a pain I'd prefer to avoid. Any suggestions? The IETF BEHAVE group has discussed recommendations from anywhere between 30 seconds (http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) and 15 minutes (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). But ultimately those are foward-looking discussions, and therefore not relevant. In the real world, I've seen mention that even 30 seconds is insufficient (http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). Perhaps 20 seconds works (http://www.tisc2001.com/newsletters/322.html), but who knows. Basically, I'm curious what keepalives you've found work today in your real applications, in the real world. -david From ap at hamachi.cc Mon Jun 6 01:53:01 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts In-Reply-To: <42A3ABEC.8070000@quinthar.com> References: <42A3ABEC.8070000@quinthar.com> Message-ID: <42A3AC7D.9040409@hamachi.cc> I am aware of at least one fairly big firewall vendor whose devices default to 20 sec UDP rule lifetime. It is even less if the traffic is unidirectional (ie 'unconfirmed' by the recepient). We are using 20 sec and seems to work fine for our purposes. Alex David Barrett wrote: > Ok, next question: What kind of keepalive period do you used to maintain > the holes you so meticulously punched? > > I'm in the process of testing my NAT hole-punching solution, and I'm > finding erratic behavior that I *think* is caused by my holes closing on > me. (Ie, I'm able to receive from a peer for a time, and then I > cannot.) So I'm implementing a keepalive, but I'm unsure of what period > to use. For now I'm just using a fixed 20-second period, but I have no > idea if that's high or low. > > Another option is to have some kind of adaptive solution that tracks > elapsed time between sent and received data (thus estimating the last > known 'good' window), but that's a pain I'd prefer to avoid. > > Any suggestions? > > The IETF BEHAVE group has discussed recommendations from anywhere > between 30 seconds > (http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) and 15 > minutes (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). > But ultimately those are foward-looking discussions, and therefore not > relevant. > > In the real world, I've seen mention that even 30 seconds is > insufficient > (http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). > Perhaps 20 seconds works > (http://www.tisc2001.com/newsletters/322.html), but who knows. > > Basically, I'm curious what keepalives you've found work today in your > real applications, in the real world. > > -david > _______________________________________________ > 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 luca.gaballo at rd.francetelecom.com Mon Jun 6 08:34:50 2005 From: luca.gaballo at rd.francetelecom.com (Gaballo Luca) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts In-Reply-To: <42A3ABEC.8070000@quinthar.com> References: <42A3ABEC.8070000@quinthar.com> Message-ID: <42A40AAA.1040509@rd.francetelecom.com> A NAT can be: - "Outbound refresh": keep the mapping active when a packet goes from the internal side of the NAT to external side - "Inbound Refresh": keep the mapping active when a packet goes from the external side of the NAT to internal side or both! Moreover the NAT Mapping Refresh Scope can be: - "Per Mapping": refresh for all session on that mapping by any outbound traffic - "Per Session": refresh on a specific session on that particular mapping by any outbound traffic So, when you refresh with a 20-second period (a good delay) you must consider also this. Have fun, -- Luca ______________________________________________ Luca Gaballo - France Telecom - R&D Division Email: luca.gaballo@rd.francetelecom.com Peer networks - Solipsis Project http://solipsis.netofpeers.net/ Personal web: http://perso.enst.fr/~gaballo David Barrett wrote: > Ok, next question: What kind of keepalive period do you used to > maintain the holes you so meticulously punched? > > I'm in the process of testing my NAT hole-punching solution, and I'm > finding erratic behavior that I *think* is caused by my holes closing > on me. (Ie, I'm able to receive from a peer for a time, and then I > cannot.) So I'm implementing a keepalive, but I'm unsure of what > period to use. For now I'm just using a fixed 20-second period, but I > have no idea if that's high or low. > > Another option is to have some kind of adaptive solution that tracks > elapsed time between sent and received data (thus estimating the last > known 'good' window), but that's a pain I'd prefer to avoid. > > Any suggestions? > > The IETF BEHAVE group has discussed recommendations from anywhere > between 30 seconds > (http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) and 15 > minutes > (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). But > ultimately those are foward-looking discussions, and therefore not > relevant. > > In the real world, I've seen mention that even 30 seconds is > insufficient > (http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). > Perhaps 20 seconds works > (http://www.tisc2001.com/newsletters/322.html), but who knows. > > Basically, I'm curious what keepalives you've found work today in your > real applications, in the real world. > > -david > _______________________________________________ > 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/20050606/d05ddfda/attachment.html From oschroed at gmail.com Mon Jun 6 11:29:24 2005 From: oschroed at gmail.com (Oliver Schroeder) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] Simulation of hyprid P2P networks Message-ID: <42A43394.6090608@gmail.com> Hello, does anyone have experience in simulating hybrid p2p networks like KaZaA oder eDonkey? I would appreciate getting some information about appropriate simulation environments and experiences which have been made. I'm interested in investigation on topology changes (overlay topology) so it seems useful to simulate the network layer es well. Thank you very much for your help, Oliver From wangyong at software.ict.ac.cn Mon Jun 6 11:34:43 2005 From: wangyong at software.ict.ac.cn (=?gb2312?B?zfXTwg==?=) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] Simulation of hyprid P2P networks Message-ID: <20050606113438.C8F3B3FC32@capsicum.zgp.org> aGksIE9saXZlciBTY2hyb2VkZXINCglJJ20gZG9pbmcgYWxtb3N0IHRoZSBzYW1lIHdvcmssIEkn bSB0cnlpbmcgc2ltdWxhdGluZyBnbnV0ZWxsYSBuZXR3b3JrIG5vdywgYnV0IEkgaGF2ZSBubyBn b29kIGlkZWEgZWl0aGVyLCBJIG5lZWQgc29tZSBhZHZpY2VzIGFuZCBkaXNjdXNpb24uDQoJDQoJ bm93LCBJbSBmYWNpbmcgYSBwcm9ibGVtLCBJIGNvdWxkIG5vdCBzaGFraW5nIGhhbmRzIHdpdGgg Z251dGVsbGEgbm9kZS4gc28sIGhvdyBjb3VsZCBJIHNvbHZlIGl0Pw0KDQoJSSBob3BlIHdlIGNv dWxkIGRpc2N1c2lvbiBQMlAgc2ltdWxhdGluZyBhbmQgeW91ciBoZWxwLg0KDQoJDQoNCj09PT09 PT0gMjAwNS0wNi0wNiAxOToyOToyNCDE+tTawLTQxdbQ0LS1wKO6PT09PT09PQ0KDQo+SGVsbG8s DQo+DQo+ZG9lcyBhbnlvbmUgaGF2ZSBleHBlcmllbmNlIGluIHNpbXVsYXRpbmcgaHlicmlkIHAy cCBuZXR3b3JrcyBsaWtlIEthWmFBIA0KPm9kZXIgZURvbmtleT8gSSB3b3VsZCBhcHByZWNpYXRl IGdldHRpbmcgc29tZSBpbmZvcm1hdGlvbiBhYm91dCANCj5hcHByb3ByaWF0ZSBzaW11bGF0aW9u IGVudmlyb25tZW50cyBhbmQgZXhwZXJpZW5jZXMgd2hpY2ggaGF2ZSBiZWVuIA0KPm1hZGUuIDxz ZT9scD1lbmRlJnA9L01uNGsuJnNlYXJjaD1hcHByb3ByaWF0ZT4NCj4NCj5JJ20gaW50ZXJlc3Rl ZCBpbiBpbnZlc3RpZ2F0aW9uIG9uIHRvcG9sb2d5IGNoYW5nZXMgKG92ZXJsYXkgdG9wb2xvZ3kp IA0KPnNvIGl0IHNlZW1zIHVzZWZ1bCB0byBzaW11bGF0ZSB0aGUgbmV0d29yayBsYXllciBlcyB3 ZWxsLg0KPg0KPlRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgaGVscCwNCj4NCj5PbGl2ZXIN Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnAycC1o YWNrZXJzIG1haWxpbmcgbGlzdA0KPnAycC1oYWNrZXJzQHpncC5vcmcNCj5odHRwOi8vemdwLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3AycC1oYWNrZXJzDQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5IZXJlIGlzIGEgd2ViIHBhZ2UgbGlzdGluZyBQMlAg Q29uZmVyZW5jZXM6DQo+aHR0cDovL3d3dy5uZXVyb2dyaWQubmV0L3R3aWtpL2Jpbi92aWV3L01h aW4vUGVlclRvUGVlckNvbmZlcmVuY2VzDQo+DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0g PSA9ID0gPSA9ID0gPQ0KCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaHWwg0KwPGjoQ0KIA0KCQkJCSAN CqGhoaGhoaGhoaGhoaGhoaHN9dPCDQqhoaGhoaGhoaGhoaGhoaGhd2FuZ3lvbmdAc29mdHdhcmUu aWN0LmFjLmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDYtMDYNCg0K From dbarrett at quinthar.com Mon Jun 6 19:35:57 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts In-Reply-To: <42A40AAA.1040509@rd.francetelecom.com> References: <42A3ABEC.8070000@quinthar.com> <42A40AAA.1040509@rd.francetelecom.com> Message-ID: <1118086564.23EA3277@dk12.dngr.org> Ah, thanks for the breakdown -- I hadn't considered the need for a return packet. Do you have any stats on what fraction of NATs are outbound/inbound/both refresh, and per session/mapping? Does it correlate with the overall NAT type (full cone, etc), or is it unrelated? Also, thanks for confirming the 20-second keepalive. -david On Mon, 6 Jun 2005 2:26 am, Gaballo Luca wrote: > A NAT can be: > - "Outbound refresh": keep the mapping active when a packet goes from > the internal side of the NAT to external side > - "Inbound Refresh": keep the mapping active when a packet goes from > the external side of the NAT to internal side > or both! > > Moreover the NAT Mapping Refresh Scope can be: > - "Per Mapping": refresh for all session on that mapping by any > outbound traffic > - "Per Session": refresh on a specific session on that particular > mapping by any outbound traffic > > So, when you refresh with a 20-second period (a good delay) you must > consider also this. > > Have fun, > -- Luca > > > ______________________________________________ > Luca Gaballo - France Telecom - R&D Division > Email: luca.gaballo@rd.francetelecom.com > Peer networks - Solipsis Project > http://solipsis.netofpeers.net/ [http://solipsis.netofpeers.net/] > > Personal web: http://perso.enst.fr/~gaballo > [http://perso.enst.fr/%7Egaballo] > > > David Barrett wrote: > >> Ok, next question: What kind of keepalive period do you used to >> maintain the holes you so meticulously punched? > >> I'm in the process of testing my NAT hole-punching solution, and I'm >> finding erratic behavior that I *think* is caused by my holes closing >> on me.? (Ie, I'm able to receive from a peer for a time, and then I >> cannot.)? So I'm implementing a keepalive, but I'm unsure of what >> period to use.? For now I'm just using a fixed 20-second period, but I >> have no idea if that's high or low. > >> Another option is to have some kind of adaptive solution that tracks >> elapsed time between sent and received data (thus estimating the last >> known 'good' window), but that's a pain I'd prefer to avoid. > >> Any suggestions? > >> The IETF BEHAVE group has discussed recommendations from anywhere >> between 30 seconds >> (http://list.sipfoundry.org/archive/ietf-behave/msg00441.html >> [http://list.sipfoundry.org/archive/ietf-behave/msg00441.html]) and 15 >> minutes (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html >> [http://list.sipfoundry.org/archive/ietf-behave/msg00127.html]). But >> ultimately those are foward-looking discussions, and therefore not >> relevant. > >> In the real world, I've seen mention that even 30 seconds is >> insufficient >> (http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119 >> [http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119]). >> Perhaps 20 seconds works (http://www.tisc2001.com/newsletters/322.html >> [http://www.tisc2001.com/newsletters/322.html]), but who knows. > >> Basically, I'm curious what keepalives you've found work today in your >> real applications, in the real world. > >> -david >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@zgp.org [mailto:p2p-hackers@zgp.org] >> http://zgp.org/mailman/listinfo/p2p-hackers >> [http://zgp.org/mailman/listinfo/p2p-hackers] >> _______________________________________________ >> Here is a web page listing P2P Conferences: >> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences >> [http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences] > From dbarrett at quinthar.com Mon Jun 6 19:38:03 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts In-Reply-To: <42A3AC7D.9040409@hamachi.cc> References: <42A3ABEC.8070000@quinthar.com> <42A3AC7D.9040409@hamachi.cc> Message-ID: <1118086688.2235AA7A@dj11.dngr.org> Ok, sounds like 20 seconds might be an upper limit, then. Are you using "unconfirmed" keepalives, or bidirectional? Thanks for the info. On Sun, 5 Jun 2005 7:26 pm, Alex Pankratov wrote: > I am aware of at least one fairly big firewall vendor whose devices > default to 20 sec UDP rule lifetime. It is even less if the traffic > is unidirectional (ie 'unconfirmed' by the recepient). We are using > 20 sec and seems to work fine for our purposes. > > Alex > > David Barrett wrote: > >> Ok, next question: What kind of keepalive period do you used to >> maintain the holes you so meticulously punched? >> I'm in the process of testing my NAT hole-punching solution, and I'm >> finding erratic behavior that I *think* is caused by my holes closing >> on me. (Ie, I'm able to receive from a peer for a time, and then I >> cannot.) So I'm implementing a keepalive, but I'm unsure of what >> period to use. For now I'm just using a fixed 20-second period, but I >> have no idea if that's high or low. >> Another option is to have some kind of adaptive solution that tracks >> elapsed time between sent and received data (thus estimating the last >> known 'good' window), but that's a pain I'd prefer to avoid. >> Any suggestions? >> The IETF BEHAVE group has discussed recommendations from anywhere >> between 30 seconds >> (http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) and 15 >> minutes >> (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). But >> ultimately those are foward-looking discussions, and therefore not >> relevant. >> In the real world, I've seen mention that even 30 seconds is >> insufficient >> (http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). Perhaps 20 seconds works (http://www.tisc2001.com/newsletters/322.html), but who knows. >> Basically, I'm curious what keepalives you've found work today in your >> real applications, in the real world. >> -david >> _______________________________________________ >> 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 larytet.8753341 at bloglines.com Mon Jun 6 22:04:24 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts Message-ID: <1118095464.2420141351.15546.sendItem@bloglines.com> coroparet firewalls can not keep hole in NAT for 20s - there are too many DNS requests, NTP, RTP, etc. and "statefull" UDP firewall will create separate hole for every destination IP. the one i am sitting behind apparently follows 2s rule. --- David Barrett "unconfirmed" keepalives, or bidirectional? Thanks for the info. > > On Sun, 5 Jun 2005 7:26 pm, Alex Pankratov wrote: > > I am aware of at least one fairly big firewall vendor whose devices > > default to 20 sec UDP rule lifetime. It is even less if the traffic > > is unidirectional (ie 'unconfirmed' by the recepient). We are using > > 20 sec and seems to work fine for our purposes. > > > > Alex > > > > David Barrett wrote: > > > >> Ok, next question: What kind of keepalive period do you used to > >> maintain the holes you so meticulously punched? > >> I'm in the process of testing my NAT hole-punching solution, and I'm > >> finding erratic behavior that I *think* is caused by my holes closing > >> on me. (Ie, I'm able to receive from a peer for a time, and then I > >> cannot.) So I'm implementing a keepalive, but I'm unsure of what > >> period to use. For now I'm just using a fixed 20-second period, but I > >> have no idea if that's high or low. > >> Another option is to have some kind of adaptive solution that tracks > >> elapsed time between sent and received data (thus estimating the last > >> known 'good' window), but that's a pain I'd prefer to avoid. > >> Any suggestions? > >> The IETF BEHAVE group has discussed recommendations from anywhere > >> between 30 seconds > >> (http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) and 15 > >> minutes > >> (http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). But > >> ultimately those are foward-looking discussions, and therefore not > >> relevant. > >> In the real world, I've seen mention that even 30 seconds is > >> insufficient > >> (http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). Perhaps 20 seconds works (http://www.tisc2001.com/newsletters/322.html), but who knows. > >> Basically, I'm curious what keepalives you've found work today in your > >> real applications, in the real world. > >> -david > >> _______________________________________________ > >> 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 dbarrett at quinthar.com Mon Jun 6 23:31:45 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts In-Reply-To: <1118095464.2420141351.15546.sendItem@bloglines.com> References: <1118095464.2420141351.15546.sendItem@bloglines.com> Message-ID: <42A4DCE1.5010303@quinthar.com> Wow. 2s is a pretty small hole. Hm. Thanks for the info. larytet.8753341@bloglines.com wrote: > coroparet firewalls can not keep hole in NAT for 20s - there are too many > DNS requests, NTP, RTP, etc. and "statefull" UDP firewall will create separate > hole for every destination IP. > > the one i am sitting behind apparently > follows 2s rule. > > --- David Barrett Ok, sounds > like 20 seconds might be an upper limit, then. Are you using > >>"unconfirmed" > > keepalives, or bidirectional? Thanks for the info. > >>On Sun, 5 Jun 2005 > > 7:26 pm, Alex Pankratov wrote: > >>>I am aware of at least one fairly big > > firewall vendor whose devices > >>>default to 20 sec UDP rule lifetime. It > > is even less if the traffic > >>>is unidirectional (ie 'unconfirmed' by the > > recepient). We are using > >>>20 sec and seems to work fine for our purposes. > > >>>Alex >>> >>>David Barrett wrote: >>> >>> >>>>Ok, next question: > > What kind of keepalive period do you used to > >>>>maintain the holes you > > so meticulously punched? > >>>>I'm in the process of testing my NAT hole-punching > > solution, and I'm > >>>>finding erratic behavior that I *think* is caused > > by my holes closing > >>>>on me. (Ie, I'm able to receive from a peer for > > a time, and then I > >>>>cannot.) So I'm implementing a keepalive, but I'm > > unsure of what > >>>>period to use. For now I'm just using a fixed 20-second > > period, but I > >>>>have no idea if that's high or low. >>>>Another option > > is to have some kind of adaptive solution that tracks > >>>>elapsed time > > between sent and received data (thus estimating the last > >>>>known 'good' > > window), but that's a pain I'd prefer to avoid. > >>>>Any suggestions? >> >>>The IETF BEHAVE group has discussed recommendations from anywhere >>> > between 30 seconds > >>>>(http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) > > and 15 > >>>>minutes >>>>(http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). > > But > >>>>ultimately those are foward-looking discussions, and therefore > > not > >>>>relevant. >>>>In the real world, I've seen mention that even > > 30 seconds is > >>>>insufficient >>>>(http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). > > Perhaps 20 seconds works (http://www.tisc2001.com/newsletters/322.html), > but who knows. > >>>>Basically, I'm curious what keepalives you've found work > > today in your > >>>>real applications, in the real world. >>>>-david >> >>>_______________________________________________ >>> >>>>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 larytet.8753341 at bloglines.com Mon Jun 6 23:52:09 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts Message-ID: <1118101929.838908570.25074.sendItem@bloglines.com> and it resets (?) itself from time to time - 1-2 times/month. naturally peer will get different port after the reset. NAT penetration is a state machine and not a trivial one. --- Peer-to-peer development." > larytet.8753341@bloglines.com wrote: > > coroparet firewalls can not keep hole in NAT for 20s - there are too many > > DNS requests, NTP, RTP, etc. and "statefull" UDP firewall will create separate > > hole for every destination IP. > > > > the one i am sitting behind apparently > > follows 2s rule. > > > > --- David Barrett > Ok, sounds > > like 20 seconds might be an upper limit, then. Are you using > > > >>"unconfirmed" > > > > keepalives, or bidirectional? Thanks for the info. > > > >>On Sun, 5 Jun 2005 > > > > 7:26 pm, Alex Pankratov wrote: > > > >>>I am aware of at least one fairly big > > > > firewall vendor whose devices > > > >>>default to 20 sec UDP rule lifetime. It > > > > is even less if the traffic > > > >>>is unidirectional (ie 'unconfirmed' by the > > > > recepient). We are using > > > >>>20 sec and seems to work fine for our purposes. > > > > > >>>Alex > >>> > >>>David Barrett wrote: > >>> > >>> > >>>>Ok, next question: > > > > What kind of keepalive period do you used to > > > >>>>maintain the holes you > > > > so meticulously punched? > > > >>>>I'm in the process of testing my NAT hole-punching > > > > solution, and I'm > > > >>>>finding erratic behavior that I *think* is caused > > > > by my holes closing > > > >>>>on me. (Ie, I'm able to receive from a peer for > > > > a time, and then I > > > >>>>cannot.) So I'm implementing a keepalive, but I'm > > > > unsure of what > > > >>>>period to use. For now I'm just using a fixed 20-second > > > > period, but I > > > >>>>have no idea if that's high or low. > >>>>Another option > > > > is to have some kind of adaptive solution that tracks > > > >>>>elapsed time > > > > between sent and received data (thus estimating the last > > > >>>>known 'good' > > > > window), but that's a pain I'd prefer to avoid. > > > >>>>Any suggestions? > >> > >>>The IETF BEHAVE group has discussed recommendations from anywhere > >>> > > between 30 seconds > > > >>>>(http://list.sipfoundry.org/archive/ietf-behave/msg00441.html) > > > > and 15 > > > >>>>minutes > >>>>(http://list.sipfoundry.org/archive/ietf-behave/msg00127.html). > > > > But > > > >>>>ultimately those are foward-looking discussions, and therefore > > > > not > > > >>>>relevant. > >>>>In the real world, I've seen mention that even > > > > 30 seconds is > > > >>>>insufficient > >>>>(http://www.frameip.com/nntp/article-comp-protocols-tcp-ip.php?numero=20119). > > > > Perhaps 20 seconds works (http://www.tisc2001.com/newsletters/322.html), > > but who knows. > > > >>>>Basically, I'm curious what keepalives you've found work > > > > today in your > > > >>>>real applications, in the real world. > >>>>-david > >> > >>>_______________________________________________ > >>> > >>>>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 > > > > > _______________________________________________ > 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 verdimar at comp.nus.edu.sg Tue Jun 7 05:21:36 2005 From: verdimar at comp.nus.edu.sg (Verdi March) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] bigint.h in Chord Message-ID: <200506071321.36551.verdimar@comp.nus.edu.sg> Hi, can anyone with chord installation, please send me the bigint.h file? As I understand, this file is generated during build. However, the build requires sfs (which can consume up to 700MB according to Chord website), while I only need the header file as a reference. Thanks in advance. -- Regards, Verdi From ap at hamachi.cc Tue Jun 7 05:55:24 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts In-Reply-To: <1118086688.2235AA7A@dj11.dngr.org> References: <42A3ABEC.8070000@quinthar.com> <42A3AC7D.9040409@hamachi.cc> <1118086688.2235AA7A@dj11.dngr.org> Message-ID: <42A536CC.8000606@hamachi.cc> David Barrett wrote: > Ok, sounds like 20 seconds might be an upper limit, then. Are you using > "unconfirmed" keepalives, or bidirectional? Thanks for the info. > Both peers monitor for the activity and send the keepalive out if there were none with 15(?) seconds. The handshake protocol however is such that both peers send some traffic when the tunnel goes up, so I guess it can count as bidirectional. From wangyong at software.ict.ac.cn Tue Jun 7 06:07:36 2005 From: wangyong at software.ict.ac.cn (=?gb2312?B?zfXTwg==?=) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] NAT hole-punch keepalive/timeouts Message-ID: <20050607060729.372B83FD35@capsicum.zgp.org> aGkNCglJIGFtIHdyaXRpbmcgYSBwcm9ncmFtIG9mIGdudXRlbGxhIHNlcnZlbnQsIHdoZW4gSSBz ZW5kIHRoZSBoYW5kc2hha2luZyBtZXNzYWdlIHRvIHRoZSBnbnV0ZWxsYSBub2RlLCB0aGUgbm9k ZSB3aWxsIHNlbmQgYmFjayB0aGUgbWVzc2FnZSBvZiAiZ251dGVsbGEvMC42IDIwMCBPSyIsIGJ1 dCB0aGVuLCBpdCB3aWxsIGNsb3NlIHRoZSBjb25uZWN0aW9uLiB3aGF0IGlzIHRoZSBwcm9ibGVt Pw0KDQoJTXkgc2VudCBtZXNzYWdlIGlzIGxpa2U6DQoJCQlzdHJpbmcgY29ubmVjdFN0cmluZyA9 ICJHTlVURUxMQSBDT05ORUNULzAuNiIrQ1JMRg0KCQkJCQkJCQkJKyAiVXNlci1BZ2VudDogTGlt ZVdpcmUvMS40IitDUkxGDQoJCQkJCQkJCQkrICJWZW5kb3ItTWVzc2FnZTogMC4xIitDUkxGDQoJ CQkJCQkJCQkrICJHR0VQOiAwLjUiK0NSTEYNCgkJCQkJCQkJCSsgIkxpc3Rlbi1JUDogNjQuMTgw LjE4OS4xODo2MzQ5Ig0KCQkJCQkJCQkJKyB0aGlzLl9sb2NhbElQICsgIjoiK3RoaXMuX2xvY2Fs UG9ydCArIENSTEYNCgkJCQkJCQkJCSsgIlBvbmctQ2FjaGluZzogMC4xIitDUkxGDQoJCQkJCQkJ CQkrICJSZW1vdGUtSVA6ICIrIHRoaXMuX3JlbW90ZUlQK0NSTEYNCgkJCQkJCQkJCSsgQ1JMRjsN CiB0aGUgbm9kZSBzZW5kIGJhY2sgbWVzc2FnZSBsaWtlOg0KCQlHTlVURUxMQS8wLjYgMjAwIE9L DQoJCVgtVmVyc2lvbjogNC44DQoJCVBvbmctQ2FjaGluZzogMC4xDQoJCUFjY2VwdC1FbmNvZGlu ZzogZGVmbGF0ZQ0KCQlYLUxvY2FsZS1QcmVmOiBlbg0KCQlYLUd1ZXNzOiAwLjENCgkJQ29udGVu dC1FbmNvZGluZzogZGVmbGF0ZQ0KCQlYLU1heC1UVEw6IDMNCgkJVmVuZG9yLU1lc3NhZ2U6IDAu MQ0KCQlYLVVsdHJhcGVlci1RdWVyeS1Sb3V0aW5nOiAwLjENCgkJWC1RdWVyeS1Sb3V0aW5nOiAw LjENCgkJTGlzdGVuLUlQOiA2NC4xODAuMTg5LjE4OjYzNDYNCgkJWC1FeHQtUHJvYmVzOiAwLjEN CgkJUmVtb3RlLUlQOiAxNTkuMjI2LjQwLjMNCgkJR0dFUDogMC41DQoJCVgtRHluYW1pYy1RdWVy eWluZzogMC4xDQoJCVgtRGVncmVlOiAzMg0KCQlVc2VyLUFnZW50OiBMaW1lV2lyZS80LjguMQ0K CQlYLVVsdHJhcGVlcjogVHJ1ZQ0KCQlYLVRyeS1VbHRyYXBlZXJzOiAJCQkJMTU0LjUuMTkzLjE5 NTo2MzQ2LDI0LjE3Ny4xNzAuMTAxOjYzNDYsMjQuMTg4LjEzOC4yMzE6NjM0NiwyNC4xNy43LjIx OjYzNDYsMjQuNDMJCQkJLjg2LjE5NTo2MzQ2LDI0LjQ0LjM0LjE2Mjo2MzQ2LDI0LjkxLjE2OC40 ODo2MzQ2LDY4LjkuMjE0LjIzMDo2MzQ2LDE1MS4yMDMuMjE0LjQJCQkJMDo2MzQ4LDI0LjEyLjEx Ny4xNTU6NjM0OA0KDQoJdGhlbiB0aGUgbm9kZSBjbG9zZWQgdGhlIGNvbm5lY3Rpb24uIEkgd2Fu dCB0byBmaWd1cmUgb3V0IHdoYXQgaGFwcGVuZD8gaG93IGNvdWxkIEkgY29ubnRlY3QgdG8gZ251 dGVsbGEgY29ycmVjdGx5Pw0KDQoJYW55b25lIGNvdWxkIGhlbHAgbWU/DQoNCgkNCg0KPT09PT09 PSAyMDA1LTA2LTA3IDEzOjU1OjI0IMT61NrAtNDF1tDQtLXAo7o9PT09PT09DQoNCj4NCj4NCj5E YXZpZCBCYXJyZXR0IHdyb3RlOg0KPg0KPj4gT2ssIHNvdW5kcyBsaWtlIDIwIHNlY29uZHMgbWln aHQgYmUgYW4gdXBwZXIgbGltaXQsIHRoZW4uICBBcmUgeW91IHVzaW5nIA0KPj4gInVuY29uZmly bWVkIiBrZWVwYWxpdmVzLCBvciBiaWRpcmVjdGlvbmFsPyAgVGhhbmtzIGZvciB0aGUgaW5mby4N Cj4+IA0KPg0KPkJvdGggcGVlcnMgbW9uaXRvciBmb3IgdGhlIGFjdGl2aXR5IGFuZCBzZW5kIHRo ZSBrZWVwYWxpdmUgb3V0IGlmDQo+dGhlcmUgd2VyZSBub25lIHdpdGggMTUoPykgc2Vjb25kcy4g VGhlIGhhbmRzaGFrZSBwcm90b2NvbCBob3dldmVyDQo+aXMgc3VjaCB0aGF0IGJvdGggcGVlcnMg c2VuZCBzb21lIHRyYWZmaWMgd2hlbiB0aGUgdHVubmVsIGdvZXMgdXAsDQo+c28gSSBndWVzcyBp dCBjYW4gY291bnQgYXMgYmlkaXJlY3Rpb25hbC4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPnAycC1oYWNrZXJzIG1haWxpbmcgbGlzdA0KPnAycC1o YWNrZXJzQHpncC5vcmcNCj5odHRwOi8vemdwLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycC1oYWNr ZXJzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5I ZXJlIGlzIGEgd2ViIHBhZ2UgbGlzdGluZyBQMlAgQ29uZmVyZW5jZXM6DQo+aHR0cDovL3d3dy5u ZXVyb2dyaWQubmV0L3R3aWtpL2Jpbi92aWV3L01haW4vUGVlclRvUGVlckNvbmZlcmVuY2VzDQo+ DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQoNCqGhoaGh oaGhoaGhoaGhoaHWwg0KwPGjoQ0KIA0KCQkJCSANCqGhoaGhoaGhoaGhoaGhoaHN9dPCDQqhoaGh oaGhoaGhoaGhoaGhd2FuZ3lvbmdAc29mdHdhcmUuaWN0LmFjLmNuDQqhoaGhoaGhoaGhoaGhoaGh oaGhoTIwMDUtMDYtMDcNCg0K From wangyong at software.ict.ac.cn Tue Jun 7 06:08:07 2005 From: wangyong at software.ict.ac.cn (=?GB2312?B?zfXTwg==?=) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] about handshaking Message-ID: <20050607060801.328A13FD49@capsicum.zgp.org> aGkNCglJIGFtIHdyaXRpbmcgYSBwcm9ncmFtIG9mIGdudXRlbGxhIHNlcnZlbnQsIHdoZW4gSSBz ZW5kIHRoZSBoYW5kc2hha2luZyBtZXNzYWdlIHRvIHRoZSBnbnV0ZWxsYSBub2RlLCB0aGUgbm9k ZSB3aWxsIHNlbmQgYmFjayB0aGUgbWVzc2FnZSBvZiAiZ251dGVsbGEvMC42IDIwMCBPSyIsIGJ1 dCB0aGVuLCBpdCB3aWxsIGNsb3NlIHRoZSBjb25uZWN0aW9uLiB3aGF0IGlzIHRoZSBwcm9ibGVt Pw0KDQoJTXkgc2VudCBtZXNzYWdlIGlzIGxpa2U6DQoJCQlzdHJpbmcgY29ubmVjdFN0cmluZyA9 ICJHTlVURUxMQSBDT05ORUNULzAuNiIrQ1JMRg0KCQkJCQkJCQkJKyAiVXNlci1BZ2VudDogTGlt ZVdpcmUvMS40IitDUkxGDQoJCQkJCQkJCQkrICJWZW5kb3ItTWVzc2FnZTogMC4xIitDUkxGDQoJ CQkJCQkJCQkrICJHR0VQOiAwLjUiK0NSTEYNCgkJCQkJCQkJCSsgIkxpc3Rlbi1JUDogNjQuMTgw LjE4OS4xODo2MzQ5Ig0KCQkJCQkJCQkJKyB0aGlzLl9sb2NhbElQICsgIjoiK3RoaXMuX2xvY2Fs UG9ydCArIENSTEYNCgkJCQkJCQkJCSsgIlBvbmctQ2FjaGluZzogMC4xIitDUkxGDQoJCQkJCQkJ CQkrICJSZW1vdGUtSVA6ICIrIHRoaXMuX3JlbW90ZUlQK0NSTEYNCgkJCQkJCQkJCSsgQ1JMRjsN CiB0aGUgbm9kZSBzZW5kIGJhY2sgbWVzc2FnZSBsaWtlOg0KCQlHTlVURUxMQS8wLjYgMjAwIE9L DQoJCVgtVmVyc2lvbjogNC44DQoJCVBvbmctQ2FjaGluZzogMC4xDQoJCUFjY2VwdC1FbmNvZGlu ZzogZGVmbGF0ZQ0KCQlYLUxvY2FsZS1QcmVmOiBlbg0KCQlYLUd1ZXNzOiAwLjENCgkJQ29udGVu dC1FbmNvZGluZzogZGVmbGF0ZQ0KCQlYLU1heC1UVEw6IDMNCgkJVmVuZG9yLU1lc3NhZ2U6IDAu MQ0KCQlYLVVsdHJhcGVlci1RdWVyeS1Sb3V0aW5nOiAwLjENCgkJWC1RdWVyeS1Sb3V0aW5nOiAw LjENCgkJTGlzdGVuLUlQOiA2NC4xODAuMTg5LjE4OjYzNDYNCgkJWC1FeHQtUHJvYmVzOiAwLjEN CgkJUmVtb3RlLUlQOiAxNTkuMjI2LjQwLjMNCgkJR0dFUDogMC41DQoJCVgtRHluYW1pYy1RdWVy eWluZzogMC4xDQoJCVgtRGVncmVlOiAzMg0KCQlVc2VyLUFnZW50OiBMaW1lV2lyZS80LjguMQ0K CQlYLVVsdHJhcGVlcjogVHJ1ZQ0KCQlYLVRyeS1VbHRyYXBlZXJzOiAJCQkJMTU0LjUuMTkzLjE5 NTo2MzQ2LDI0LjE3Ny4xNzAuMTAxOjYzNDYsMjQuMTg4LjEzOC4yMzE6NjM0NiwyNC4xNy43LjIx OjYzNDYsMjQuNDMJCQkJLjg2LjE5NTo2MzQ2LDI0LjQ0LjM0LjE2Mjo2MzQ2LDI0LjkxLjE2OC40 ODo2MzQ2LDY4LjkuMjE0LjIzMDo2MzQ2LDE1MS4yMDMuMjE0LjQJCQkJMDo2MzQ4LDI0LjEyLjEx Ny4xNTU6NjM0OA0KDQoJdGhlbiB0aGUgbm9kZSBjbG9zZWQgdGhlIGNvbm5lY3Rpb24uIEkgd2Fu dCB0byBmaWd1cmUgb3V0IHdoYXQgaGFwcGVuZD8gaG93IGNvdWxkIEkgY29ubnRlY3QgdG8gZ251 dGVsbGEgY29ycmVjdGx5Pw0KDQoJYW55b25lIGNvdWxkIGhlbHAgbWU/DQoNCgkNCg0KPT09PT09 PSAyMDA1LTA2LTA3IDEzOjU1OjI0IMT61NrAtNDF1tDQtLXAo7o9PT09PT09DQoNCj4NCj4NCj5E YXZpZCBCYXJyZXR0IHdyb3RlOg0KPg0KPj4gT2ssIHNvdW5kcyBsaWtlIDIwIHNlY29uZHMgbWln aHQgYmUgYW4gdXBwZXIgbGltaXQsIHRoZW4uICBBcmUgeW91IHVzaW5nIA0KPj4gInVuY29uZmly bWVkIiBrZWVwYWxpdmVzLCBvciBiaWRpcmVjdGlvbmFsPyAgVGhhbmtzIGZvciB0aGUgaW5mby4N Cj4+IA0KPg0KPkJvdGggcGVlcnMgbW9uaXRvciBmb3IgdGhlIGFjdGl2aXR5IGFuZCBzZW5kIHRo ZSBrZWVwYWxpdmUgb3V0IGlmDQo+dGhlcmUgd2VyZSBub25lIHdpdGggMTUoPykgc2Vjb25kcy4g VGhlIGhhbmRzaGFrZSBwcm90b2NvbCBob3dldmVyDQo+aXMgc3VjaCB0aGF0IGJvdGggcGVlcnMg c2VuZCBzb21lIHRyYWZmaWMgd2hlbiB0aGUgdHVubmVsIGdvZXMgdXAsDQo+c28gSSBndWVzcyBp dCBjYW4gY291bnQgYXMgYmlkaXJlY3Rpb25hbC4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPnAycC1oYWNrZXJzIG1haWxpbmcgbGlzdA0KPnAycC1o YWNrZXJzQHpncC5vcmcNCj5odHRwOi8vemdwLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycC1oYWNr ZXJzDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5I ZXJlIGlzIGEgd2ViIHBhZ2UgbGlzdGluZyBQMlAgQ29uZmVyZW5jZXM6DQo+aHR0cDovL3d3dy5u ZXVyb2dyaWQubmV0L3R3aWtpL2Jpbi92aWV3L01haW4vUGVlclRvUGVlckNvbmZlcmVuY2VzDQo+ DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQoNCqGhoaGh oaGhoaGhoaGhoaHWwg0KwPGjoQ0KIA0KCQkJCSANCqGhoaGhoaGhoaGhoaGhoaHN9dPCDQqhoaGh oaGhoaGhoaGhoaGhd2FuZ3lvbmdAc29mdHdhcmUuaWN0LmFjLmNuDQqhoaGhoaGhoaGhoaGhoaGh oaGhoTIwMDUtMDYtMDcNCg0K From dcarboni at gmail.com Tue Jun 7 08:06:24 2005 From: dcarboni at gmail.com (Davide Carboni) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] about handshaking In-Reply-To: <20050607060801.328A13FD49@capsicum.zgp.org> References: <20050607060801.328A13FD49@capsicum.zgp.org> Message-ID: <71b79fa9050607010619799848@mail.gmail.com> TWF5YmUgeW91ciBub2RlIGRvZXMgbm90IHJlc3BvbmRlIHRvIHBpbmcgbWVzc2FnZXMuIFRyeSB0 byBjb25uZWN0CnlvdXIgcHJvZ3JhbSB0byBhbiBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbiBs aWtlCmh0dHA6Ly9waGV4LmtvdWsuZGUvbWFtYm8vIHRoZW4gdHJ5IHRvIGZpZ3VyZSBvdXQgd2hh dCBpcyBnb2luZyBvbi4KCk9uIDYvNy8wNSwgzfXTwiA8d2FuZ3lvbmdAc29mdHdhcmUuaWN0LmFj LmNuPiB3cm90ZToKPiBoaQo+ICAgICAgICAgSSBhbSB3cml0aW5nIGEgcHJvZ3JhbSBvZiBnbnV0 ZWxsYSBzZXJ2ZW50LCB3aGVuIEkgc2VuZCB0aGUgaGFuZHNoYWtpbmcgbWVzc2FnZSB0byB0aGUg Z251dGVsbGEgbm9kZSwgdGhlIG5vZGUgd2lsbCBzZW5kIGJhY2sgdGhlIG1lc3NhZ2Ugb2YgImdu dXRlbGxhLzAuNiAyMDAgT0siLCBidXQgdGhlbiwgaXQgd2lsbCBjbG9zZSB0aGUgY29ubmVjdGlv bi4gd2hhdCBpcyB0aGUgcHJvYmxlbT8KPiAKPiAgICAgICAgIE15IHNlbnQgbWVzc2FnZSBpcyBs aWtlOgo+ICAgICAgICAgICAgICAgICAgICAgICAgIHN0cmluZyBjb25uZWN0U3RyaW5nID0gIkdO VVRFTExBIENPTk5FQ1QvMC42IitDUkxGCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyAiVXNlci1BZ2VudDog TGltZVdpcmUvMS40IitDUkxGCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyAiVmVuZG9yLU1lc3NhZ2U6IDAu MSIrQ1JMRgo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICsgIkdHRVA6IDAuNSIrQ1JMRgo+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICsgIkxpc3Rlbi1JUDogNjQuMTgwLjE4OS4xODo2MzQ5Igo+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsg dGhpcy5fbG9jYWxJUCArICI6Iit0aGlzLl9sb2NhbFBvcnQgKyBDUkxGCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKyAiUG9uZy1DYWNoaW5nOiAwLjEiK0NSTEYKPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArICJSZW1vdGUt SVA6ICIrIHRoaXMuX3JlbW90ZUlQK0NSTEYKPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArIENSTEY7Cj4gIHRo ZSBub2RlIHNlbmQgYmFjayBtZXNzYWdlIGxpa2U6Cj4gICAgICAgICAgICAgICAgIEdOVVRFTExB LzAuNiAyMDAgT0sKPiAgICAgICAgICAgICAgICAgWC1WZXJzaW9uOiA0LjgKPiAgICAgICAgICAg ICAgICAgUG9uZy1DYWNoaW5nOiAwLjEKPiAgICAgICAgICAgICAgICAgQWNjZXB0LUVuY29kaW5n OiBkZWZsYXRlCj4gICAgICAgICAgICAgICAgIFgtTG9jYWxlLVByZWY6IGVuCj4gICAgICAgICAg ICAgICAgIFgtR3Vlc3M6IDAuMQo+ICAgICAgICAgICAgICAgICBDb250ZW50LUVuY29kaW5nOiBk ZWZsYXRlCj4gICAgICAgICAgICAgICAgIFgtTWF4LVRUTDogMwo+ICAgICAgICAgICAgICAgICBW ZW5kb3ItTWVzc2FnZTogMC4xCj4gICAgICAgICAgICAgICAgIFgtVWx0cmFwZWVyLVF1ZXJ5LVJv dXRpbmc6IDAuMQo+ICAgICAgICAgICAgICAgICBYLVF1ZXJ5LVJvdXRpbmc6IDAuMQo+ICAgICAg ICAgICAgICAgICBMaXN0ZW4tSVA6IDY0LjE4MC4xODkuMTg6NjM0Ngo+ICAgICAgICAgICAgICAg ICBYLUV4dC1Qcm9iZXM6IDAuMQo+ICAgICAgICAgICAgICAgICBSZW1vdGUtSVA6IDE1OS4yMjYu NDAuMwo+ICAgICAgICAgICAgICAgICBHR0VQOiAwLjUKPiAgICAgICAgICAgICAgICAgWC1EeW5h bWljLVF1ZXJ5aW5nOiAwLjEKPiAgICAgICAgICAgICAgICAgWC1EZWdyZWU6IDMyCj4gICAgICAg ICAgICAgICAgIFVzZXItQWdlbnQ6IExpbWVXaXJlLzQuOC4xCj4gICAgICAgICAgICAgICAgIFgt VWx0cmFwZWVyOiBUcnVlCj4gICAgICAgICAgICAgICAgIFgtVHJ5LVVsdHJhcGVlcnM6ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDE1NC41LjE5My4xOTU6NjM0NiwyNC4xNzcuMTcwLjEw MTo2MzQ2LDI0LjE4OC4xMzguMjMxOjYzNDYsMjQuMTcuNy4yMTo2MzQ2LDI0LjQzICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAuODYuMTk1OjYzNDYsMjQuNDQuMzQuMTYyOjYzNDYsMjQu OTEuMTY4LjQ4OjYzNDYsNjguOS4yMTQuMjMwOjYzNDYsMTUxLjIwMy4yMTQuNCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgMDo2MzQ4LDI0LjEyLjExNy4xNTU6NjM0OAo+IAo+ICAgICAg ICAgdGhlbiB0aGUgbm9kZSBjbG9zZWQgdGhlIGNvbm5lY3Rpb24uIEkgd2FudCB0byBmaWd1cmUg b3V0IHdoYXQgaGFwcGVuZD8gaG93IGNvdWxkIEkgY29ubnRlY3QgdG8gZ251dGVsbGEgY29ycmVj dGx5Pwo+IAo+ICAgICAgICAgYW55b25lIGNvdWxkIGhlbHAgbWU/Cj4gCj4gCj4gCj4gPT09PT09 PSAyMDA1LTA2LTA3IDEzOjU1OjI0IMT61NrAtNDF1tDQtLXAo7o9PT09PT09Cj4gCj4gPgo+ID4K PiA+RGF2aWQgQmFycmV0dCB3cm90ZToKPiA+Cj4gPj4gT2ssIHNvdW5kcyBsaWtlIDIwIHNlY29u ZHMgbWlnaHQgYmUgYW4gdXBwZXIgbGltaXQsIHRoZW4uICBBcmUgeW91IHVzaW5nCj4gPj4gInVu Y29uZmlybWVkIiBrZWVwYWxpdmVzLCBvciBiaWRpcmVjdGlvbmFsPyAgVGhhbmtzIGZvciB0aGUg aW5mby4KPiA+Pgo+ID4KPiA+Qm90aCBwZWVycyBtb25pdG9yIGZvciB0aGUgYWN0aXZpdHkgYW5k IHNlbmQgdGhlIGtlZXBhbGl2ZSBvdXQgaWYKPiA+dGhlcmUgd2VyZSBub25lIHdpdGggMTUoPykg c2Vjb25kcy4gVGhlIGhhbmRzaGFrZSBwcm90b2NvbCBob3dldmVyCj4gPmlzIHN1Y2ggdGhhdCBi b3RoIHBlZXJzIHNlbmQgc29tZSB0cmFmZmljIHdoZW4gdGhlIHR1bm5lbCBnb2VzIHVwLAo+ID5z byBJIGd1ZXNzIGl0IGNhbiBjb3VudCBhcyBiaWRpcmVjdGlvbmFsLgo+ID5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ID5wMnAtaGFja2VycyBtYWlsaW5n IGxpc3QKPiA+cDJwLWhhY2tlcnNAemdwLm9yZwo+ID5odHRwOi8vemdwLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3AycC1oYWNrZXJzCj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fCj4gPkhlcmUgaXMgYSB3ZWIgcGFnZSBsaXN0aW5nIFAyUCBDb25mZXJlbmNl czoKPiA+aHR0cDovL3d3dy5uZXVyb2dyaWQubmV0L3R3aWtpL2Jpbi92aWV3L01haW4vUGVlclRv UGVlckNvbmZlcmVuY2VzCj4gPgo+IAo+ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0g PSA9ID0gPQo+IAo+IAo+INbCCj4gwPGjoQo+IAo+IAo+IM3108IKPiB3YW5neW9uZ0Bzb2Z0d2Fy ZS5pY3QuYWMuY24KPiAyMDA1LTA2LTA3Cj4gCj4gCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18KPiBwMnAtaGFja2VycyBtYWlsaW5nIGxpc3QKPiBwMnAt aGFja2Vyc0B6Z3Aub3JnCj4gaHR0cDovL3pncC5vcmcvbWFpbG1hbi9saXN0aW5mby9wMnAtaGFj a2Vycwo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4g SGVyZSBpcyBhIHdlYiBwYWdlIGxpc3RpbmcgUDJQIENvbmZlcmVuY2VzOgo+IGh0dHA6Ly93d3cu bmV1cm9ncmlkLm5ldC90d2lraS9iaW4vdmlldy9NYWluL1BlZXJUb1BlZXJDb25mZXJlbmNlcwo+ IAo+IAo+IAoKCi0tIApJIGhhdmUgbWFkZSB0aGlzIGxldHRlciBsb25nZXIgdGhhbiB1c3VhbCBi ZWNhdXNlIEkgbGFjayB0aGUgdGltZSB0bwptYWtlIGl0IHNob3J0ZXIuCkIuIFBhc2NhbAo= From wangyong at software.ict.ac.cn Tue Jun 7 08:18:10 2005 From: wangyong at software.ict.ac.cn (=?GB2312?B?zfXTwg==?=) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] about handshaking Message-ID: <20050607081924.2E1BE3FC98@capsicum.zgp.org> aGkNCgl5b3UgbWVhbnMgdGhhdCBteSBub2RlIG11c3QgcmVwb25kIHRvIHBpbmcgbWVzc2FnZSBk dWlyaW5nIHNoYWtpbmcgaGFuZHMgd2l0aCBvdGhlciBub2Rlcz8NCg0KCQ0KDQo9PT09PT09IDIw MDUtMDYtMDcgMTY6MDY6MjQgxPrU2sC00MXW0NC0tcCjuj09PT09PT0NCg0KPk1heWJlIHlvdXIg bm9kZSBkb2VzIG5vdCByZXNwb25kZSB0byBwaW5nIG1lc3NhZ2VzLiBUcnkgdG8gY29ubmVjdA0K PnlvdXIgcHJvZ3JhbSB0byBhbiBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbiBsaWtlDQo+aHR0 cDovL3BoZXgua291ay5kZS9tYW1iby8gdGhlbiB0cnkgdG8gZmlndXJlIG91dCB3aGF0IGlzIGdv aW5nIG9uLg0KPg0KPk9uIDYvNy8wNSwgzfXTwiA8d2FuZ3lvbmdAc29mdHdhcmUuaWN0LmFjLmNu PiB3cm90ZToNCj4+IGhpDQo+PiAgICAgICAgIEkgYW0gd3JpdGluZyBhIHByb2dyYW0gb2YgZ251 dGVsbGEgc2VydmVudCwgd2hlbiBJIHNlbmQgdGhlIGhhbmRzaGFraW5nIG1lc3NhZ2UgdG8gdGhl IGdudXRlbGxhIG5vZGUsIHRoZSBub2RlIHdpbGwgc2VuZCBiYWNrIHRoZSBtZXNzYWdlIG9mICJn bnV0ZWxsYS8wLjYgMjAwIE9LIiwgYnV0IHRoZW4sIGl0IHdpbGwgY2xvc2UgdGhlIGNvbm5lY3Rp b24uIHdoYXQgaXMgdGhlIHByb2JsZW0/DQo+PiANCj4+ICAgICAgICAgTXkgc2VudCBtZXNzYWdl IGlzIGxpa2U6DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcgY29ubmVjdFN0cmlu ZyA9ICJHTlVURUxMQSBDT05ORUNULzAuNiIrQ1JMRg0KPj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKyAiVXNl ci1BZ2VudDogTGltZVdpcmUvMS40IitDUkxGDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArICJWZW5kb3It TWVzc2FnZTogMC4xIitDUkxGDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArICJHR0VQOiAwLjUiK0NSTEYN Cj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICsgIkxpc3Rlbi1JUDogNjQuMTgwLjE4OS4xODo2MzQ5Ig0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKyB0aGlzLl9sb2NhbElQICsgIjoiK3RoaXMuX2xvY2FsUG9ydCArIENS TEYNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICsgIlBvbmctQ2FjaGluZzogMC4xIitDUkxGDQo+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICArICJSZW1vdGUtSVA6ICIrIHRoaXMuX3JlbW90ZUlQK0NSTEYNCj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICsgQ1JMRjsNCj4+ICB0aGUgbm9kZSBzZW5kIGJhY2sgbWVzc2FnZSBsaWtlOg0K Pj4gICAgICAgICAgICAgICAgIEdOVVRFTExBLzAuNiAyMDAgT0sNCj4+ICAgICAgICAgICAgICAg ICBYLVZlcnNpb246IDQuOA0KPj4gICAgICAgICAgICAgICAgIFBvbmctQ2FjaGluZzogMC4xDQo+ PiAgICAgICAgICAgICAgICAgQWNjZXB0LUVuY29kaW5nOiBkZWZsYXRlDQo+PiAgICAgICAgICAg ICAgICAgWC1Mb2NhbGUtUHJlZjogZW4NCj4+ICAgICAgICAgICAgICAgICBYLUd1ZXNzOiAwLjEN Cj4+ICAgICAgICAgICAgICAgICBDb250ZW50LUVuY29kaW5nOiBkZWZsYXRlDQo+PiAgICAgICAg ICAgICAgICAgWC1NYXgtVFRMOiAzDQo+PiAgICAgICAgICAgICAgICAgVmVuZG9yLU1lc3NhZ2U6 IDAuMQ0KPj4gICAgICAgICAgICAgICAgIFgtVWx0cmFwZWVyLVF1ZXJ5LVJvdXRpbmc6IDAuMQ0K Pj4gICAgICAgICAgICAgICAgIFgtUXVlcnktUm91dGluZzogMC4xDQo+PiAgICAgICAgICAgICAg ICAgTGlzdGVuLUlQOiA2NC4xODAuMTg5LjE4OjYzNDYNCj4+ICAgICAgICAgICAgICAgICBYLUV4 dC1Qcm9iZXM6IDAuMQ0KPj4gICAgICAgICAgICAgICAgIFJlbW90ZS1JUDogMTU5LjIyNi40MC4z DQo+PiAgICAgICAgICAgICAgICAgR0dFUDogMC41DQo+PiAgICAgICAgICAgICAgICAgWC1EeW5h bWljLVF1ZXJ5aW5nOiAwLjENCj4+ICAgICAgICAgICAgICAgICBYLURlZ3JlZTogMzINCj4+ICAg ICAgICAgICAgICAgICBVc2VyLUFnZW50OiBMaW1lV2lyZS80LjguMQ0KPj4gICAgICAgICAgICAg ICAgIFgtVWx0cmFwZWVyOiBUcnVlDQo+PiAgICAgICAgICAgICAgICAgWC1UcnktVWx0cmFwZWVy czogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTU0LjUuMTkzLjE5NTo2MzQ2LDI0LjE3 Ny4xNzAuMTAxOjYzNDYsMjQuMTg4LjEzOC4yMzE6NjM0NiwyNC4xNy43LjIxOjYzNDYsMjQuNDMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC44Ni4xOTU6NjM0NiwyNC40NC4zNC4xNjI6 NjM0NiwyNC45MS4xNjguNDg6NjM0Niw2OC45LjIxNC4yMzA6NjM0NiwxNTEuMjAzLjIxNC40ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwOjYzNDgsMjQuMTIuMTE3LjE1NTo2MzQ4DQo+ PiANCj4+ICAgICAgICAgdGhlbiB0aGUgbm9kZSBjbG9zZWQgdGhlIGNvbm5lY3Rpb24uIEkgd2Fu dCB0byBmaWd1cmUgb3V0IHdoYXQgaGFwcGVuZD8gaG93IGNvdWxkIEkgY29ubnRlY3QgdG8gZ251 dGVsbGEgY29ycmVjdGx5Pw0KPj4gDQo+PiAgICAgICAgIGFueW9uZSBjb3VsZCBoZWxwIG1lPw0K Pj4gDQo+PiANCj4+IA0KPj4gPT09PT09PSAyMDA1LTA2LTA3IDEzOjU1OjI0IMT61NrAtNDF1tDQ tLXAo7o9PT09PT09DQo+PiANCj4+ID4NCj4+ID4NCj4+ID5EYXZpZCBCYXJyZXR0IHdyb3RlOg0K Pj4gPg0KPj4gPj4gT2ssIHNvdW5kcyBsaWtlIDIwIHNlY29uZHMgbWlnaHQgYmUgYW4gdXBwZXIg bGltaXQsIHRoZW4uICBBcmUgeW91IHVzaW5nDQo+PiA+PiAidW5jb25maXJtZWQiIGtlZXBhbGl2 ZXMsIG9yIGJpZGlyZWN0aW9uYWw/ICBUaGFua3MgZm9yIHRoZSBpbmZvLg0KPj4gPj4NCj4+ID4N Cj4+ID5Cb3RoIHBlZXJzIG1vbml0b3IgZm9yIHRoZSBhY3Rpdml0eSBhbmQgc2VuZCB0aGUga2Vl cGFsaXZlIG91dCBpZg0KPj4gPnRoZXJlIHdlcmUgbm9uZSB3aXRoIDE1KD8pIHNlY29uZHMuIFRo ZSBoYW5kc2hha2UgcHJvdG9jb2wgaG93ZXZlcg0KPj4gPmlzIHN1Y2ggdGhhdCBib3RoIHBlZXJz IHNlbmQgc29tZSB0cmFmZmljIHdoZW4gdGhlIHR1bm5lbCBnb2VzIHVwLA0KPj4gPnNvIEkgZ3Vl c3MgaXQgY2FuIGNvdW50IGFzIGJpZGlyZWN0aW9uYWwuDQo+PiA+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5wMnAtaGFja2VycyBtYWlsaW5nIGxp c3QNCj4+ID5wMnAtaGFja2Vyc0B6Z3Aub3JnDQo+PiA+aHR0cDovL3pncC5vcmcvbWFpbG1hbi9s aXN0aW5mby9wMnAtaGFja2Vycw0KPj4gPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiA+SGVyZSBpcyBhIHdlYiBwYWdlIGxpc3RpbmcgUDJQIENvbmZl cmVuY2VzOg0KPj4gPmh0dHA6Ly93d3cubmV1cm9ncmlkLm5ldC90d2lraS9iaW4vdmlldy9NYWlu L1BlZXJUb1BlZXJDb25mZXJlbmNlcw0KPj4gPg0KPj4gDQo+PiA9ID0gPSA9ID0gPSA9ID0gPSA9 ID0gPSA9ID0gPSA9ID0gPSA9ID0NCj4+IA0KPj4gDQo+PiDWwg0KPj4gwPGjoQ0KPj4gDQo+PiAN Cj4+IM3108INCj4+IHdhbmd5b25nQHNvZnR3YXJlLmljdC5hYy5jbg0KPj4gMjAwNS0wNi0wNw0K Pj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBwMnAtaGFja2VycyBtYWlsaW5nIGxpc3QNCj4+IHAycC1oYWNrZXJzQHpncC5vcmcN Cj4+IGh0dHA6Ly96Z3Aub3JnL21haWxtYW4vbGlzdGluZm8vcDJwLWhhY2tlcnMNCj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBIZXJlIGlzIGEg d2ViIHBhZ2UgbGlzdGluZyBQMlAgQ29uZmVyZW5jZXM6DQo+PiBodHRwOi8vd3d3Lm5ldXJvZ3Jp ZC5uZXQvdHdpa2kvYmluL3ZpZXcvTWFpbi9QZWVyVG9QZWVyQ29uZmVyZW5jZXMNCj4+IA0KPj4g DQo+PiANCj4NCj4NCj4tLSANCj5JIGhhdmUgbWFkZSB0aGlzIGxldHRlciBsb25nZXIgdGhhbiB1 c3VhbCBiZWNhdXNlIEkgbGFjayB0aGUgdGltZSB0bw0KPm1ha2UgaXQgc2hvcnRlci4NCj5CLiBQ YXNjYWwNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PnAycC1oYWNrZXJzIG1haWxpbmcgbGlzdA0KPnAycC1oYWNrZXJzQHpncC5vcmcNCj5odHRwOi8v emdwLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3AycC1oYWNrZXJzDQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5IZXJlIGlzIGEgd2ViIHBhZ2UgbGlzdGlu ZyBQMlAgQ29uZmVyZW5jZXM6DQo+aHR0cDovL3d3dy5uZXVyb2dyaWQubmV0L3R3aWtpL2Jpbi92 aWV3L01haW4vUGVlclRvUGVlckNvbmZlcmVuY2VzDQo+DQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0g PSA9ID0gPSA9ID0gPSA9ID0gPQ0KCQkJDQoNCqGhoaGhoaGhoaGhoaGhoaHWwg0KwPGjoQ0KIA0K CQkJCSANCqGhoaGhoaGhoaGhoaGhoaHN9dPCDQqhoaGhoaGhoaGhoaGhoaGhd2FuZ3lvbmdAc29m dHdhcmUuaWN0LmFjLmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDYtMDcNCg0K From larytet.8753341 at bloglines.com Tue Jun 7 22:40:19 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] firewall firebox from WatchGuard Message-ID: <1118184019.3845505918.9286.sendItem@bloglines.com> hi, does anybody have access to this box ? i want to know how DNS works. is this firewall statefull and terminates all DNS requests on the internal "wall" and resends them to the "enlisted" DNS server ? + any other information is greatly appreciated. thank you, arkady From lazyfine at hotmail.com Wed Jun 8 00:20:56 2005 From: lazyfine at hotmail.com (B fine) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] 'help' In-Reply-To: <20050607190006.0DB9A3FD6D@capsicum.zgp.org> Message-ID: 'help' _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From codewarrior at cuseeme.de Wed Jun 8 17:57:30 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem Message-ID: <299DE8B4-B5B5-4918-B048-6469616D2FC4@cuseeme.de> dear p2p hackers, due to the massive influence from tycoon firms, and the ongoing software patents disscussion in europe and the pressure from the mpaa.org/ on bittorrent users i thought there is a strong need for "Opencuseeme" the first free peer2peer multiconferencing tool. we need developers check it out www.cuseeme.de ******************************************************** opencuseeme / peer2peer multiparty conferencing ******************************************************** I found an java reflector http://www.linc.or.jp/~hamano/PMRef.html and installed it on my osx machine the docu said i could connect with vchat http://vchat.cu-seeme.org/download.html or any other client http://www.inforoots.org:8080/internet/cuseeme/ to the POORMANREF running on the same machine. The questions is i CAN connect to my reflector . but it seems to be NOT working from outside i am on DMZ , my ports are open cuseeme.dyndns.tv CID 0 MaxSend 150 Max Rec, 200 my other reflector on a static adress seems to be working: 207.44.156.3 MaxSend 14 Max Rec 40 any help would be greatly appreciatet regards www.cuseeme.de ******************************************************** opencuseeme / peer2peer multiparty conferencing ******************************************************** From lemonobrien at yahoo.com Wed Jun 8 18:10:55 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem In-Reply-To: <299DE8B4-B5B5-4918-B048-6469616D2FC4@cuseeme.de> Message-ID: <20050608181055.43088.qmail@web53608.mail.yahoo.com> i develop in peer-to-peer system in C++, but i'm not going to develop for free. people need to eat. codewarrior@cuseeme.de wrote:dear p2p hackers, due to the massive influence from tycoon firms, and the ongoing software patents disscussion in europe and the pressure from the mpaa.org/ on bittorrent users i thought there is a strong need for "Opencuseeme" the first free peer2peer multiconferencing tool. we need developers check it out www.cuseeme.de ******************************************************** opencuseeme / peer2peer multiparty conferencing ******************************************************** I found an java reflector http://www.linc.or.jp/~hamano/PMRef.html and installed it on my osx machine the docu said i could connect with vchat http://vchat.cu-seeme.org/download.html or any other client http://www.inforoots.org:8080/internet/cuseeme/ to the POORMANREF running on the same machine. The questions is i CAN connect to my reflector . but it seems to be NOT working from outside i am on DMZ , my ports are open cuseeme.dyndns.tv CID 0 MaxSend 150 Max Rec, 200 my other reflector on a static adress seems to be working: 207.44.156.3 MaxSend 14 Max Rec 40 any help would be greatly appreciatet regards www.cuseeme.de ******************************************************** opencuseeme / peer2peer multiparty conferencing ******************************************************** _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Discover Yahoo! Have fun online with music videos, cool games, IM & more. Check it out! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050608/459d0338/attachment.htm From rabbi at abditum.com Wed Jun 8 18:19:00 2005 From: rabbi at abditum.com (Len Sassaman) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem In-Reply-To: <20050608181055.43088.qmail@web53608.mail.yahoo.com> References: <20050608181055.43088.qmail@web53608.mail.yahoo.com> Message-ID: This fellow has been spamming lists for open source applications that have nothing to do with P2P, also. I'm doubting he'll find help this way. On Wed, 8 Jun 2005, Lemon Obrien wrote: > i develop in peer-to-peer system in C++, but i'm not going to develop for free. people need to eat. > > codewarrior@cuseeme.de wrote:dear p2p hackers, > due to the massive influence from tycoon firms, > and the ongoing software patents disscussion > in europe and the pressure from the > mpaa.org/ on bittorrent users i thought > there is a strong need for "Opencuseeme" > the first free peer2peer multiconferencing tool. > > we need developers > > check it out > > www.cuseeme.de > ******************************************************** > opencuseeme / peer2peer multiparty conferencing > ******************************************************** > > I found an java reflector http://www.linc.or.jp/~hamano/PMRef.html > > and installed it on my osx machine the docu said i could connect > with vchat http://vchat.cu-seeme.org/download.html or any other client > > http://www.inforoots.org:8080/internet/cuseeme/ > > to the POORMANREF running on the same machine. > > The questions is i CAN connect to my reflector > . > but it seems to be NOT working from outside > i am on DMZ , my ports are open > > cuseeme.dyndns.tv CID 0 > MaxSend 150 > Max Rec, 200 > my other reflector on a static adress seems to be working: > 207.44.156.3 > MaxSend 14 > Max Rec 40 > > > > any help would be greatly appreciatet > > regards > > > > www.cuseeme.de > ******************************************************** > opencuseeme / peer2peer multiparty conferencing > ******************************************************** > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > > You don't get no juice unless you squeeze > Lemon Obrien, the Third. > > --------------------------------- > Discover Yahoo! > Have fun online with music videos, cool games, IM & more. Check it out! --Len. From codewarrior at cuseeme.de Wed Jun 8 18:26:26 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem In-Reply-To: References: <20050608181055.43088.qmail@web53608.mail.yahoo.com> Message-ID: On Jun 8, 2005, at 8:19 PM, Len Sassaman wrote: > This fellow has been spamming lists for open source applications > that have > nothing to do with P2P, also. I'm doubting he'll find help this way. > len , lemon, experts do you really know what i am talking about or you are just want to start a flame war? cheers marc > On Wed, 8 Jun 2005, Lemon Obrien wrote: > > >> i develop in peer-to-peer system in C++, but i'm not going to >> develop for free. people need to eat. >> >> check it out >> >> www.cuseeme.de >> ******************************************************** >> opencuseeme / peer2peer multiparty conferencing >> ******************************************************** > --Len. > From lemonobrien at yahoo.com Wed Jun 8 18:34:46 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem In-Reply-To: Message-ID: <20050608183447.51716.qmail@web53608.mail.yahoo.com> i charge 10,000 (USD) a month. i tried to download the source code for windows...could not. I remember this program from the late 90s. It was mostly for Macs; the Mac source code is probably unusable...but i developed for apple in the late 90s so i could figure it out. i'm currenlty making a desktop commerce system (peer-to-peer). I created my own library j--, which emulates java using c++. I hate *slow* software. anyway codewarrior@cuseeme.de wrote: On Jun 8, 2005, at 8:19 PM, Len Sassaman wrote: > This fellow has been spamming lists for open source applications > that have > nothing to do with P2P, also. I'm doubting he'll find help this way. > len , lemon, experts do you really know what i am talking about or you are just want to start a flame war? cheers marc > On Wed, 8 Jun 2005, Lemon Obrien wrote: > > >> i develop in peer-to-peer system in C++, but i'm not going to >> develop for free. people need to eat. >> >> check it out >> >> www.cuseeme.de >> ******************************************************** >> opencuseeme / peer2peer multiparty conferencing >> ******************************************************** > --Len. > _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050608/2bb2d865/attachment.html From mgp at ucla.edu Wed Jun 8 18:38:58 2005 From: mgp at ucla.edu (Michael Parker) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem In-Reply-To: <20050608183447.51716.qmail@web53608.mail.yahoo.com> References: <20050608183447.51716.qmail@web53608.mail.yahoo.com> Message-ID: <42A73B42.7060500@ucla.edu> Oh, so we _are_ starting a flame war? ;-) - Mike Lemon Obrien wrote: > I created my own library j--, which emulates java using c++. I hate > *slow* software. > > > */codewarrior@cuseeme.de/* wrote: > > do you really know what i am talking about or you are just > want to start > a flame war? > From codewarrior at cuseeme.de Wed Jun 8 18:51:27 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem In-Reply-To: <20050608183447.51716.qmail@web53608.mail.yahoo.com> References: <20050608183447.51716.qmail@web53608.mail.yahoo.com> Message-ID: <30979DE7-779F-4501-B2F1-47271D7C7826@cuseeme.de> On Jun 8, 2005, at 8:34 PM, Lemon Obrien wrote: > > i tried to download the source code for windows...could not. this guy too http://baby.indstate.edu/CU-SeeMe/devl_archives/apr_98/0169.html :-) > I remember this program from the late 90s. It was mostly for Macs; > the Mac source code is probably unusable...but i developed for > apple in the late 90s so i could figure it out. nice , i want to re-open it again beacause nothing like this exists at this time. > i'm currenlty making a desktop commerce system (peer-to-peer). I > created my own library j--, which emulates java using c++. I hate > *slow* software. i am , a cuseeme user from the first hour , but i made different business during the years. At the end of 2000 i mentioned a big loss of reflectors so i started to research . I get in contact with michael sattler the writer of the book and several guys that are involved in development but noone had the client source code . As far as i know was the 0.6 version free and my aim is to make a free peer 2 peer application like skype for multiparty video without any costs. As soon as tyler hacked some of the old reflector source we could work on the client. i found a lot of stuff the i dokumented on my page even stuff that i found thru the www.waybackmachine.com > > anyway thanks you marc > > > codewarrior@cuseeme.de wrote: > > On Jun 8, 2005, at 8:19 PM, Len Sassaman wrote: > > > This fellow has been spamming lists for open source applications > > that have > > nothing to do with P2P, also. I'm doubting he'll find help this way. > > > > len , lemon, experts > > do you really know what i am talking about or you are just > want to start > a flame war? > > cheers > > marc > > > On Wed, 8 Jun 2005, Lemon Obrien wrote: > > > > > >> i develop in peer-to-peer system in C++, but i'm not going to > >> develop for free. people need to eat. > >> > >> check it out > >> > >> www.cuseeme.de > >> ******************************************************** > >> opencuseeme / peer2peer multiparty conferencing > >> ******************************************************** > > --Len. > > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > > You don't get no juice unless you squeeze > Lemon Obrien, the Third. > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.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 lemonobrien at yahoo.com Thu Jun 9 00:35:42 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] [opencuseeme] connection problem In-Reply-To: <42A73B42.7060500@ucla.edu> Message-ID: <20050609003542.82410.qmail@web53608.mail.yahoo.com> hopefully not. i don't really want to start a flame war. Michael Parker wrote: Oh, so we _are_ starting a flame war? ;-) - Mike Lemon Obrien wrote: > I created my own library j--, which emulates java using c++. I hate > *slow* software. > > > */codewarrior@cuseeme.de/* wrote: > > do you really know what i am talking about or you are just > want to start > a flame war? > _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050608/4bbcb557/attachment.htm From sg266 at cornell.edu Thu Jun 9 19:28:28 2005 From: sg266 at cornell.edu (Saikat Guha) Date: Sat Dec 9 22:12:59 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <200506081201.53635.baford@mit.edu> References: <200506081201.53635.baford@mit.edu> Message-ID: <1118345308.20932.47.camel@localhost.localdomain> On Wed, 2005-06-08 at 09:01 -0700, Bryan Ford wrote: > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] Hi David, > So, to make a long story short, NAT traversal is a hard problem, and it's > made especially hard by address-restricted NATs. > If I could count on > full-cone NAT behavior, my life as a programmer would be easier Consider that NAT vendors have blatantly said that they _refuse_ to implement full cone; mainly because of the importance of security in Internet devices and market forces. IMHO, unless the draft absolutely forbids non-full cone behavior, vendors that value security (as a principle or as marketing hype) will continue to developing non-full cone NATs. Regardless of the recommendations, developers will need to support non-full cone behavior if they want to maximize connectivity; there are ways to do this without adding all the complexity you mentioned but thats a separate topic. The big difference between full and non-full cone, I find, is less and more security respectively and not in p2p connectivity or application support. -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050609/6afe1493/attachment.pgp From lemonobrien at yahoo.com Thu Jun 9 21:30:35 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:59 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <1118345308.20932.47.camel@localhost.localdomain> Message-ID: <20050609213035.99032.qmail@web53610.mail.yahoo.com> this security crap has to go. I think none of the major it companies have nothing to do; and i think it is the current fad. its bad for business. its bad for consumers. its bad for america. el Saikat Guha wrote: On Wed, 2005-06-08 at 09:01 -0700, Bryan Ford wrote: > -----Original Message----- > From: David Barrett [mailto:dbarrett@quinthar.com] Hi David, > So, to make a long story short, NAT traversal is a hard problem, and it's > made especially hard by address-restricted NATs. > If I could count on > full-cone NAT behavior, my life as a programmer would be easier Consider that NAT vendors have blatantly said that they _refuse_ to implement full cone; mainly because of the importance of security in Internet devices and market forces. IMHO, unless the draft absolutely forbids non-full cone behavior, vendors that value security (as a principle or as marketing hype) will continue to developing non-full cone NATs. Regardless of the recommendations, developers will need to support non-full cone behavior if they want to maximize connectivity; there are ways to do this without adding all the complexity you mentioned but thats a separate topic. The big difference between full and non-full cone, I find, is less and more security respectively and not in p2p connectivity or application support. -- Saikat _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050609/d1cc7b01/attachment.htm From dbarrett at quinthar.com Thu Jun 9 21:50:30 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <1118345308.20932.47.camel@localhost.localdomain> References: <200506081201.53635.baford@mit.edu> <1118345308.20932.47.camel@localhost.localdomain> Message-ID: <42A8B9A6.6020303@quinthar.com> Saikat Guha wrote: >>From: David Barrett [mailto:dbarrett@quinthar.com] >>So, to make a long story short, NAT traversal is a hard problem, and it's >>made especially hard by address-restricted NATs. >>If I could count on >>full-cone NAT behavior, my life as a programmer would be easier > > IMHO, unless the draft absolutely > forbids non-full cone behavior, vendors that value security (as a > principle or as marketing hype) will continue to developing non-full > cone NATs. Unfortunately I agree, but this can be said about any of the NAT variables. Each has its own pros/cons, and the problem as a developer isn't dealing with misconfigured or broken NATs, it's dealing with the wide variety of differently-configured NATS. Reading through your IETF charter, I see: "Given the current near-universal deployment of NATs (Network Address Translators) in the public Internet, **the lack of standards for NAT behavior has given rise to a crisis**." [emphasis added] I'm not sure if this statement is referring to standards in terms of NAT *implementation* or NAT *deployment*, and there's a very big difference. If you are concerned with standardizing the implementation of NATs, but do nothing to standardize the deployment of NATs, you won't have done much to mitigate the current crisis. Indeed, it seems rather academic to completely define anything but the lowest-common denominator, because as a developer, that's all that matters. At the moment, the lowest common denominator is punching holes through address-restricted NATS, maintaining said holes with high-frequency keepalives, and avoiding fragmentation using very small MTUs. So long as you allow this configuration, I'm forced to develop towards it, and anything less restrictive or easier might as well not exist. Granted, I'd welcome a better definition of "high frequency keepalives" and "small MTUs". But I'd welcome even more an absence of address-restricted NATs. Personally, I believe NATs are not firewalls, and shouldn't be in the business of blocking traffic with the goal of enhancing security. Firewalls are much more capable in this respect, and have much less "collateral damage". But so long as NAT vendors are encouraged to market NATs as poor-man's firewalls (ie, so long as the IETF does nothing to counter this trend), I need to build with that in mind. -david From wharms at bfs.de Fri Jun 10 07:27:34 2005 From: wharms at bfs.de (walter harms) Date: Sat Dec 9 22:12:59 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <1118345308.20932.47.camel@localhost.localdomain> References: <200506081201.53635.baford@mit.edu> <1118345308.20932.47.camel@localhost.localdomain> Message-ID: <42A940E6.5040402@bfs.de> hi, there is only one way to combat sloopy/crippeled implementation. inform the customer. write a test-programm that checks for all rfc requirements and distribute it. most ppl are not aware what there system should do ( they never read specs, exspecialy not rfc's). if a programm say: "i am sorry to inform you that your network is not conform to rfc xyz. reason" They will feel riped-off. Since most ppl do not understand they will stick to the standards (see RFC) and feel uneasy if the do not comply. educate the masses. re, walter Saikat Guha wrote: > On Wed, 2005-06-08 at 09:01 -0700, Bryan Ford wrote: > >>-----Original Message----- >>From: David Barrett [mailto:dbarrett@quinthar.com] > > > Hi David, > > >>So, to make a long story short, NAT traversal is a hard problem, and it's >>made especially hard by address-restricted NATs. >>If I could count on >>full-cone NAT behavior, my life as a programmer would be easier > > > Consider that NAT vendors have blatantly said that they _refuse_ to > implement full cone; mainly because of the importance of security in > Internet devices and market forces. IMHO, unless the draft absolutely > forbids non-full cone behavior, vendors that value security (as a > principle or as marketing hype) will continue to developing non-full > cone NATs. Regardless of the recommendations, developers will need to > support non-full cone behavior if they want to maximize connectivity; > there are ways to do this without adding all the complexity you > mentioned but thats a separate topic. The big difference between full > and non-full cone, I find, is less and more security respectively and > not in p2p connectivity or application support. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 codewarrior at cuseeme.de Fri Jun 10 09:00:23 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:12:59 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <42A940E6.5040402@bfs.de> References: <200506081201.53635.baford@mit.edu> <1118345308.20932.47.camel@localhost.localdomain> <42A940E6.5040402@bfs.de> Message-ID: On Jun 10, 2005, at 9:27 AM, walter harms wrote: > educate the masses. walter great saying , as far as i researched on my project work , conferencing over udp seems to be feasible. and you could use something like this .... It has an interesting approach to UDP NAT Hole-punching that doesn't use a _public_ STUN-like server per say..... ..Basically, the approach trades off a public STUN server in exchange for a port-scan and full-cone support. (Rodi packets can be made to look like DNS, RTP etc). The default transport protocol of choice is UDP. :-/ http://larytet.sourceforge.net/btRat.shtml i am correct? just a bit packet loss right? thank you marc > >>> So, to make a long story short, NAT traversal is a hard problem, >>> and it's >>> made especially hard by address-restricted NATs. If I could count on >>> full-cone NAT behavior, my life as a programmer would be easier >> Consider that NAT vendors have blatantly said that they _refuse_ to >> implement full cone; mainly because of the importance of security in >> Internet devices and market forces. IMHO, unless the draft absolutely >> forbids non-full cone behavior, vendors that value security (as a >> principle or as marketing hype) will continue to developing non-full >> cone NATs. From zooko at zooko.com Fri Jun 10 14:14:00 2005 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] colliding md5 hashes of human-meaningful documents Message-ID: <20050610141400.5882F1727@zooko.com> There is nothing theoretically surprising about this, but hopefully its concreteness and the accompanying scenario will make an impression on people on people. The same technique should work to generate two documents with identical SHA1 hashes. http://www.cits.rub.de/MD5Collisions/ Regards, Zooko From dbarrett at quinthar.com Fri Jun 10 20:37:16 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] colliding md5 hashes of human-meaningful documents In-Reply-To: <20050610141400.5882F1727@zooko.com> References: <20050610141400.5882F1727@zooko.com> Message-ID: <1118435838.9A71EA7@dg12.dngr.org> I think you did a great job presenting it in a non-technical, real-world scenario. Good work! Are you going to clean up and release your document-tweaking tools? Alternatively a web-based service where the user can upload two documents and have them tweaked to matching signatures and mailed back might be better (and safer, as you can also insert clear warnings, as well as hold onto the source). -david On Fri, 10 Jun 2005 7:25 am, zooko@zooko.com wrote: > > There is nothing theoretically surprising about this, but hopefully its > concreteness and the accompanying scenario will make an impression on > people > on people. The same technique should work to generate two documents > with > identical SHA1 hashes. > > http://www.cits.rub.de/MD5Collisions/ > > Regards, > > Zooko > _______________________________________________ > 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 zooko at zooko.com Fri Jun 10 20:43:13 2005 From: zooko at zooko.com (zooko@zooko.com) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] colliding md5 hashes of human-meaningful documents In-Reply-To: <1118435838.9A71EA7@dg12.dngr.org> References: <20050610141400.5882F1727@zooko.com> <1118435838.9A71EA7@dg12.dngr.org> Message-ID: <20050610204313.65FA01046@zooko.com> > I think you did a great job presenting it in a non-technical, real-world > scenario. Good work! Are you going to clean up and release your > document-tweaking tools? Alternatively a web-based service where the > user can upload two documents and have them tweaked to matching > signatures and mailed back might be better (and safer, as you can also > insert clear warnings, as well as hold onto the source). Sorry to allow this confusion: I am not the author of these results. > > http://www.cits.rub.de/MD5Collisions/ Magnus Daum (CITS Research Group, RUB) Stefan Lucks (University of Mannheim) I should have named them in my post. I agree they did a great job of presentation. Regards, Zooko From hopper at omnifarious.org Sat Jun 11 04:39:07 2005 From: hopper at omnifarious.org (Eric M. Hopper) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] colliding md5 hashes of human-meaningful documents In-Reply-To: <20050610141400.5882F1727@zooko.com> References: <20050610141400.5882F1727@zooko.com> Message-ID: <1118464747.5236.3.camel@bats.omnifarious.org> On Fri, 2005-06-10 at 11:14 -0300, zooko@zooko.com wrote: > There is nothing theoretically surprising about this, but hopefully its > concreteness and the accompanying scenario will make an impression on people > on people. The same technique should work to generate two documents with > identical SHA1 hashes. > > http://www.cits.rub.de/MD5Collisions/ I'm so happy someone is doing this. I try to keep telling people that a broken hash function is actually worse than no hash function at all, but nobody pays any attention and they largely call me an alarmist twit. Mostly, it worries me that people won't think through the implications of the break carefully enough and make some mistake with unforeseen consequences in the future. Doing it right is a lot harder than most people think, and most people are better off with a fairly simple set of rules than trying to think through the ins and outs of a complex situation like a partially broken hash function. The fact that most hash functions so far are vulnerable to extension attacks is bad enough. *sigh*, -- The best we can hope for concerning the people at large is that they be properly armed. -- Alexander Hamilton -- Eric Hopper (hopper@omnifarious.org http://www.omnifarious.org/~hopper) -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 185 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050610/ea6bbd82/attachment.pgp From arachnid at notdot.net Mon Jun 13 00:30:44 2005 From: arachnid at notdot.net (Nick Johnson) Date: Sat Dec 9 22:12:59 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <20050609213035.99032.qmail@web53610.mail.yahoo.com> References: <20050609213035.99032.qmail@web53610.mail.yahoo.com> Message-ID: <42ACD3B4.60807@notdot.net> Lemon Obrien wrote: > this security crap has to go. I think none of the major it companies > have nothing to do; and i think it is the current fad. > > its bad for business. its bad for consumers. its bad for america. Er, you do realise the Internet covers more than just America, right? -Nick Johnson From lemonobrien at yahoo.com Mon Jun 13 17:51:59 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:59 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <42ACD3B4.60807@notdot.net> Message-ID: <20050613175159.563.qmail@web53603.mail.yahoo.com> yeah...but everyone likes to make money. Nick Johnson wrote:Lemon Obrien wrote: > this security crap has to go. I think none of the major it companies > have nothing to do; and i think it is the current fad. > > its bad for business. its bad for consumers. its bad for america. Er, you do realise the Internet covers more than just America, right? -Nick Johnson _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences You don't get no juice unless you squeeze Lemon Obrien, the Third. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050613/2a6570c8/attachment.htm From dbarrett at quinthar.com Wed Jun 15 10:09:35 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs Message-ID: <42AFFE5F.3010701@quinthar.com> In my ongoing quest for real-world data, do you know of any significant P2P deployments that hole-punch through symmetric NATs? As you know, the simple "rendezvous" hole-punching approach described by Bryan Ford's paper [1] suggests that upwards of 82% of all NATs can have holes punched on the assumption that "consistent endpoint translation" is in place (and thanks to the IETF-BEHAVE group, this number will only improve). This means if you establish outbound UDP sessions from the same private endpoint to two separate locations, your NAT will assign the same public endpoint to each. This allows me to contact you without "guessing" what NAT port you might be using. [1] http://www.brynosaurus.com/pub/net/p2pnat/ But as Bryan describes, symmetric NATs make no such consistent translation, and thus each outbound session is assigned a unique public endpoint by the NAT. This complicates hole punching, but doesn't prevent it. To punch through symmetric NATs you must, based on knowledge of one of a peer's public NAT endpoints, intelligently guess the others. So hole punching through symmetric NATs is difficult, and Bryan suggests not worth the effort. I'm curious what you think, however. Have you tried it and found it useful in the real world? In theory it can get you better than 82% success ratio of hole punching, but I'm not sure if it gets you only to 85% or 90% or 99% or what. Do you know of any success (or failure) stories of hole punching through symmetric NATs in the real world? -david From ap at hamachi.cc Wed Jun 15 15:57:41 2005 From: ap at hamachi.cc (Alex Pankratov) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: <42AFFE5F.3010701@quinthar.com> References: <42AFFE5F.3010701@quinthar.com> Message-ID: <42B04FF5.2050604@hamachi.cc> David Barrett wrote: > In theory it can get you better than 82% success ratio of hole punching, > but I'm not sure if it gets you only to 85% or 90% or 99% or what. Do > you know of any success (or failure) stories of hole punching through > symmetric NATs in the real world? We have few thousand online clients and the successful tunnel mediation rate of about 97%. And we know how to further improve it by another 1% to 1.5%. I cannot share any technical details, but this should give you confidence that it *is* doable :) Alex From srhea at cs.berkeley.edu Wed Jun 15 16:13:26 2005 From: srhea at cs.berkeley.edu (Sean C. Rhea) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: <42AFFE5F.3010701@quinthar.com> References: <42AFFE5F.3010701@quinthar.com> Message-ID: On Jun 15, 2005, at 3:09 AM, David Barrett wrote: > In my ongoing quest for real-world data, do you know of any > significant P2P deployments that hole-punch through symmetric NATs? Not a lot of data, but some. (Probably not what you're looking for, but just in case.) http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf Sean -- Men who have discovered the limits of arrogance make better company: You notice more when you're not running around imposing your will on everything. -- Virginia Vitzthum -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050615/c71c523c/PGP.pgp From larytet.8753341 at bloglines.com Wed Jun 15 17:06:51 2005 From: larytet.8753341 at bloglines.com (larytet.8753341@bloglines.com) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs Message-ID: <1118855211.3073141068.30273.sendItem@bloglines.com> i make it on dayly basis using http://larytet.sourceforge.net/btRat.shtml --- Peer-to-peer development." P2P deployments that hole-punch through symmetric NATs? > > > As you know, the simple "rendezvous" hole-punching approach described by > Bryan Ford's paper [1] suggests that upwards of 82% of all NATs can have > holes punched on the assumption that "consistent endpoint translation" > is in place (and thanks to the IETF-BEHAVE group, this number will only > improve). This means if you establish outbound UDP sessions from the > same private endpoint to two separate locations, your NAT will assign > the same public endpoint to each. This allows me to contact you without > "guessing" what NAT port you might be using. > > [1] http://www.brynosaurus.com/pub/net/p2pnat/ > > But as Bryan describes, symmetric NATs make no such consistent > translation, and thus each outbound session is assigned a unique public > endpoint by the NAT. This complicates hole punching, but doesn't > prevent it. To punch through symmetric NATs you must, based on > knowledge of one of a peer's public NAT endpoints, intelligently guess > the others. > > > So hole punching through symmetric NATs is difficult, and Bryan suggests > not worth the effort. I'm curious what you think, however. Have you > tried it and found it useful in the real world? > > In theory it can get you better than 82% success ratio of hole punching, > but I'm not sure if it gets you only to 85% or 90% or 99% or what. Do > you know of any success (or failure) stories of hole punching through > symmetric NATs in the real world? > > -david > _______________________________________________ > 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 sg266 at cornell.edu Wed Jun 15 18:15:47 2005 From: sg266 at cornell.edu (Saikat Guha) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: <42AFFE5F.3010701@quinthar.com> References: <42AFFE5F.3010701@quinthar.com> Message-ID: <1118859348.5135.19.camel@localhost.localdomain> On Wed, 2005-06-15 at 03:09 -0700, David Barrett wrote: > So hole punching through symmetric NATs is difficult, and Bryan suggests > not worth the effort. I'm curious what you think, however. Have you > tried it and found it useful in the real world? We performed port prediction and hole punching tests, albeit for TCP. The compiled results are available at: http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf Detailed results of the port prediction can be found at: https://www.guha.cc/saikat/stunt-results.php?sort=10,5,6 While this is for TCP, we found earlier that more NATs support hole- punching and port prediction for UDP than for TCP; so interpret the results as a lower bound or a qualitative indication of the trend. With 82% "cone" NATs, as per Bryan's paper, the UDP P2P success rate is slightly less since both sides need to successfully punch holes. FWIW, we measured the effect of port prediction for TCP. With 75% "TCP cone" NATs the P2P success rate without port prediction is roughly 50%; if we add in port prediction for the symmetric NATs, the success rate increases by 35%. Cheers. -- Saikat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050615/4a378a37/attachment.pgp From lemonobrien at yahoo.com Wed Jun 15 20:24:12 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: <1118855211.3073141068.30273.sendItem@bloglines.com> Message-ID: <20050615202413.99416.qmail@web53607.mail.yahoo.com> i downloaded Rodi source code. I checked out how the NAT stuff worked...and well, didn't understand it too well. it seemed it was using a thread to send messages to itself so it could discover its global port? would you mind explaining how it works in detail? lemon larytet.8753341@bloglines.com wrote: i make it on dayly basis using http://larytet.sourceforge.net/btRat.shtml --- Peer-to-peer development." In my ongoing quest for real-world data, do you know of any significant > P2P deployments that hole-punch through symmetric NATs? > > > As you know, the simple "rendezvous" hole-punching approach described by > Bryan Ford's paper [1] suggests that upwards of 82% of all NATs can have > holes punched on the assumption that "consistent endpoint translation" > is in place (and thanks to the IETF-BEHAVE group, this number will only > improve). This means if you establish outbound UDP sessions from the > same private endpoint to two separate locations, your NAT will assign > the same public endpoint to each. This allows me to contact you without > "guessing" what NAT port you might be using. > > [1] http://www.brynosaurus.com/pub/net/p2pnat/ > > But as Bryan describes, symmetric NATs make no such consistent > translation, and thus each outbound session is assigned a unique public > endpoint by the NAT. This complicates hole punching, but doesn't > prevent it. To punch through symmetric NATs you must, based on > knowledge of one of a peer's public NAT endpoints, intelligently guess > the others. > > > So hole punching through symmetric NATs is difficult, and Bryan suggests > not worth the effort. I'm curious what you think, however. Have you > tried it and found it useful in the real world? > > In theory it can get you better than 82% success ratio of hole punching, > but I'm not sure if it gets you only to 85% or 90% or 99% or what. Do > you know of any success (or failure) stories of hole punching through > symmetric NATs in the real world? > > -david > _______________________________________________ > 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 You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Discover Yahoo! Find restaurants, movies, travel & more fun for the weekend. Check it out! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050615/4cebcab3/attachment.html From dbarrett at quinthar.com Wed Jun 15 21:25:53 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: <42B04FF5.2050604@hamachi.cc> References: <42AFFE5F.3010701@quinthar.com> <42B04FF5.2050604@hamachi.cc> Message-ID: <42B09CE1.80008@quinthar.com> Alex Pankratov wrote: > > We have few thousand online clients and the successful tunnel mediation > rate of about 97%. And we know how to further improve it by another > 1% to 1.5%. I cannot share any technical details, but this should give > you confidence that it *is* doable :) Well this is reassuring and inspirational. Thanks! -david From dbarrett at quinthar.com Wed Jun 15 22:10:17 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: References: <42AFFE5F.3010701@quinthar.com> Message-ID: <42B0A749.2070000@quinthar.com> Sean C. Rhea wrote: > > Not a lot of data, but some. (Probably not what you're looking for, but > just in case.) > > http://www.cs.cornell.edu/People/francis/nutss-fdna.pdf It looks like the key lesson there is that most symmetric NATS use sequential port assignments, simplifying port-prediction significantly. However, this only works if the latency between STUN discovery and session initialization is low, or if the NAT has low load. So I guess a followup question is: 1) When predicting symmetric UDP ports, how far "ahead" do you probe past the NAT port pierced by the STUN server? It seems like the longer duration that has elapsed between the STUN execution, and the higher the load on the NAT, the further ahead you need to scan. But in reality, is this like 5-10? Or 50-100? Or 500-1000 ports? Do you do them sequentially, or in parallel? 2) At one point will routers and firewalls start classifying your port-prediction as a general port-scan and block you out entirely as a would-be hacker? -david From dbarrett at quinthar.com Wed Jun 15 22:28:59 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:12:59 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: <1118859348.5135.19.camel@localhost.localdomain> References: <42AFFE5F.3010701@quinthar.com> <1118859348.5135.19.camel@localhost.localdomain> Message-ID: <42B0ABAB.1050300@quinthar.com> Saikat Guha wrote: > > We performed port prediction and hole punching tests, albeit for TCP. > The compiled results are available at: > http://nutss.gforge.cis.cornell.edu/pub/draft-imc-stunt.pdf > > Detailed results of the port prediction can be found at: > https://www.guha.cc/saikat/stunt-results.php?sort=10,5,6 Wow, excellent data. Great paper, too. Regarding the data, I see it dtail TCP port prediction; do those results closely correlate with UDP prediction? And I think the relevant column is "TCP Binding/Delta", correct? If so, it appears that only two of the tested NATs used random port assignments, which is encouraging. -david From sg266 at cornell.edu Thu Jun 16 01:28:54 2005 From: sg266 at cornell.edu (Saikat Guha) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] UDP Hole Punching through Symmetric NATs In-Reply-To: <42B0ABAB.1050300@quinthar.com> References: <42AFFE5F.3010701@quinthar.com> <1118859348.5135.19.camel@localhost.localdomain> <42B0ABAB.1050300@quinthar.com> Message-ID: <1118885335.6785.25.camel@localhost.localdomain> On Wed, 2005-06-15 at 15:28 -0700, David Barrett wrote: > Regarding the data, I see it > dtail TCP port prediction; do those results closely correlate with UDP > prediction? I do not know for sure, but I believe they will be similar. Just as competing HTTP traffic etc contents with port pred. for TCP, DNS traffic will contend with UDP. At the same time more NATs are cone for UDP so the overall picture may be more rosy, but unfortunately, I don't have the numbers to substantiate that. Alex mentioned stellar success rates so perhaps the situation is much more rosy that I anticipate. > And I think the relevant column is "TCP Binding/Delta", correct? If so, > it appears that only two of the tested NATs used random port > assignments, which is encouraging. Correct. And of those 2, one is an old lab box chosen for testing because of that particular property and the other was submitted by an anonymous user who didn't leave any NAT or contact information. -- Saikat (who thinks fuzzy words like 'rosy' are great for use in technical discussions) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050615/2f82891f/attachment.pgp From john.casey at gmail.com Thu Jun 16 05:12:25 2005 From: john.casey at gmail.com (John Casey) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] what is the best way to generate random variables according to a zipf distribution ?? Message-ID: Dear All, I was wondering if any one might help explain what is the best way to generate random variables that are distributed according to a zipf distribution with a slope of -1 and an output range of 1 to 30. I have tried using cern's cern.jet.random.Distributions nextZipfInt(... ) (see http://hoschek.home.cern.ch/hoschek/colt/V1.0.3/doc/cern/jet/random/Distributions.html) but the output of this generator is severely clipped if I attempt to change the output range. I have also tried generating a series of data points that are derived using zipf's law and have been able to uniformly at random sample these values. This method seems to work quite, and the distribution of sampled values better approximates zipf's law than using the cern random generator. In terms of methodology is this method acceptable?? it seems to be a bit of a kludge to me. But I am having difficulty finding a better solution. Any ideas ?? thanks. From john.casey at gmail.com Thu Jun 16 08:06:25 2005 From: john.casey at gmail.com (John Casey) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] zipf's law Message-ID: Dear All, I was wondering if any one might help explain what is the best way to generate random variables that are distributed according to a zipf distribution with a slope of -1 and an output range of 1 to 30. I have tried using cern's cern.jet.random.Distributions nextZipfInt(... ) (see http://hoschek.home.cern.ch/hoschek/colt/V1.0.3/doc/cern/jet/random/Distributions.html) but the output of this generator is severely clipped if I attempt to change the output range. I have also tried generating a series of data points that are derived using zipf's law and have been able to uniformly at random sample these values. This method seems to work quite, and the distribution of sampled values better approximates zipf's law than using the cern random generator. In terms of methodology is this method acceptable?? it seems to be a bit of a kludge to me. But I am having difficulty finding a better solution. Any ideas ?? thanks. From hal at finney.org Thu Jun 16 16:01:37 2005 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] zipf's law Message-ID: <20050616160137.CCE4A57E8C@finney.org> John Casey writes: > I was wondering if any one might help explain what is the best way to > generate random variables that are distributed according to a zipf > distribution with a slope of -1 and an output range of 1 to 30. Maybe I'm misunderstanding... The standard method for generating random values according to any given distribution is to generate a uniform random value and map it to the desired distribution. In this case, if you want the 30 output values to have proportions 1, 1/2, 1/3, 1/4, ... 1/30, you would first sum these values. Let S = 1 + 1/2 + 1/3 + 1/4 + ... + 1/30. Then generate a uniform random value x in the range [0,S]. Then map it to your 30 bins by testing it against the ranges [0,1], [1, 1+1/2], [1+1/2, 1+1/2+1/3], and so on. The bin number is then your output variable. Sorry about providing the obvious if you already knew this! Hal Finney From greg at electricrain.com Thu Jun 16 21:36:49 2005 From: greg at electricrain.com (Gregory P. Smith) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use Message-ID: <20050616213649.GG25592@zot.electricrain.com> This paper on using network coding for p2p content distribution swarm speedups is interesting. http://www.research.microsoft.com/~pablo/papers/nc_contentdist.pdf (beware of patents) -greg From justin at specialbusservice.com Thu Jun 16 22:47:18 2005 From: justin at specialbusservice.com (Justin Cormack) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <20050616213649.GG25592@zot.electricrain.com> References: <20050616213649.GG25592@zot.electricrain.com> Message-ID: <42B20176.9010200@specialbusservice.com> Gregory P. Smith wrote: >This paper on using network coding for p2p content distribution swarm >speedups is interesting. > > http://www.research.microsoft.com/~pablo/papers/nc_contentdist.pdf > >(beware of patents) > > Yes it was quite interesting. From the patent point of view, which were you thinking of? Do you think it would be covered by the digital fountain patents (I havent looked at their patents just the papers so I am not sure how they are written). The computational costs are pretty high. Justin From coderman at gmail.com Thu Jun 16 22:51:14 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <20050616213649.GG25592@zot.electricrain.com> References: <20050616213649.GG25592@zot.electricrain.com> Message-ID: <4ef5fec605061615513bd83560@mail.gmail.com> On 6/16/05, Gregory P. Smith wrote: > This paper on using network coding for p2p content distribution swarm > speedups is interesting. the decentralization of coding process (end nodes as well as seeds/server perform encoding functions) is a nifty improvement in this model. it is also CPU intensive which may affect throughput negatively in a way that bittorrent and/or central coding schemes do not. real world comparison with bittorrent / other systems on heterogeneous hardware would be interesting. From alenlpeacock at gmail.com Fri Jun 17 05:30:25 2005 From: alenlpeacock at gmail.com (Alen Peacock) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <4ef5fec605061615513bd83560@mail.gmail.com> References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> Message-ID: Bram Cohen makes some interesting arguments against such a scheme: http://www.advogato.org/person/Bram/ (Nov 7 2004 entry, "erasure codes"). I'm sure most p2p-hackers readers are familiar with this reasoning, but I'm equally convinced that a lot of us don't necessarily agree with Bram's stance, at least not in the general case. At the same time, I don't think anyone would argue that the costs associated with using erasure codes inside a decentralized system (both in terms of implementation and processing) aren't significant. Alen On 6/16/05, coderman wrote: > On 6/16/05, Gregory P. Smith wrote: > > This paper on using network coding for p2p content distribution swarm > > speedups is interesting. > > the decentralization of coding process (end nodes as well as > seeds/server perform encoding functions) is a nifty improvement in > this model. it is also CPU intensive which may affect throughput > negatively in a way that bittorrent and/or central coding schemes do > not. > > real world comparison with bittorrent / other systems on heterogeneous > hardware would be interesting. > _______________________________________________ > 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 john.casey at gmail.com Fri Jun 17 06:44:29 2005 From: john.casey at gmail.com (John Casey) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] zipf's law In-Reply-To: <20050616160137.CCE4A57E8C@finney.org> References: <20050616160137.CCE4A57E8C@finney.org> Message-ID: On 6/17/05, "Hal Finney" wrote: > John Casey writes: > > I was wondering if any one might help explain what is the best way to > > generate random variables that are distributed according to a zipf > > distribution with a slope of -1 and an output range of 1 to 30. > > Maybe I'm misunderstanding... > > The standard method for generating random values according to any given > distribution is to generate a uniform random value and map it to the > desired distribution. > > In this case, if you want the 30 output values to have proportions > 1, 1/2, 1/3, 1/4, ... 1/30, you would first sum these values. Let > S = 1 + 1/2 + 1/3 + 1/4 + ... + 1/30. Then generate a uniform random > value x in the range [0,S]. Then map it to your 30 bins by testing > it against the ranges [0,1], [1, 1+1/2], [1+1/2, 1+1/2+1/3], and so on. > The bin number is then your output variable. > > Sorry about providing the obvious if you already knew this! Thanks Hal I have just tried the binning technique but it doesn't seem to give very good results. On sorting the random numbers the distribution still seems to be very skewed which I am guessing is due to the integer nature of the binning process. http://www3.it.deakin.edu.au/~jacasey/bin-transform.gif I might go back to my older idea of using cern's zipf random generator save all the variables and then normalize them all by the largest number generated into the range [0,1] I have attached inline the java code that I used to generate that graph. Are there any obvious or not so obvious errors ?? public class zipf3 { public static double harmonic(int N, int exponent) { double sum = 0.0; for (int i = 1; i <= N; i++) sum += 1.0 / Math.pow(i,exponent); return sum; } public static void main(String[] args) { double sum = harmonic(100,1); for(int i=0;i<10000;i++) { double tmp=Math.random()*sum; double range=0; for(int j=1;j<101;j++) { double upper=harmonic(j,1); if((tmp>=range) && (tmp<=upper)) { System.out.println(j); break; } else { range=upper; } } } } } From hal at finney.org Fri Jun 17 06:53:09 2005 From: hal at finney.org (Hal Finney) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] zipf's law Message-ID: <20050617065309.8CBF557E8C@finney.org> John Casey writes: > Thanks Hal I have just tried the binning technique but it doesn't seem > to give very good results. On sorting the random numbers the > distribution still seems to be very skewed which I am guessing is due > to the integer nature of the binning process. > > http://www3.it.deakin.edu.au/~jacasey/bin-transform.gif > > I might go back to my older idea of using cern's zipf random generator > save all the variables and then normalize them all by the largest > number generated into the range [0,1] > > I have attached inline the java code that I used to generate that > graph. Are there any obvious or not so obvious errors ?? Your program looks correct, although it's a little inefficient in how it calls harmonic for each bin. I ran it and counted how many outputs it produced of each bin number and it seemed to be a good Zipf distribution. Here are the first 20 bins: 1963 1 922 2 611 3 478 4 386 5 309 6 288 7 229 8 214 9 197 10 185 11 156 12 155 13 134 14 149 15 113 16 112 17 113 18 89 19 89 20 The first number is the number of times we got that output and the second is the bin number. As you can see, 2 happens about half as often as 1, 3 happens about 1/3 as often, 10 happens about 1/10 as often, and so on. I'm not sure what your graph was supposed to show but maybe you had a mistake in your plotting program. I'd say this output looks great. Hal From john.casey at gmail.com Fri Jun 17 08:11:31 2005 From: john.casey at gmail.com (John Casey) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] zipf's law In-Reply-To: <20050617065309.8CBF557E8C@finney.org> References: <20050617065309.8CBF557E8C@finney.org> Message-ID: > The first number is the number of times we got that output and the second > is the bin number. As you can see, 2 happens about half as often as 1, > 3 happens about 1/3 as often, 10 happens about 1/10 as often, and so on. > > I'm not sure what your graph was supposed to show but maybe you had a > mistake in your plotting program. I'd say this output looks great. Cheers thanks. I was just plotting the 10,000 raw frequencies. rather than the total of each bin. From ludovic.courtes at laas.fr Fri Jun 17 11:01:50 2005 From: ludovic.courtes at laas.fr (=?iso-8859-1?q?Ludovic_Court=E8s?=) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <42B20176.9010200@specialbusservice.com> (Justin Cormack's message of "Thu, 16 Jun 2005 23:47:18 +0100") References: <20050616213649.GG25592@zot.electricrain.com> <42B20176.9010200@specialbusservice.com> Message-ID: <87u0jx1c2p.fsf@laas.fr> Hi, Justin Cormack writes: > From the patent point of view, which were you thinking of? Do you > think it would be covered by the digital fountain patents (I havent > looked at their patents just the papers so I am not sure how they are > written). >From Pablo Rodriguez' page, it seems that Microsoft actually owns a patent related to the paper: http://www.rodriguezrodriguez.com/files/My_Research.html . Thanks, Ludovic. From codewarrior at cuseeme.de Fri Jun 17 11:12:45 2005 From: codewarrior at cuseeme.de (codewarrior@cuseeme.de) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <87u0jx1c2p.fsf@laas.fr> References: <20050616213649.GG25592@zot.electricrain.com> <42B20176.9010200@specialbusservice.com> <87u0jx1c2p.fsf@laas.fr> Message-ID: <703E8582-A1CB-459E-BA0C-1EAABB3A30C8@cuseeme.de> On Jun 17, 2005, at 1:01 PM, Ludovic Court?s wrote: > patent related to the paper: > http://www.rodriguezrodriguez.com/files/My_Research.html . yeah, and microsoft inveted the internet ROFL cheers m. -- "In a world without walls or fences, who needs Windows and Gates?" http://brain.let.de cuseeme:// cuseeme.dyndns.tv From mccoy at mad-scientist.com Fri Jun 17 17:41:10 2005 From: mccoy at mad-scientist.com (Jim McCoy) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <42B20176.9010200@specialbusservice.com> References: <20050616213649.GG25592@zot.electricrain.com> <42B20176.9010200@specialbusservice.com> Message-ID: <22D3F8E8-F3AE-4C59-B915-BDCA257EDC54@mad-scientist.com> On Jun 16, 2005, at 3:47 PM, Justin Cormack wrote: > > From the patent point of view, which were you thinking of? Do you > think it would be covered by the digital fountain patents (I havent > looked at their patents just the papers so I am not sure how they > are written). While any useful erasure coding system would eventually run into the DF patents, I think Greg was referring to the oblique mention of a potential patent on the data verification process. The problem with using rateless erasure codes in this case is that it becomes hard to verify the pieces that are being distributed, the only public (non- patented IIRC) method has a high computational cost. The paper references a faster, simpler, and conveniently not disclosed method which I believe is what is going to end up in someone's IP portfolio... Jim From greg at electricrain.com Fri Jun 17 20:48:34 2005 From: greg at electricrain.com (Gregory P. Smith) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <42B20176.9010200@specialbusservice.com> References: <20050616213649.GG25592@zot.electricrain.com> <42B20176.9010200@specialbusservice.com> Message-ID: <20050617204834.GJ25592@zot.electricrain.com> On Thu, Jun 16, 2005 at 11:47:18PM +0100, Justin Cormack wrote: > >This paper on using network coding for p2p content distribution swarm > >speedups is interesting. > > > >http://www.research.microsoft.com/~pablo/papers/nc_contentdist.pdf > > > >(beware of patents) > > Yes it was quite interesting. > > From the patent point of view, which were you thinking of? Do you think > it would be covered by the digital fountain patents (I havent looked at > their patents just the papers so I am not sure how they are written). > > The computational costs are pretty high. > > Justin I assumed it probably uses something digital fountain stuff covers given that they did mention it somewhere in the paper. Regardless that warning is standard practice with these algorithms. I was disappointed that the paper didn't really cover the computational costs. cpu vendors would love this stuff. gotta have a multicore machine with memory bandwidth to sit there continuosly computing new codes over your entire dataset. ;) -g From Bernard.Traversat at Sun.COM Sat Jun 18 01:11:32 2005 From: Bernard.Traversat at Sun.COM (Bernard Traversat) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] JXTA Community "triple play" releases and JXTA/Boeing Announcement In-Reply-To: <4ef5fec605061615513bd83560@mail.gmail.com> References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> Message-ID: <42B374C4.5010303@sun.com> This week the JXTA community executed an impressive "triple-play", releasing simultaneously, for the first time in the project history, 3 different implementations of the JXTA P2P protocols. The 3 implementations are fully compliant and interoperable enabling the deployment of self-organizing, scalable, and secure P2P applications on devices ranging from sensors, phones, ipods, PDAs, PCs, TVs, STBs, DVRs, servers and supercomputers. 1)JXTA-J2SE 2.3.4(Arroz Congris) http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=215 2)JXTA-J2ME 2.0 (Arrakis) http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=214 3)JXTA-C/C++ 2.1.1 for Solaris, Linux, Win, and embedded RTOS (Disney) http://www.jxta.org/servlets/ReadMsg?list=announce&msgNo=213 Sun also announced that Boeing (http://biz.yahoo.com/prnews/050613/sfm025.html), the lead systems integrator for the U.S. Army's multi-billion dollar Future Combat Systems (FCS) project, has selected the JXTA technology to provide the P2P discovery service for the U.S. Army FCS global network infrastructure. These latest announcements highlight the continue growth and maturity of the JXTA technology, making JXTA the leading P2P Platform for deploying ubiquitous applications. JXTA will have a significant presence at JavaOne (http://www.jxta.org/JavaOne/JavaOne2005.html). JXTA community members will also be on hand to share their experiences and expertise on developing and deploying JXTA applications at the JXTA TownHall meeting (http://www.jxta.org/community/TownHall/SF25jun2005.html) meeting. Please come meet with us and learn about the unique capabilities of the JXTA technology for deploying highly-resilient, self-organizing, and scalable ubiquitous P2P network solutions. Cheers, B. -- --http://weblogs.java.net/blog/tra "As Java implies platform independence, and XML implies language independence, JXTA implies network independence." From arachnid at notdot.net Sun Jun 19 20:59:48 2005 From: arachnid at notdot.net (Nick Johnson) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> Message-ID: <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> On 17/06/2005, at 5:30 PM, Alen Peacock wrote: > Bram Cohen makes some interesting arguments against such a scheme: > http://www.advogato.org/person/Bram/ (Nov 7 2004 entry, "erasure > codes"). His arguments there are mostly specious. He states "One possible benefit erasure codes is that when sending data to a peer there are so many potential pieces that you can send any random one you have and it won't be a duplicate. The problem is that the peer may already have gotten that same piece from another peer, so that benefit is destroyed, and on top of that the overhead of communicating and remembering which peer has what is increased tremendously." - a blanket assertion which isn't true at all. Granted, there's still a chance that your peer already has the piece you want to send, but the higher the number of pieces, the lower that chance. > I'm sure most p2p-hackers readers are familiar with this reasoning, > but I'm equally convinced that a lot of us don't necessarily agree > with Bram's stance, at least not in the general case. At the same > time, I don't think anyone would argue that the costs associated with > using erasure codes inside a decentralized system (both in terms of > implementation and processing) aren't significant. Indeed. Personally, I think the main problem with Fountain codes and the like is the lack of an easy way to verify individual pieces. There exists a Homomorphic Hashing algorithm for the purpose, but it's complex, extremely slow, expands the encoded pieces (though not by much), and the hashes themselves are large. More development is needed here before it's a practical system, IMHO. That said, I'm working on a P2P system where we do intend to use Online codes (a variant of Fountain codes) - not for piece encoding, but for the transmission of individual pieces via multicast. This is where they really shine. -Nick Johnson From coderman at gmail.com Sun Jun 19 22:48:16 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> Message-ID: <4ef5fec605061915485f414b97@mail.gmail.com> On 6/19/05, Nick Johnson wrote: > ... there's still a > chance that your peer already has the piece you want to send, but the > higher the number of pieces, the lower that chance. in the bittorrent context you can centrally direct the range of blocks to be xfer'd between peers efficiently regardless of whether the blocks are error coded or not. i don't see Bram's arguments intended for all p2p / decentralized systems [and the myraid ways error coding can be integrated]. > That said, I'm working on a P2P system where we do intend to use > Online codes (a variant of Fountain codes) - not for piece encoding, > but for the transmission of individual pieces via multicast. This is > where they really shine. wireless broadcast (at the data packet layer, not just physical/transport) is another environment where these codes are useful for the same kind of unidirectional bulk transport. there are lots of potential uses for these codes but a centralized tracker is not one of them. [it would be interesting to see if Bram reconsiders these type of decentralized network codes for a trackerless DHT torrent network, assuming CPU requirements were not prohibitive] From arachnid at notdot.net Sun Jun 19 22:51:50 2005 From: arachnid at notdot.net (Nick Johnson) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <4ef5fec605061915485f414b97@mail.gmail.com> References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> <4ef5fec605061915485f414b97@mail.gmail.com> Message-ID: On 20/06/2005, at 10:48 AM, coderman wrote: > wireless broadcast (at the data packet layer, not just > physical/transport) is another environment where these codes are > useful for the same kind of unidirectional bulk transport. there are > lots of potential uses for these codes but a centralized tracker is > not one of them. > > [it would be interesting to see if Bram reconsiders these type of > decentralized network codes for a trackerless DHT torrent network, > assuming CPU requirements were not prohibitive] How is the use or otherwise of a tracker in any way related to the use of rateless codes? -Nick Johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050620/867f0aa2/attachment.html From arachnid at notdot.net Sun Jun 19 23:16:18 2005 From: arachnid at notdot.net (Nick Johnson) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> Message-ID: <0AEEA650-3819-41E8-856F-F0AED539685B@notdot.net> On 20/06/2005, at 11:07 AM, Michael J. Freedman wrote: > On Mon, 20 Jun 2005, Nick Johnson wrote: > > >> That said, I'm working on a P2P system where we do intend to use >> Online codes (a variant of Fountain codes) - not for piece >> encoding, but for the transmission of individual pieces via >> multicast. This is where they really shine. >> > > You should speak with Petar. His Online codes are actually > probably covered by Digital Fountain's patennts, but he's since > developed something else which he claims shouldn't be. I don't > know where he's taking rateless.com, however. Yes, I saw that. Having read the patents, they seem to be extremely inclusive - I can't think how one would develop any rateless code that isn't covered by them. The only reason I haven't contacted him, however, is because I assumed he had some reason for not publishing his patent-free code, and wasn't just going to hand it out to whoever asks. :/ -Nick Johnson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050620/a92523e6/attachment.htm From dbarrett at quinthar.com Mon Jun 20 00:07:49 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:00 2006 Subject: [Ietf-behave] Fwd: [p2p-hackers] Official IETF behavior recommendations for NATrelevant to P2P In-Reply-To: <20050619223531.21432.qmail@web40426.mail.yahoo.com> References: <20050619223531.21432.qmail@web40426.mail.yahoo.com> Message-ID: <42B608D5.4090606@quinthar.com> Pyda Srisuresh wrote: > First off, much thanks to David for taking the time and sharing his thoughts > with the list. We could do with more people like you, David, to give us real > feedback from an applicaion developers' perspective. I would really appreciate > your continued feedback and involvement on this list. Thanks again. Ah, you're entirely welcome. I'm glad the IETF-BEHAVE group is working on this topic. And I think I was being snippy last time I wrote and suggested anything less than a total full-cone world was meaningless. This is anything but the case. Granted, as a P2P developer, a standardized full-cone Internet with fixed keepalives and so forth would be the ideal. But there's a big range between where we are today and that ideal, and any progress along this road is most welcome. > Unfortunately, the predominant use-case of NATs during early deployment was > client-server apps and people were concerned mainly about hosts running the > client apps from behind NAT. P2P apps were not as prevalent. Security was a big > concern. > > So, given the history and mindset of the NAT vendors from the past, I am sure > you understand the reason behind the hesitation on this list. Yes, I accept entirely the historical reasons why we are where we are today. But it's frustrating from a development perspective nonetheless. And security should always be a major concern. It's just unfortunate when it comes at the expense of functionality. Personally, I believe full-cone NATs provide the lion's share of the benefits with the fewest detriments (blocking external traffic to internal applications not anticipating it). But address restricted and symmetric NATs offer few incremental security benefits, while many incremental detriments. I believe full-cone NATs offer a excellent balance of "untargeted security" and functionality, and that administrators seeking more targeted security should purposely configure a firewall. But I recognize that there is a diversity of opinion on the topic. -david From dbarrett at quinthar.com Mon Jun 20 08:39:04 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] Spoofing source address to tunnel through address-restricted/symmetric NAT Message-ID: <42B680A8.7030309@quinthar.com> I've heard it's possible to spoof the source address of a UDP packet. And I know address-restricted and symmetric NATs filter/route inbound UDP traffic based on source address. Has anyone tried combining these two to pierce these NATs? For example, client A uses STUN to find its public IP address on a symmetric NAT. Normally, only the STUN server would be able to reply through that NAT port -- any UDP packets arriving at that port from a source other than the STUN server would be filtered. However, if other clients were able to spoof the source address of their UDP packets, then anyone could use the STUN server's NAT port just as if it were a full-cone NAT. Were clients in a P2P network to voluntarily publish their STUN port-mappings, and always spoof addresses to be from there, this could obviate the need for hole-punching and port-scanning entirely. With this in mind: 1) How do you spoof UDP source identities? 2) Have you heard of anyone using this for NAT piercing? 3) How good is "the internet" (by which I mean current deployed hardware) at identifying and blocking spoofed UDP packets? I see a post from Bryan Ford on the IETF-BEHAVE list describing this very theoretical possibility (http://list.sipfoundry.org/archive/ietf-behave/msg00667.html), but I haven't seen any actual attempts to do this in the real world. Bryan, have you tried this? -david From solipsis at pitrou.net Mon Jun 20 13:32:08 2005 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] Spoofing source address to tunnel through address-restricted/symmetric NAT In-Reply-To: <42B680A8.7030309@quinthar.com> References: <42B680A8.7030309@quinthar.com> Message-ID: <1119274328.29968.10.camel@p-dvsi-395-20.rd.francetelecom.fr> > With this in mind: > > 1) How do you spoof UDP source identities? > > 2) Have you heard of anyone using this for NAT piercing? > > 3) How good is "the internet" (by which I mean current deployed > hardware) at identifying and blocking spoofed UDP packets? If I were you, before asking technical questions, I would ask myself whether relying on source address spoofing is really desireable policy-wise and reputation-wise. Even if the application using the hack is not malicious per se. I mean, if there's a source address in UDP packets, it's not meant for people to forge/abuse it... ;) Regards Antoine. From em at em.no-ip.com Mon Jun 20 14:39:35 2005 From: em at em.no-ip.com (Enzo Michelangeli) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] Spoofing source address to tunnel throughaddress-restricted/symmetric NAT References: <42B680A8.7030309@quinthar.com> <1119274328.29968.10.camel@p-dvsi-395-20.rd.francetelecom.fr> Message-ID: <003101c575a5$e72a7460$0200a8c0@em.noip.com> ----- Original Message ----- From: "Antoine Pitrou" To: "Peer-to-peer development." Sent: Monday, June 20, 2005 9:32 PM Subject: Re: [p2p-hackers] Spoofing source address to tunnel throughaddress-restricted/symmetric NAT > > With this in mind: > > > > 1) How do you spoof UDP source identities? > > > > 2) Have you heard of anyone using this for NAT piercing? > > > > 3) How good is "the internet" (by which I mean current deployed > > hardware) at identifying and blocking spoofed UDP packets? > > If I were you, before asking technical questions, I would ask myself > whether relying on source address spoofing is really desireable > policy-wise and reputation-wise. Even if the application using the hack > is not malicious per se. > > I mean, if there's a source address in UDP packets, it's not meant for > people to forge/abuse it... ;) And so what? There are cases when what is "meant" (by whom, anyway?) is not necessarily what is "right"; and surely has no bearing on the legitimacy of asking a question. In this particular case, source address spoofing in the past has been used for both good (censorship-busting: google for "Triangle Boy") and bad (DoS attacks) purposes, so most providers have taken to filter IP packets from the edge with unexpected source IP addresses. This makes the whole issue kind of moot... Enzo From matthew at matthew.at Mon Jun 20 15:40:10 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] Spoofing source address to tunnel through address-restricted/symmetric NAT In-Reply-To: <42B680A8.7030309@quinthar.com> Message-ID: <200506201540.j5KFeaU06375@where.matthew.at> In the general case this won't work, because odds are (extremely) high that the ISP the "other clients" are attached to is doing filtering that won't allow their spoofed-source UDP packets to reach the destination. This has been a "best practice" for ISPs for years now (see the NANOG archives to find out just how many years), so is nearly universally deployed, especially on consumer broadband networks (and university networks) where the potential for abuse is highest. Actually trying this is easy if you can generate raw IP datagrams (requires root on a Unix machine (including MacOS X), can't be done without driver work on older Windows, is easy on XP, is limited in what you can generate on XP SP2)... After all, the IP and UDP header just isn't that complicated to synthesize. You would, of course, also need a UDP-based transport protocol that you could modify to work this way and which wasn't dependent on the source address for demultiplexing who it was talking to... after all, everyone who makes it through their ISP's filters will have the same source address, and that's typically how you figure out "who this packet came from". The amicima MFP protocol (which we hope to release in just a few more weeks in open-source form) would work, since it doesn't rely on the source address to demultiplex incoming datagrams to the associated sessions as a side effect of its IP address mobility capability. Matthew Kaufman matthew@matthew.at www.amicima.com From coderman at gmail.com Mon Jun 20 18:16:34 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> <4ef5fec605061915485f414b97@mail.gmail.com> Message-ID: <4ef5fec6050620111650e0ba7e@mail.gmail.com> On 6/19/05, Nick Johnson wrote: > How is the use or otherwise of a tracker in any way related to the use of > rateless codes? coordinating exchange of authentic blocks of coded content is the crux of the issue. if you have centralized control, error / online coding does not get you any benefit over the current method of using verbatim blocks of data. in a decentralized context, meaning no centralized tracker, the issue of authentic coded blocks is difficult and conveniently not described in the network coding paper. if you can do this efficiently then there is potential that network coding (with each peer performing re-encodes with current data) can be efficient without requiring the centralized control that is critical to the current unencoded block transfer coordination in bittorrent. From coderman at gmail.com Mon Jun 20 19:24:13 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <20050616213649.GG25592@zot.electricrain.com> References: <20050616213649.GG25592@zot.electricrain.com> Message-ID: <4ef5fec605062012246bbe3d5b@mail.gmail.com> On 6/16/05, Gregory P. Smith wrote: > This paper on using network coding for p2p content distribution swarm > speedups is interesting. > > http://www.research.microsoft.com/~pablo/papers/nc_contentdist.pdf Bram has responded to this paper via: http://www.livejournal.com/users/bramcohen/20140.html it looks like he has not considered it in detail as of yet: "some people will point out that 'error correcting codes' isn't the right term for the latest and greatest of this sort of technology, to which I say 'whatever'" also: "The really big unfixable problem with error correction is that peers can't verify data with a secure hash before they pass it on to other peers. As a result, it's quite straightforward for a malicious peer to poison an entire swarm just by uploading a little bit of data. The Avalanche paper conveniently doesn't mention that problem." as mentioned this is one of the previously discussed but not disclosed in detail techniques that makes network coding trustworthy in this context. you can be sure this is patented in Avalanche. (has anyone seen a relevant USPTO app for it yet?) From m.rogers at cs.ucl.ac.uk Mon Jun 20 21:15:02 2005 From: m.rogers at cs.ucl.ac.uk (Michael Rogers) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] zipf's law In-Reply-To: References: Message-ID: <42B731D6.30400@cs.ucl.ac.uk> Hi John, You might also be interested in this paper: http://www.eecs.harvard.edu/~michaelm/NEWWORK/postscripts/history.pdf The crux of it is that lognormal and Zipf distributions can be generated using very similar multiplicative growth models. Cheers, Michael John Casey wrote: >Dear All, > >I was wondering if any one might help explain what is the best way to >generate random variables that are distributed according to a zipf >distribution with a slope of -1 and an output range of 1 to 30. I have >tried using cern's cern.jet.random.Distributions nextZipfInt(... ) >(see http://hoschek.home.cern.ch/hoschek/colt/V1.0.3/doc/cern/jet/random/Distributions.html) >but the output of this generator is severely clipped if I attempt to >change the output range. I have also tried generating a series of data >points that are derived using zipf's law and have been able to >uniformly at random sample these values. This method seems to work >quite, and the distribution of sampled values better approximates >zipf's law than using the cern random generator. In terms of >methodology is this method acceptable?? it seems to be a bit of a >kludge to me. But I am having difficulty finding a better solution. >Any ideas ?? thanks. >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers >_______________________________________________ >Here is a web page listing P2P Conferences: >http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > > From arachnid at notdot.net Mon Jun 20 21:55:02 2005 From: arachnid at notdot.net (Nick Johnson) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: <4ef5fec6050620111650e0ba7e@mail.gmail.com> References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> <4ef5fec605061915485f414b97@mail.gmail.com> <4ef5fec6050620111650e0ba7e@mail.gmail.com> Message-ID: On 21/06/2005, at 6:16 AM, coderman wrote: > On 6/19/05, Nick Johnson wrote: > >> How is the use or otherwise of a tracker in any way related to the >> use of >> rateless codes? >> > > coordinating exchange of authentic blocks of coded content is the crux > of the issue. if you have centralized control, error / online coding > does not get you any benefit over the current method of using verbatim > blocks of data. > > in a decentralized context, meaning no centralized tracker, the issue > of authentic coded blocks is difficult and conveniently not described > in the network coding paper. if you can do this efficiently then > there is potential that network coding (with each peer performing > re-encodes with current data) can be efficient without requiring the > centralized control that is critical to the current unencoded block > transfer coordination in bittorrent. Trackers in BitTorrent don't deal with individual data blocks - only peer discovery. -Nick Johnson From dbarrett at quinthar.com Mon Jun 20 22:06:52 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] Spoofing source address to tunnel through address-restricted/symmetric NAT In-Reply-To: <200506201540.j5KFeaU06375@where.matthew.at> References: <200506201540.j5KFeaU06375@where.matthew.at> Message-ID: <42B73DFC.5000401@quinthar.com> Ah, thanks Matthew for the detail. So, it sounds like this wouldn't be practical for true P2P as raw socket support would prohibitively restrict deployment, and most consumer ISPs would block outbound spoofed UDP packets anyway. However, that still leaves the serverside. Assuming you were able to find a colo that'd let you dump spoofed UDP onto the backbone, would consumer ISPs block *inbound* spoofed UDP packets? How would they even know? The theoretical advantage of this would be for rendezvous and relay services, where servers need to occassionally contact clients. In the case of a geographically-distributed server farm, a client needs to separately hole-punch to each server, which is a pain. Using serverside spoofed UDP, you might get around this. And as for the legal/ethical issues of using spoofed UDP, if I'm spoofing traffic from one of my own servers (ie, server B is spoofing packets from server A, but both are owned by me) then I see no cause for complaint. -david Matthew Kaufman wrote: > In the general case this won't work, because odds are (extremely) high that > the ISP the "other clients" are attached to is doing filtering that won't > allow their spoofed-source UDP packets to reach the destination. > > This has been a "best practice" for ISPs for years now (see the NANOG > archives to find out just how many years), so is nearly universally > deployed, especially on consumer broadband networks (and university > networks) where the potential for abuse is highest. > > Actually trying this is easy if you can generate raw IP datagrams (requires > root on a Unix machine (including MacOS X), can't be done without driver > work on older Windows, is easy on XP, is limited in what you can generate on > XP SP2)... After all, the IP and UDP header just isn't that complicated to > synthesize. > > You would, of course, also need a UDP-based transport protocol that you > could modify to work this way and which wasn't dependent on the source > address for demultiplexing who it was talking to... after all, everyone who > makes it through their ISP's filters will have the same source address, and > that's typically how you figure out "who this packet came from". The amicima > MFP protocol (which we hope to release in just a few more weeks in > open-source form) would work, since it doesn't rely on the source address to > demultiplex incoming datagrams to the associated sessions as a side effect > of its IP address mobility capability. > > > Matthew Kaufman > matthew@matthew.at > www.amicima.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 coderman at gmail.com Mon Jun 20 23:05:23 2005 From: coderman at gmail.com (coderman) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] network coding put to practical p2p content dist. use In-Reply-To: References: <20050616213649.GG25592@zot.electricrain.com> <4ef5fec605061615513bd83560@mail.gmail.com> <4A7BBD17-7F4C-4D1C-A590-D164C23E1CAE@notdot.net> <4ef5fec605061915485f414b97@mail.gmail.com> <4ef5fec6050620111650e0ba7e@mail.gmail.com> Message-ID: <4ef5fec6050620160522b9df30@mail.gmail.com> On 6/20/05, Nick Johnson wrote: > ... > Trackers in BitTorrent don't deal with individual data blocks - only > peer discovery. i explained that very poorly, my apologies. by centralized i meant the metadata contained in the torrent, which consists of finite blocks and their SHA1 digest (among other details) and the authoritative introduction performed by the tracker(s) referenced in the torrent metadata. in this case peers can only exchange the exact blocks defined in the torrent and will (currently) only discover peers through the authoritative tracker(s). there are ways to improve efficiency in this situation dealing with coordination between peers and/or trackers (for example, intelligent trackers that order peers in the list in particular ways, the super seeder modes for rapid seeding of popular torrents, etc) but these all deal with scheduling of the same static blocks. authenticated network codes would allow peers to send freshly coded chunks of a current dataset without any predefined block offsets. the two advantages this could provide (assuming CPU/memory costs are not prohibitive) are: - introduction outside of a .torrent/tracker, since peers no longer need to be exchanging the exact same fixed blocks, only the same data (and yet still be able to trust a given network coded chunk) - less complicated scheduling because of the way novel bits are incorporated into subsequent re-encoded blocks, thus obviating the need for some of the complicated scheduling used by trackers and/or peers / superseeders. this is the core difference i meant to reference in earlier posts. bittorrent as it currently works with distinct authenticated blocks in metadata and tracker introduction will not benefit from network coding or other online / error coding (over the internet), the efficiency tweaks possible can be done on a blocking / scheduling basis. network codes might be able to approach the same high efficiencies without a fixed set of blocks and with less need for smarts in a tracker or seeder peer. which in turn makes them well suited for the types of edge cases the authors cite as problematic for bittorrent efficiency: large heterogeneous networks (tracker overload?), high peer churn (block scheduling/tracker overload?), and flash crowds (the superseeders). From chen28mo at 21cn.com Tue Jun 21 12:44:00 2005 From: chen28mo at 21cn.com (=?gb2312?B?s8LErQ==?=) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] about p2p simulation Message-ID: I'm going to collect some trace in Gnutella network and do some p2p simulation based on the trace collected. However,I have some questions about p2p simulation and trace collecting. Questions: 1. Which p2p simulation(specially for gnutella) is good and preferred? (NS2,PLP2P,NeuroGrid,Gnutellasim,etc) 2 Which method collecting p2p trace is effective, monitoring the p2p traffic passively or crawler technique? Does someone provide me some traces of gnutella or kazaa? And I also hope abtain a modified gnutella software (like gtk-gnutella)can collect gnutella trace. Thanks a lot. best, jowe 2005-6-20 From dcarboni at gmail.com Fri Jun 24 10:54:32 2005 From: dcarboni at gmail.com (Davide Carboni) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] infinite loops Message-ID: <71b79fa9050624035452fd4813@mail.gmail.com> I notice that most of p2p protocols use TTL to prevent infinite loops. I was wondering why they do not use the following technique: - each node stores a cache of all message IDs received from neighbors -if an incoming message has an ID not in the cache, then the ID is added and the message is relayed -else if the incoming message has an ID alraedy in the cache it is simply ignored. -- I have made this letter longer than usual because I lack the time to make it shorter. B. Pascal From behnel_ml at gkec.informatik.tu-darmstadt.de Fri Jun 24 11:17:20 2005 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] infinite loops In-Reply-To: <71b79fa9050624035452fd4813@mail.gmail.com> References: <71b79fa9050624035452fd4813@mail.gmail.com> Message-ID: <42BBEBC0.8090104@gkec.informatik.tu-darmstadt.de> Davide Carboni schrieb: > I notice that most of p2p protocols use TTL to prevent infinite loops. > I was wondering why they do not use the following technique: > > - each node stores a cache of all message IDs received from neighbors > -if an incoming message has an ID not in the cache, then the ID is > added and the message is relayed > -else if the incoming message has an ID alraedy in the cache it is > simply ignored. Ok, hum, for how long exactly would you store such a cached ID and how would you handle the case where a message actually has to pass through you twice because some other node incidentally changed its position in the topology? Stefan From behnel_ml at gkec.informatik.tu-darmstadt.de Fri Jun 24 12:09:20 2005 From: behnel_ml at gkec.informatik.tu-darmstadt.de (Stefan Behnel) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] infinite loops In-Reply-To: <71b79fa905062404557b8f732a@mail.gmail.com> References: <71b79fa9050624035452fd4813@mail.gmail.com> <42BBEBC0.8090104@gkec.informatik.tu-darmstadt.de> <71b79fa905062404557b8f732a@mail.gmail.com> Message-ID: <42BBF7F0.5000603@gkec.informatik.tu-darmstadt.de> Davide Carboni wrote: >>>I notice that most of p2p protocols use TTL to prevent infinite loops. >>>I was wondering why they do not use the following technique: >>> >>>- each node stores a cache of all message IDs received from neighbors >>>-if an incoming message has an ID not in the cache, then the ID is >>>added and the message is relayed >>>-else if the incoming message has an ID alraedy in the cache it is >>>simply ignored. >> >>Ok, hum, for how long exactly would you store such a cached ID > > assuming an ID of 8 bytes, you can store 10^7 ID with 80MB of RAM. If > the average message rate on the node is 100 m/s you can keep the ID > for 10^5 seconds which is not so little time Ok, I assume that is the best thing to do with 80MB of RAM. No, seriously. Why waste a big part of memory for an error prone cache if you can waste one byte in a message that assures handling of all possible errors? Including broken messages, topology restructuring, etc. >>and how would >>you handle the case where a message actually has to pass through you twice >>because some other node incidentally changed its position in the topology? > > ...then I ignore the message, that's all. I've already relayed it to > the other neighbors Then why do you think it came back? Do you think it has reached its destination? Stefan From will at memefeeder.com Fri Jun 24 13:34:33 2005 From: will at memefeeder.com (Will Morton) Date: Sat Dec 9 22:13:00 2006 Subject: TTLs (was Re: [p2p-hackers] infinite loops) In-Reply-To: <71b79fa9050624035452fd4813@mail.gmail.com> References: <71b79fa9050624035452fd4813@mail.gmail.com> Message-ID: It's a trade-off between using memory on your machine and wasting bandwidth on the network... Why not use a hybrid approach? You can keep a suitably small message ID cache to prevent tight loops such as 'A->B->C->A' where the TTL would still be high enough for the message to go round the loop a few times - and if this is your goal, you'd only need to cache the ID for a few seconds so you'll only use a few K for your cache. Then use a TTL as well to prevent more circuitous loops. HTH Will On 24 Jun 2005, at 11:54, Davide Carboni wrote: > I notice that most of p2p protocols use TTL to prevent infinite loops. > I was wondering why they do not use the following technique: > > - each node stores a cache of all message IDs received from neighbors > -if an incoming message has an ID not in the cache, then the ID is > added and the message is relayed > -else if the incoming message has an ID alraedy in the cache it is > simply ignored. > > > > > > -- > I have made this letter longer than usual because I lack the time to > make it shorter. > B. Pascal > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > _______________________________________________ > Here is a web page listing P2P Conferences: > http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2388 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050624/1bed426a/smime.bin From gbildson at limepeer.com Fri Jun 24 14:26:38 2005 From: gbildson at limepeer.com (Greg Bildson) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] infinite loops In-Reply-To: <71b79fa9050624035452fd4813@mail.gmail.com> Message-ID: The problem isn't infinite loops. It is a question of total network cost of a query. TTL based networks are *not* trying to achieve full network coverage of a query. They are trying to give you a defined horizon for a query that is likely big enough. The costs of queries in a broadcast or semi-broadcast network grow exponentially as the horizon increases (based on TTL and hops). If you try to ensure that your query will reach the entire network when the network is 100,000 users then it will become much more expensive to do that when the network reaches 1,000,000 users. There has to be a cap on the horizon and a TTL provides that cap. You can work out some pretty staggering bandwidth measurements per node if you assume that 1 in 100 users is sending a full network query every minute. Thanks -greg > -----Original Message----- > From: p2p-hackers-bounces@zgp.org [mailto:p2p-hackers-bounces@zgp.org]On > Behalf Of Davide Carboni > Sent: Friday, June 24, 2005 6:55 AM > To: Peer-to-peer development. > Subject: [p2p-hackers] infinite loops > > > I notice that most of p2p protocols use TTL to prevent infinite loops. > I was wondering why they do not use the following technique: > > - each node stores a cache of all message IDs received from neighbors > -if an incoming message has an ID not in the cache, then the ID is > added and the message is relayed > -else if the incoming message has an ID alraedy in the cache it is > simply ignored. > > > > > > -- > I have made this letter longer than usual because I lack the time to > make it shorter. > B. Pascal > _______________________________________________ > 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 matthew at matthew.at Fri Jun 24 14:45:13 2005 From: matthew at matthew.at (Matthew Kaufman) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] infinite loops In-Reply-To: <71b79fa9050624035452fd4813@mail.gmail.com> Message-ID: <200506241445.j5OEjiU13627@where.matthew.at> 1. Your approach assumes that you want the message delivered as far as possible within the network. In some networks this cache technique is used to reduce looping and redelivery *along with* TTL in order to deliberately limit the message delivery horizon. 2. Your approach assumes that originators can generate unique message Ids. This is easy to approximate but non-trivial to guarantee if you're trying to save memory or computation time. Consider the case of IP... What would you use as the "unique message ID"? 3. Your approach uses more memory in the client no matter how long the message ID storage needs to be. The longer the potential message lifetime, the more memory it uses. The higher the message rate, the more memory it uses. The longer the message IDs, the more memory it uses. The more complex the lookup data structure, the more memory it uses. Also, doing that lookup is more computationally expensive, especially as the memory utilization grows. In summary, if you want messages delivered as widely as possible, and the clients can generate unique message IDs, and the message rate is low enough that the CPU and memory requirements created at each client are reasonable, then sure, this works fine. Matthew Kaufman matthew@matthew.at www.amicima.com From lemonobrien at yahoo.com Fri Jun 24 16:57:17 2005 From: lemonobrien at yahoo.com (Lemon Obrien) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] infinite loops In-Reply-To: <200506241445.j5OEjiU13627@where.matthew.at> Message-ID: <20050624165718.83117.qmail@web53606.mail.yahoo.com> the problem is, how long do you keep the message in the cache....you can only genereate so many ids, and there are bound to be conflicts...memory and how many messages per second is the node recieving...each message needs to be stored. Matthew Kaufman wrote:1. Your approach assumes that you want the message delivered as far as possible within the network. In some networks this cache technique is used to reduce looping and redelivery *along with* TTL in order to deliberately limit the message delivery horizon. 2. Your approach assumes that originators can generate unique message Ids. This is easy to approximate but non-trivial to guarantee if you're trying to save memory or computation time. Consider the case of IP... What would you use as the "unique message ID"? 3. Your approach uses more memory in the client no matter how long the message ID storage needs to be. The longer the potential message lifetime, the more memory it uses. The higher the message rate, the more memory it uses. The longer the message IDs, the more memory it uses. The more complex the lookup data structure, the more memory it uses. Also, doing that lookup is more computationally expensive, especially as the memory utilization grows. In summary, if you want messages delivered as widely as possible, and the clients can generate unique message IDs, and the message rate is low enough that the CPU and memory requirements created at each client are reasonable, then sure, this works fine. Matthew Kaufman matthew@matthew.at www.amicima.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 You don't get no juice unless you squeeze Lemon Obrien, the Third. --------------------------------- Discover Yahoo! Get on-the-go sports scores, stock quotes, news & more. Check it out! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20050624/d857fcaf/attachment.htm From lgonze at panix.com Fri Jun 24 21:30:25 2005 From: lgonze at panix.com (Lucas Gonze) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] infinite loops In-Reply-To: <20050624165718.83117.qmail@web53606.mail.yahoo.com> References: <20050624165718.83117.qmail@web53606.mail.yahoo.com> Message-ID: <42BC7B71.1010509@panix.com> I fiddled around with a fuzzy TTL technique where you mask your own ID into a bloom filter that travels along with the message, the idea being that you stop if you see your ID in there. As the message propagates the filter is more and more densely populated, so that eventually the likelihood of a false positive is high enough that you have the same effect as with a TTL. What I was trying to produce was a way for nodes to recognize messages without spending memory and without increasing the size of the message. ...this was not incredibly productive, given that a real TTL does the same thing with a less complication, but maybe it is an idea that will inspire a better one. - Lucas Lemon Obrien wrote: > the problem is, how long do you keep the message in the cache....you > can only genereate so many ids, and there are bound to be > conflicts...memory and how many messages per second is the node > recieving...each message needs to be stored. > > */Matthew Kaufman /* wrote: > > 1. Your approach assumes that you want the message delivered as far as > possible within the network. In some networks this cache technique > is used > to reduce looping and redelivery *along with* TTL in order to > deliberately > limit the message delivery horizon. > > 2. Your approach assumes that originators can generate unique > message Ids. > This is easy to approximate but non-trivial to guarantee if you're > trying to > save memory or computation time. Consider the case of IP... What > would you > use as the "unique message ID"? > > 3. Your approach uses more memory in the client no matter how long the > message ID storage needs to be. The longer the potential message > lifetime, > the more memory it uses. The higher the message rate, the more > memory it > uses. The longer the message IDs, the more memory it uses. The > more complex > the lookup data structure, the more memory it uses. Also, doing > that lookup > is more computationally expensive, especially as the memory > utilization > grows. > > In summary, if you want messages delivered as widely as possible, > and the > clients can generate unique message IDs, and the message rate is > low enough > that the CPU and memory requirements created at each client are > reasonable, > then sure, this works fine. > > Matthew Kaufman > matthew@matthew.at > www.amicima.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 > > > > You don't get no juice unless you squeeze > Lemon Obrien, the Third. > > Discover Yahoo! > Get on-the-go sports scores, stock quotes, news & more. Check it 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 > > From tutschku at informatik.uni-wuerzburg.de Sat Jun 25 11:11:54 2005 From: tutschku at informatik.uni-wuerzburg.de (Kurt Tutschku) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] CFP : 3rd International Workshop on Mobile Peer to Peer Computing MP2P 06, in conjunction with the 4th IEEE International Conference on Pervasive Computing and Communications PerCom 06 Message-ID: <001801c57976$b2a8dcc0$6402a8c0@musa> (Please apologize multiple copies) --------------------------------------------------------------------- Call-for-Paper 3rd International Workshop on Mobile Peer-to-Peer Computing (MP2P'06) http://www-info3.informatik.uni-wuerzburg.de/mp2p2006 Pisa, Italy, March 17, 2006 In conjunction with the 4th IEEE International Conference on Pervasive Computing and Communications (PerCom?06) http://www.percom.org/ ---------------------------------------------------------------------- Peer-to-Peer (P2P) computing is a networking and distributed computing paradigm which allows the sharing of computing resources and services by direct, symmetric interaction between computers. The advance in mobile wireless communication technology and the increasing number of mobile users, extend the arena of P2P computing to encompass mobile devices and wireless networks. The special characteristics of mobile environments, such as highly variable connectivity, disconnection, location-dependency, resource constraints, and diversity in wireless networks as well as carrier-grade performance requirements bring new challenges for research in mobile P2P computing. MP2P?06 is intended to serve as a continuing forum for scientists and engineers in academia and industry to exchange and discuss their experiences, new ideas, and research results about all aspects of mobile P2P computing. It will address the challenges, technologies, and architectures leading to real-world solutions that provide users with direct access and control of their critical peer-based information and services, regardless of location or device. The principal theme of MP2P?06 is the development of protocols, systems and architectures of mobile P2P architectures and the evaluation of their performance. Topics of particular interest include, but are not limited to: - Architecture and platforms for mobile P2P computing - Measurement studies on mobile P2P systems - Performance of mobile P2P services - Resource and service discovery in mobile P2P computing - Resource exchange mechanisms in mobile P2P application - Mobile P2P over different kinds of bearer services: 2.5/3G (GPRS/UMTS) / 802.11 (WLAN) - Mobile P2P & operator/provider requirements - Reliability and carrier-gradeness of mobile P2P services - Mobile P2P & fixed P2P system interworking - Issues of combining P2P services with mobility (mobile IP / MANET) - Peer access and control in mobile environment - Location dependent mobile P2P services - Data exchange and rendering techniques for mobile devices - Secure communication protocols for mobile P2P computing - Mobile P2P messaging systems - Peer-to-peer broadband wireless communications - Applications of mobile P2P - Nature-inspired algorithms for mobile P2P computing - Theoretical issues on mobile information diffusion - Mobile P2P video games - Stimulating cooperation in mobile computing Paper Submission: ----------------- Papers must be written in English and should not exceed 6 pages in IEEE proceedings style. Authors MUST submit their papers through the EDAS web site (http://www.edas.info/) in three steps: * Creation of a personal account on EDAS (if the author does not already have one) * Registration of the paper (requiring a short abstract of up to 150 words) * Upload of the paper. Only in pdf format Submission implies the willingness of at least one of the authors to register and present the paper. All submissions will be reviewed and selected based on their originality of the paper. Accepted papers must be presented at the workshop and will appear in a combined PerCom 2006 workshop proceedings published by IEEE Computer Society Press. Authors that present a system in their paper are highly encouraged to demonstrate also the system in the demo session of the workshop. Important Dates: ---------------- Papers due: 5pm EST, September 15, 2005 Notification of acceptance November 15, 2005 Camera-ready papers due December, 2005 Organizing Committee, Program Co-chairs: ---------------------------------------- - Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany. - Frank-Uwe Andersen, Siemens Communications, Berlin, Germany. - Li Li, Communications Research Center Canada, Canada. - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill, USA Steering Board -------------- - Jiannong Cao, Department of Computing, Hong Kong Polytechnic University. - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University - Cecilia Mascolo, Department of Computer Science, University College London - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill Publicity Chair --------------- Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany Program Committee Members (To be confirmed): -------------------------------------------- - Frank-Uwe Andersen, Siemens Communications, Germany. - Christian Bettstetter, DoCoMo Euro-Labs,Germany. - Jiannong Cao, Department of Computing, Hong Kong Polytechnic University. - Miguel Castro, Microsoft Research Ltd, Great Britain. - Luca Caviglione, CNIT - University of Genoa Research Unit, University of Genova, Italy. - Geoff Coulson, Computing Department, University of Lancaster, UK. - Eyal de Lara, Department of Computer Science, University of Toronto, Canada. - Hermann de Meer, Department of Computer Networks & Computer Communications, University of Passau, Germany. - Babak Esfandiari, Carleton University, Canada. - Kevin Fall, Berkeley Research Labs Intel Corporation, USA. - Stephen Hailes, Department of Computer Science, University College of London, UK - Felix Hernandez-Campos, Department of Computer Science, University of North Carolina at Chapel Hill, USA - Yih-Chun Hu, Electrical Engineering and Computer Sciences, University of California, Berkeley, USA - Y. Charlie Hu, School of Electrical and Computer Engineering, Purdue University - Valerie Issarny, INRIA, France. - Thomas Kunz, Dept. of Systems and Comp. Engineering, Carleton University. Canada. - Wolfgang Kellerer, DoCoMo DoCoMo Communications Laboratories Europe, Germany. - Eyal de Lara, Department of Computer Science, University of Toronto, Canada - Karen Lawson, Kodak Ltd. R&D, UK - Li Li, Communications Research Center Canada, Canada. - Christoph Lindemann, FB Informatik IV, University of Dortmund, Germany. - Haiyun Luo, Department of Computer Science, University of Illinois at Urbana-Champaign, USA - Cecilia Mascolo, Department of Computer Science, University College London - Maria Papadopouli, Department of Computer Science, University of North Carolina at Chapel Hill - Rudolf Riedi, Department of Statistics, Rice University, USA - George Roussos, School of Computer Science and Information Systems, Birkbeck College, University of London, UK - Shervin Shirmohammadi, School of Information Technology and Engineering (SITE), University of Ottawa, Canada. - Apostolos Traganitis, Department of Computer Science, University of Crete, Greece - Kurt Tutschku, Department of Distributed Systems, University of W?rzburg, Germany. - Ben Zhao, Computer Science Dept., University of California at Santa Barbara, USA. --- Dr. Kurt Tutschku, Assistant Professor University of Wuerzburg Department of Distributed Systems Institute of Computer Science Am Hubland 97074 Wuerzburg Germany Tel.: +49-931-8886641 FAX.: +49-931-8886632 mailto:tutschku@informatik.uni-wuerzburg.de or mailto:kurttutschku@hotmail.com http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku From decapita at dti.unimi.it Sat Jun 25 11:48:41 2005 From: decapita at dti.unimi.it (Sabrina De Capitani di Vimercati) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] WPES 2005: Deadline extension (June 30) Message-ID: [Apologies if you receive multiple copies of this message] CALL FOR PAPERS 4th WORKSHOP ON PRIVACY IN THE ELECTRONIC SOCIETY Alexandria, VA, USA - November 7, 2005 Sponsored by ACM SIGSAC Held in association with 12th ACM CCS 2005 http://wpes05.dti.unimi.it ------------------------------------------------------------------------ Due to several requests the deadline is extended to June 30, 2005 (firm) ------------------------------------------------------------------------ The need for privacy-aware policies, regulations, and techniques has been widely recognized. This workshop discusses the problems of privacy in the global interconnected societies and possible solutions. The 2005 Workshop, held in conjunction with the ACM CCS conference, is the fourth in a yearly forum for papers on all the different aspects of privacy in today's electronic society. The workshop seeks submissions from academia and industry presenting novel research on all theoretical and practical aspects of electronic privacy, as well as experimental studies of fielded systems. We encourage submissions from other communities such as law and business that present these communities' perspectives on technological issues. Topics of interest include, but are not limited to: - anonymity, pseudonymity, and unlinkability - business model with privacy requirements - data protection from correlation and leakage attacks - electronic communication privacy - information dissemination control - privacy-aware access control - privacy in the digital business - privacy enhancing technologies - privacy policies - privacy and anonymity in Web transactions - privacy threats - privacy and human rights - privacy and confidentiality management - privacy in the electronic records - privacy in health care and public administration - public records and personal privacy - privacy and virtual identity - personally identifiable information - privacy policy enforcement - privacy and data mining - relationships between privacy and security - user profiling - wireless privacy - economics of privacy 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. Submissions should be at most 15 pages excluding the bibliography and well-marked appendices (using 11-point font and reasonable margins on letter-size paper), and at most 20 pages total. Committee members are not required to read the appendices, and so the paper should be intelligible without them. Like last year, we plan to accept some of the submissions as full papers (15 pages), and we may accept some others as abstracts (3 pages) if they represent novel or interesting work that is not as developed. Papers are to be submitted electronically via the online submission system (http://www.softconf.com/start/CCS05-WEPS/submit.html). Through this form, you will be requested to upload the file of your paper (in PDF or portable postscript format). Do NOT upload files formatted for word processing packages (e.g., Microsoft Word or WordPerfect files). Submissions not meeting these guidelines risk rejection without consideration of their merits. Papers must be received by the deadline of June 24, 2005 in order to be considered. Notification of acceptance or rejection will be sent to authors by August 8, 2005. Authors of accepted full papers must guarantee that their paper will be presented at the workshop. Accepted papers will be published by the ACM in a conference proceedings GENERAL CHAIR Vijay Atluri Rutgers University, USA email: atluri@andromeda.rutgers.edu PROGRAM CHAIRS Sabrina De Capitani di Vimercati Roger Dingledine University of Milan The Free Haven Project, USA email: samarati@dti.unimi.it email: arma@mit.edu IMPORTANT DATES Paper Submission due: June 30, 2005 (NEW) Acceptance notification: August 8, 2005 Final papers due: September 5, 2005 PROGRAM COMMITTEE Alessandro Acquisti, Carnegie Mellon University Steven M. Bellovin, Columbia University, USA Nikita Borisov, University of California, USA Matthew Burnside, Columbia University, USA George Danezis, University of Cambridge, UK Hannes Federrath, Universitat Regensburg Philippe Golle, Palo Alto Research Center, USA Andrew Patrick, National Research Council, Canada Pierangela Samarati, University of Milan Matthias Schunter, IBM Zurich Research Laboratory, Switzerland Paul Syverson, Naval Research Laboratory, USA Chenxi Wang, Carnegie Mellon University, USA Brent Waters, Stanford University, USA Marianne Winslett, University of Illinois, USA From dbarrett at quinthar.com Wed Jun 29 04:08:28 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] STUN server bindings Message-ID: <42C21EBC.2080807@quinthar.com> The STUN protocol indicates: A STUN server MUST be prepared to receive Binding Requests on four address/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2, P2). Does this mean that a compliant STUN server must have two Ethernet cards, each configured with a different IP address? Or is it possible for a single computer with a single Ethernet card to send and receive via two different IP addresses? In general, how would such a thing be done on a Linux Fedora Core 2 server? Alternatively, does this mean I need to have two separate computers working together, such that server A can receive a STUN request with the CHANGE_IP flag set, and then it can request that server B send the response? -david From chris at chris-edwards.org Wed Jun 29 04:12:50 2005 From: chris at chris-edwards.org (Chris Edwards) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] STUN server bindings In-Reply-To: <42C21EBC.2080807@quinthar.com> References: <42C21EBC.2080807@quinthar.com> Message-ID: <42C21FC2.803@chris-edwards.org> David Barrett wrote: > The STUN protocol indicates: > > A STUN server MUST be prepared to receive Binding Requests on four > address/port combinations - (A1, P1), (A2, P1), (A1, P2), and (A2, > P2). > > Does this mean that a compliant STUN server must have two Ethernet > cards, each configured with a different IP address? Or is it possible > for a single computer with a single Ethernet card to send and receive > via two different IP addresses? In general, how would such a thing be > done on a Linux Fedora Core 2 server? Create aliases for the ethernet device. eg. eth0:1 eth0:2, ... Each can then have its own IP address. From dbarrett at quinthar.com Wed Jun 29 04:30:23 2005 From: dbarrett at quinthar.com (David Barrett) Date: Sat Dec 9 22:13:00 2006 Subject: [p2p-hackers] STUN server bindings In-Reply-To: <42C21FC2.803@chris-edwards.org> References: <42C21EBC.2080807@quinthar.com> <42C21FC2.803@chris-edwards.org> Message-ID: <42C223DF.9000205@quinthar.com> Chris Edwards wrote: > > Create aliases for the ethernet device. eg. eth0:1 eth0:2, ... > > Each can then have its own IP address. Oh. Cool, thanks for the fast reply. -david