The dark side of P2P column ...
[1/12] from: petr::krenzelok::trz::cz at: 14-May-2001 20:25
Hi, RT is advertising rebol as lightweight distributed system, where each client system is able to communicate. Now you can read what Jim Seymour thinks about P2P ... http://www.zdnet.com/pcmag/stories/opinions/0,7802,2711706,00.html -pekr-
[2/12] from: depotcity:telus at: 14-May-2001 12:02
A quote from the article... Now you're in a situation where your machine will accept any incoming TCP connection... Any TCP connection? Why would that be? TB
[3/12] from: john:schuhr at: 14-May-2001 16:15
Sorry if this seems like I'm bashing a "respected" columnist but: Ignore Jim Seymour. A) He's not very technical (compared to some of the ppl who post to this mailing list) B) He's a negativist. Of course there are issues with P2P, but he's using a random buzzword generator to write his articles. For example: since lots more traffic would be banging around on the Net among our newly 'serverized' P2P-ready PCs. Well, duh.. that's the point. But surprise! It's now *gasp* distributed among the network connections. Yes, the individual user's bandwidth will increase but we are in the 21st century for sobbing-out-loud. He doesn't really expect ppl to be using 56K dialup for the next 10 years. As for security.. good grief. Talk about paranoid and an overall doom-cryer. Yeah, if you host anything on your machine(s) at home, ppl will *gasp* connect to your box and do their thing. Some ppl play nice, others don't. That's when you use a neat little concept called a SANDBOX. Just wrap your hosted service in a secure process and *pling*, there isn't so much to worry about anymore. Are there security issues? Yes. Should we all just give up and jump off a cliff? Don't ask J. Seymour for advice. --John Schuhr
[4/12] from: ryanc:iesco-dms at: 14-May-2001 13:49
I dont know about "all ports open," but alot of machines that connect to the internet already have security issues anyway. P2P or not, any TCP using app is just going to add a mere blip to the already mess of security issues. As far as asymmetry, I would expect that this is only a really minor issue. P2P should just help elliviate the growth on the major pipelines, and it could even help ISP's keep communications inside. Its not like the net hasn't been growing all this time. This just means its current growth needs may be more symmetrical, versus asymetrical. I would imagine if you kept your dialup line connection up for a few days, not only your ISP would contact you, but so would the telephone company. Both these guys have seperate accounts for this type of activity--leased line. What about DSL and Cable? Some of these providers are have been already policing Quake servers and the like for a long time. Once again, nothing new. I am not saying the guy is completely out of his mind, I do think that P2P does raise security and symetry issues. I just think the way he speaks of them is out of proportion. The net is pretty resilent. It hardly choked during the "last days" of Napster. I dont think it will much worse than that anytime soon. --Ryan Petr Krenzelok wrote:
> Hi, > RT is advertising rebol as lightweight distributed system, where each client
<<quoted lines omitted: 6>>> [rebol-request--rebol--com] with "unsubscribe" in the > subject, without the quotes.
-- Ryan Cole Programmer Analyst www.iesco-dms.com 707-468-5400 I am enough of an artist to draw freely upon my imagination. Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -Einstein
[5/12] from: rebol:programmer at: 14-May-2001 16:04
> I would imagine if you kept your dialup line connection up for a few days,
not only your ISP would contact you, but so would the telephone company. Both these
> guys have seperate accounts for this type of activity--leased line.
I'm online with a dial-up account most of the time (I usually disconnect for about 30 seconds every 25-26 hours). My ISP has never said anything about it and neither has the phone company - Verizon (formerly GTE). I've been doing this for years without problems, but I know that most ISPs won't let you stay on this much ;-) Cal Dixon (who gets his internet access from a guy named "Dave")
[6/12] from: holger:rebol at: 14-May-2001 16:39
On Mon, May 14, 2001 at 08:25:29PM +0200, Petr Krenzelok wrote:
> Hi, > > RT is advertising rebol as lightweight distributed system, where each client > system is able to communicate. Now you can read what Jim Seymour thinks > about P2P ... > > http://www.zdnet.com/pcmag/stories/opinions/0,7802,2711706,00.html
Lightweight Distributed Computing is not the same as what most people these days mean by "P2P", nor does it need P2P (meaning P2P in its usual sense, i.e. using direct connections between clients, which is also how Jim Seymour uses the term). "Being able to communicate" does not necessarily mean being able to accept TCP connections and handle requests . It is possible to set up LDC environments with lightweight servers, which is exactly what REBOL/Express does, btw. In some environments it is also possible to use completely different types of solutions, e.g. based on broadcasting or multicasting, which does not really distinguish between clients and servers in the usual way. Jim Seymour is right on many points, and he does not even address all the issues of P2P. There are some more. When we started designing REBOL/Express and some other LDC features in REBOL we looked at transport-layer P2P very closely, and decided not to use P2P (in its strict sense) as its primary transport and session mechanism, because of its many problems. P2P (at the transport and session level) is probably one of the most overhyped concepts in recent years. It's funny though: that type of P2P communication has been around for decades. Windows Network Neighborhood is P2P, e.g., (and it is actually even REAL P2P, without the need for ANY server, unlike Napster, Gnutella, Groove etc). Still P2P people don't seem to like it though. I wonder why :-). Every few years or so someone seems to come up with that "really new idea" P2P which is "so much better than server-based", it stays around for a while and then dies or becomes obsoleted by better server-based solutions. The only P2P-based solutions which stay around for long are those designed excusively for LANs, using broadcasting or multicasting. People don't seem to learn though, and after a while the cycle repeats, and again someone somewhere tries to change the way transports and sessions work. Somehow with P2P people always seem to look at the promised advantages but completely ignore the overwhelming flaws and problems. Here are some: 1) P2P in the REALLY strict sense (i.e. no servers whatsoever) is impossible on the Internet, because you need some way for one peer to "find" other peers. That requires known, central addresses, i.e. servers. At the very least you need "registration servers" where peers providing a service need to register. Depending on the type of environment this can be a central server (Napster), many servers which also act as clients (Gnutella) or something based on existing central registration networks, e.g. DNS. The ONLY situation where you can get away with not having any central servers at all is if you can use broadcasting or multicasting, but this is not possible on the whole Internet (yet). This means almost all so-called P2P solutions which span more than a single LAN actually cheat. They are not really P2P at all, and in real life they don't give you the advantages P2P promises in theory. 2) If you need central servers anyway then the often cited argument that P2P provides additional robustness or redundancy becomes untrue. Actually in P2P both robustness and redundancy are usually worse than in server-based solutions: you have the same r/r bottlenecks for the registration servers, but the added problem that your "serverized clients" are not always rated as "real" servers, i.e. they tend to have more outages, in particular if they are really just "serverized clients" behind a DSL line, and outages tend to last longer (no RAID etc). 3) Bandwidth: there is not only the obvious problem that most DSL, Cable and modem lines are asymmetric, but there is also the bigger problem that with P2P more connections into the "outlying areas" of the Internet are needed to transmit the same amount of data to the same number of people. Example: transmitting a 10 MB file to 100 users using a well-connected server means you need 10 MB * (100 + 1) = 1010 MB of bandwidth on relatively slow ("client") lines: one upload and 101 downloads. Transmitting the same file by P2P means you need 10 MB * (100 + 100) = 2000 MB, almost twice the bandwidth. So the effect is not just that the ratio of uploads to downloads changes, but you also increase the total amount of bandwidth across client lines that you need. Yes, you save the server bandwidth, but server bandwidth is cheap, easily available, easy to optimize, tune, replicate, scale based on demand etc. Client bandwidth is not, and likely won't be for a long time. 4) Bandwidth (again): a LOT of systems these days are limited to 28800 (or 33600) bps in the upload direction, and this is not likely to change soon. Yes, DSL and Cable are catching on, but not quickly enough, and not in the very quickly growing mobile market. For the majority of connected devices high-speed Internet won't become a reality for many years. 5) Mobile environments, uptime: In order to transfer something by P2P BOTH sides need to be up at the same time, a big problem in the mobile market. Handheld devices make very bad P2P service providers because they get disconnected too quickly (drive through a tunnel, ride a subway or plane, battery empty etc.). With server-based solutions only one side has to be online at a time, whereas with P2P a time slot has to be found where both are online. 6) Firewalls, proxy servers, Intranets: server-based solutions are compatible to the majority of security systems out there (most compatible: HTTP tunnelling from client to server, which is what REBOL/Express uses as its default transport scheme). P2P solutions that require reverse connections usually cannot traverse firewalls or proxy servers. A huge problem for some companies out there with products that are exclusively based on P2P transports. 7) Accounting, monitoring: usually someone in your company wants to know how a service is used, i.e. how many transfers take place, what is transfered, who transfers data, etc., to get a sense of customer demand, to improve marketing etc. In server setups you just look at server logs, in P2P setups you, well, guess :-). 8) Security: securing the machine providing the service, as Jim described, is only part of the problem. Another part is access rights: How do you do that in distributed systems ? How do you revoke the privileges of, say, an employee who has left a company ? Another problem is certification: P2P environments make it significantly more difficult to deal with object or source certificates. Instead of trusting server certificates you would have to start using object-based certificate chains, and both Java and PGP show what a pain that tends to be, compared to the (transparent and seamless) server certificates SSL uses. 9) Content management: how do you manage your content, how do you handle versioning ? Updates ? Revokations ? Quality control ? For server-based setups you can establish administrative procedures for this. For P2P you have no control over who downloads what version of what product when. It is already a problem with FTP servers which have automatic replication, but in P2P setups it becomes much worse. To me it seems extremely foolish to blindly jump onto this P2P bandwagon, like some companies are doing, and this is not what LDC is about. P2P people are concentrating on the wrong thing: the technical aspects of the physical connection. Those aspects were solved 30 years ago, and the resulting solution (TCP, server-based) is just fine and usually superior to P2P. Reinventing the wheel, but worse, seems pointless to me. The problem these days is above the transport level. It is extremely difficult to design network applications that are small, functional, secure, compatible among platforms and versions, easy to debug, easy to upgrade etc. This is where LDC comes in. LDC is not about the technical aspects of physical connections. It is about how to exchange data, how to format data, how to secure data, how to parse data, how to interpret data, how to quickly and easily design software that allows multiple machines to communicate, how to do so on a large number of platforms, how to visualize received data and to interact with the user, how to add networking capabilities to existing applications in an easy way, with a single implementation that works on all platforms, without spending months designing ".NET" spec files, ASN.1 descriptions, Java class hierarchies etc., how to send data that is smart, in real-time, instead of having to design, implement and debug applications that are smart and predict what data they are used with years before the first byte of data is ever exchanged. Long sentence :-). REBOL provides a single, consistent environment that can be used in ALL parts of the networked application, including GUI creation, user input, data generation, information exchange, communication with back-end servers, response generation, encryption, parsing, data visualization, data storage etc. Keeping data and application models consistent throughout the application and across platforms saves time, reduces opportunities for bugs, and simplifies and encourages the development of networked applications of all kinds. THAT is what LDC is about. As for LDC and P2P: we believe in peer-to-peer as something that has to happen at a much higher level: the concept should exist all the way up at the application layer, not down at the transport layer, as with most so-called P2P environments. Which transport mode is used for any individual application should be irrelevant, and should certainly not spawn religious discussions. It is easy to write applications which actually support more than one transport mode, e.g. server-based, peer-to-peer, broadcast/multicast etc. all in one application. We like to think that LDC is a "better P2P" in the sense that it provides P2P functionality where it counts: at the point where applications interact. REBOL simplifies the development of networked applications. LDC allows the development of applications that allow Jim in Houston to easily communicate with John in Los Angeles: peer-to-peer communication at the application level, without worrying how this actually works "under the hood", i.e. whether servers are involved or not. -- Holger Kruse [holger--rebol--com]
[7/12] from: thundrebol:yah:oo at: 14-May-2001 16:45
From what I've read on the site, RT is promoting a client-side processing technology that leverages the current server-browser model of the Internet. What REBOL/View may have in common with some P2P applications is that it enables "weblications"-- app functionality and connectivity that provides a different user experience than the model supported by browsers. Jim Seymour's technical arguments are a bit thin, but that's beside the point (aren't SMTP servers a peer-to-peer server technology?). Seymour and other journalists are shackling the demise of an application (Napster) to a technology (P2P). If Napster wasn't peer-to-peer but it still let you type the name of a song and listen to it, it would have been just as popular. Joel Spolsky -- http://joel.editthispage.com/stories/storyReader$320 //Ed -- Petr Krenzelok <[petr--krenzelok--trz--cz]> wrote:
[8/12] from: larry:ecotope at: 14-May-2001 18:10
Holger, Thanks for the excellent discussion of P2P versus REBOL LDP. Very helpful. -Larry
[9/12] from: ryanc:iesco-dms at: 14-May-2001 17:53
Ed O'Connor wrote:
<snip> > "If Napster wasn't peer-to-peer but it still let you > type the name of a song and listen to it, it would > have been just as popular." > Joel Spolsky -- > http://joel.editthispage.com/stories/storyReader$320
</snip> It probably would have worked alot better too. I think this is the real dark side of P2P. My estimate is that Napster was about 70% reliable, on a good day. Scary. Holger, you said: The ONLY situation where you can get away with not having any central servers at all is if you can use broadcasting or multicasting, but this is not possible on the whole Internet (yet). If you dont mind my asking, what did you mean by "(yet)"? --Ryan
[10/12] from: holger:rebol at: 14-May-2001 20:10
On Mon, May 14, 2001 at 05:53:40PM -0700, Ryan Cole wrote:
> Holger, you said: > > "The ONLY situation where you can get away with not having any central servers at all is if you can use broadcasting or multicasting, but this is not possible > on the whole Internet (yet)." > > If you dont mind my asking, what did you mean by "(yet)"?
Internet-wide broadcasting will obviously remain impossible :-), but Internet-wide multicasting is possible at least in theory now. The technical framework exists (at least for IPv4, it is still somewhat sketchy for IPv6), but the organizational framework is still spotty. At the moment there are several multicasting testbeds (the biggest one is the MBone), consisting of interconnected multicast "islands" in the Internet "ocean", plus a few ISPs and streaming content providers use multicasting in a limited fashion to save bandwidth on their streaming media feeds. At this time multicasting is somewhat difficult to set up because you have to configure "multicast tunnels" between multicast-capable routers in order to participate in multicasting. Eventually, once all Internet routers become multicast-capable, multicasting should become completely transparent, Internet-wide. Btw, REBOL does support multicasting :-). -- Holger Kruse [holger--rebol--com]
[11/12] from: pa:russo:perd at: 15-May-2001 9:44
>... >LDC is not about the technical aspects of physical connections. It is about
<<quoted lines omitted: 19>>>Holger Kruse >[holger--rebol--com]
Holger, your sentence was inspired, not only long. I think I'll steal it and put it on my "Perfect REBOL Evangelist's Guidebook". :-) -- Paolo Russo [pa--russo--perd--com] _________________ PERD s.r.l. Virtual Technologies for Real Solutions http://www.perd.com
[12/12] from: al:bri:xtra at: 15-May-2001 20:50
I've got a all you can eat dial up account. They toss me off at 8:00 AM and 5:00 PM for a minute or two, but that's not significant to me. Andrew Martin ICQ: 26227169 http://members.nbci.com/AndrewMartin/
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted