Boston Linux & UNIX was originally founded in 1994 as part of The Boston Computer Society. We meet on the third Wednesday of each month at the Massachusetts Institute of Technology, in Building E51.

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss] peer to peer software



On 06/15/2014 11:12 AM, Stephen Adler wrote:
> I want to thank you all for all the comments you've sent in about peer 2
> peer. It seems to me from reading the comments that p2p is basically all
> about p2p discovery. I also realize that from the discussion, the
> internet is now broken. The way p2p is obviously supposed to work is
> sending out a broadcast udp message querying "the internet" for peers.
> Back in 1990, that may have worked,

As Tom mentioned, it never worked, not on the general internet. 
Multicast is still alive and well, and used in LAN environments all the 
time.  However, it does not get used at large scale.  For the situations 
where everyone thought multicast would do the most good (e.g. Akami's 
CDN), it has so many issues (whether it be protocol deficiencies or 
router/switch support) that they end up rolling their own equivalent.

> So its all about
> seeding peer discovery through tricks and gimmicks. uploading an initial
> list of peers to an irc chat room, a web site, dynamic dns etc.
> Basically we are now in an era where we effectively have to hack the udp
> broad cast method. Further more, since now about everyone sits behind a
> NAT firewall, further hacks are needed for "outside ip discovery". It's
> as if we need to reboot the internet or build a new internet on top of
> the mess commercialization of the internet has done to it. I get this
> feeling that with all the firewalls spewed through the internet, the
> only port one can use is 80, and everything has to be proxyed through
> that port..... A sorry state of affairs...

Networking isn't easy...I take it someone told you it was?  Certain 
simple things are easy, sure.  But once you start talking about 
real-world issues beyond your LAN (firewalls, scale, etc), you're beyond 
the basic networking textbooks.

There's a constant tradeoff of usability (people have a strong desire 
for things to "just work") and security.  What makes you think 
"rebooting" would result in a different set of tradeoffs?  Most of the 
hideous holes that windows used to have were b/c M$ wanted network 
shares and such to work "out of the box" without needing a skilled 
sysadmin to set up.  Another example along the same vein: I want to be 
able to use multicast to discover the printer on my network, but I don't 
want the printer exposed to people outside my network.  I want to be 
able to set up NFS on my home network quickly and easily without 
exposing those things outside my house (and without having to be an 
expert on what all portmapper exposes about other services on my 
machine). How would a 'reboot' create a wholly different scenario?

FWIW nowadays it's not difficult to tunnel anything you want through 
port 80, so anyone with a firewall policy that only allows outgoing port 
80 is usually deluding themselves about the level of security they are 
enforcing.  Not that it helps if you have clients that live in such 
networks, other than letting you feel smug about how little they're 
getting from making your life so difficult...

Matt



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org