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:yaho:o 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/
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted