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