Industrial-Strength P2P 104
hhutkin writes "Business 2.0 has an article in their latest issue on Bill Joy and Sun's peer-to-peer play, Jxta." A bit light on details but still good to know progress is being made in the field of peer to peer apps. But don't expect anything useful any time soon.
I hope it changes my life as much as Jini did! (Score:3, Insightful)
A: Means I can do something I currently cannot (and want to do)
or
B: Does something so much better as to make my old methods obsolete
it doesn't excite me much. I think sharing illegal files was the killer app of P2P.
Re:I hope it changes my life as much as Jini did! (Score:1)
In both senses of the word.
Re:I hope it changes my life as much as Jini did! (Score:2)
Re:I hope it changes my life as much as Jini did! (Score:1)
Was?
Was... (Score:1)
Though I'm sure the RIAA would love to see it try.
Re:I hope it changes my life as much as Jini did! (Score:1)
Jini is a beauty. Sun's marketing engine is just not capable of boosting more than one product, which is why the J2EE suite is so much more widely accepted. Eventually the functionality offered by Jini can/will be replaced by XML/HTTP, but that does not make the ideas and design any less interesting.
Do you know anything about Jini at all? If not, I'd like to fill you in. In short it's an infrastructure for building dynamic distributed systems and I believe that it contains all the features you'd expect in a system designed for that.
Sun's attitude. (Score:2)
They come down off the mountain with these standards like they were revelations. I think this puts a lot of people on the defensive. No matter how open the standard is, Sun wants to keep reminding us that it was their idea.
In part it's also a chicken and egg problem. JXTA will have more value as it becomes a standard, but until then it has only marginal benefits over whatever proprietary system people use (and thus its adoption is slow).
I think people should concentrate on SOAP. There's no reason P2P couldn't be implemented this way instead.
Re:I hope it changes my life as much as Jini did! (Score:2)
I fear JXTA will go the same way. SUN is a server side company and it has never understood the client side. For example: Java's failure on the client side; the crappy GUI they ship with their OS and the fact that their most succesfull desktop products (forte and staroffice) were acquired rather than created at SUN. When they announced JXTA I was one of the dozens of puzzled folks who were left wondering what the fuss was about when you unzipped the demo.
Crappy GUI and *gasp* a unix shell like interface to the whole thing, apparently the only thing these guys grasp. I know it is only a demo app but it is hardly an inspiring one. Unless they get some real, useful and most importantly unique apps out based on JXTA that actually require JXTA (morpheus et al. demonstrate that mp3 sharing does not require such a poweful tool) it is doomed to fail.
When it comes to p2p, the UI is all that matters. Nobody cares about what is powering it. Long after the napster network collapsed, people were running napster: to play their mp3! Apple understands UIs so they created iPod: instant hit.
The only thing I see on the JXTA site is stuff I already have (and hence does not require JXTA). This tells me that the JXTA developers are as much in the dark as I am when it comes to the killer app JXTA so desparately needs. They have a cool idea but no clue as to what to do with it.
Many technologies die this way. A few years ago mobile agents were a hot thing. It never took off because people just couldn't figure out a useful application for it. There were many cool demos and prototypes and I had lots of fun playing with the aglet stuff from IBM but no useful application of all this technology. Same for 3d userinterfaces. We have the hardware to run 3d stuff, but other than games and CAD, this hardware is not used to replace the desktop metaphore. Then there's VRML: another cool idea that never took off. The message is clear, once the coolness wears off there has to be a reason to keep using a technology.
It would be cool to have my toaster instruct the coffee machine to download britney spears. However I hate britney spears and it would spoil my breakfast having to listen to her when all I wanted was some toast and coffee (which don't require either jini or JXTA). I'm not saying that SUN should abandon JXTA, I'm just telling them that if they continue the way they are doing things now, they might as well abandon it right now.
Re:I hope it changes my life as much as Jini did! (Score:1)
I'm sure the following people might disagree with you:
- U.S. Army [sun.com]
- Raytheon (U.S. Navy) [sun.com]
- Cisco [sun.com]
- eko systems (medical data and equipment) [sun.com]
- More success stories here [sun.com] and here [sun.com]
Jini isn't dead, it is just poorly marketed by Sun (Jini is about services not devices and what is the current trend in industry? - that's right, service based systems ala web services), probably because they've put all their eggs into the J2EE basket (which also has its place).
I strongly encourage you to re-evaluate Jini. It can be a truly powerful paradigm even for none Java enabled machines/devices (e.g. using a surrogate architecture).
Read the Jini FAQ [artima.com], see the following excellent article on Jini [javaworld.com] and have a look at the Jini user mailing list [sun.com] sometime and you will be surprised by how powerful Jini can be.
Who pays for P2P? (Score:4, Insightful)
Of course not all web sites have to make money. Once upon a time, pre-dot-com-boom, this was common knowledge. P2P networks run by dedicated enthusiasts may have the best chance of survival. Those are the kind of sites I've always liked best anyway...done for love, not money.
Re:Who pays for P2P? (Score:4, Insightful)
The question isn't who pays, it is who benefits.
Think of P2P as a way of efficiently distributing data and/or processing. The key word here is efficiently. Consider DNS, a distributed database. DNS is the system that was designed to allow the Internet to scale up from modest beginnings, and it exceeded expectations (and continues to do so) for scalability. It's the glue that keeps the Internet going, and which works better than a lot of newer, application-layer protocols (HTTP - been slashdotted lately?)
Therefore, an efficient and easily usable P2P framework allows application builders to build things that work better and faster than is available today. This isn't the new car - it's the new road.
Once you get the road built, then you start figuring out how to make money off of it. No one makes money off of DNS, but there's money to be made of the Internet that it enables (pr0n if nothing else!)
Re:Who pays for P2P? (Score:1)
No one makes money off of DNS . . .
These people [verisign.com] disagree, but I think they help prove your point :)
Re:Who pays for P2P? (Score:2)
OK [securityfocus.com].
Sale Value != Use Value (Score:2)
This stuff could become useful, in a business setting, for instance, by allowing employees to wander around with laptops with wireless network hardware, and have a self-assembling network. Within that sort of setting, the notion of "paid subscription" is ridiculous silliness. Money wouldn't be "made;" money would be saved over alternative ways of setting up networks.
Re:Sale Value != Use Value (Score:2)
Are you sure you're not thinking of JINI [sun.com]? Isn't JXTA just a application level framework for P2P type services, Napster, Gnutella, whatever?
Re:Who pays for P2P? (Score:2)
Take a P2P Knowledge Management system, I just made up in my fevered imagination. Small daemons on each employees PC offering different services, or search results, for queries sent scuttling around the network ala Gnutella. The query "Bob's Expenses" hitting the legal guy's machine could return one result, or service, hitting the accountants could provide another...
Off the top of my head, sure, but I'd bet plenty of firms would pay for that kind of thing. It's cheaper than buying big servers, for a start.
How does the "web" make money? (Score:3, Insightful)
How will p2p make money? It will not. Some companies/people might figure out a way to leverage it though.
Re:How does the "web" make money? (Score:2)
Re:Who pays for P2P? (Score:1, Insightful)
Who cares? (Score:2)
Since when does everything need to make someone lots of money?
In a true peer-to-peer system, the costs would be transparently distributed among the users in the form of their internet-connectivity bills. Since they are paying for those anyway, it wouldn't even be noticeable.
Re:Who pays for P2P? (Score:2)
Things like the CB radio range are free, but it's still possible to build a business on selling the radios, and this requires everyone agreeing on what the radios do.
Like FidoNet? (Score:1)
P2P is not just file sharing (Score:1)
Who makes money with the telephone? (Score:3, Insightful)
Actually, the fact that your mindset became widespread is probably one of the worst things that happened to the web and Internet. It used to be mostly P2P until VCs and other companies started hijacking previously decentralized services and putting them on big, inefficient, hard-to-maintain, vulnerable central servers.
P2P represents a return to the roots of the web and Internet. If you want to chat with someone or exchange information with other people, you put it on a machine you control. Hopefully, ISPs and web hosting servicese will improve the quality of their product in response to increased demand. Improved services means both better outgoing bandwidth, better usage metering, and better naming services (so that people can find you).
Oh, in case you still don't get it, the people who make money with P2P is the ISPs, software, and hardware makers.
Re:Where'd Everybuddy Go? (Score:1, Interesting)
Gee whiz.... big news...
It's no different than making any other new protocol... the hard part is getting everyone to use it. And even though this article is titled "industrial strength", it doesn't elaborate on what makes this new protocol so "industrially strong". Does it use encryption? Respect copyrighted material? In bed with the RIAA? Who knows.... because this author certainly doesn't.
Yeah... sure
Read this in print (Score:1)
After people have enough judges messing in the sphere, the user base decides to just go it alone with P2P open source systems that have no centralized server - mostly as they don't like having the plug pulled on them.
-
Better Info Source... (Score:3, Informative)
They provide considerably more details, to wit:
The Project JXTA platform initially defines the following protocols:
This kind of corresponds to some of the traditional Unix services like Bind, and such, or with CORBA services like Naming, Trading, and such, albeit with the explicit intent that the respective "registries" of hosts and host information be Rather Dynamic.
This seems a lot more likely to "go somewhere" than Jini, seeing as how it's a lot more "platform-independent." See the Protocol Specs [jxta.org]
industrial this , industrial that. (Score:3, Interesting)
2c
Does the Future Really Need Jxta? (Score:2, Insightful)
What is it, specifically, besides (insert file-sharing utility here) with enhanced security?
I recall the Wired article [wired.com] about Jini, but a 'Doze beater it was not. Should we expect anything different from this equally-cooled-named product?
Notwithstanding trading MP3 files and gaming, is anyone using peer-to-peer applications?
Re:Does the Future Really Need Jxta? (Score:2)
Bill Joy, 1998: "It's better to be Yahoo than Netscape."
Now, who said this man wasn't a visionary?
The future... (Score:1)
What is it, specifically, besides (insert file-sharing utility here) with enhanced security?
That's a very poor way of characterizing it. What JXTA is (or attempts to be) is a platform upon which you can easily develop and deploy a p2p app-- without all that messy reinventing the wheel that would otherwise be required. File sharing apps are certainly one application you could develop, but you can also build distributed computing/streaming/chat utilities. And anything else you can imagine.
So the concept is great. Unfortunately, JXTA doesn't seem to be quite there yet. JXTA currently only provides a working implementation of the lower-level components required to put together a p2p app. Peer discovery isn't very sophisticated at this point, though the basic tools with which you might build a more sophisticated system are there. And performance isn't great.
This is only my opinion, but the problem I see is that JXTA seems to be more of a research project than an attempt to build a practical p2p platform. Maybe in time JXTA will be refined into a more practical tool, but I wouldn't be surprised if it was displaced by a better performing, less flexible platform (based off of Kazaa/Morpheus, maybe.)
Re:The future... (Score:1)
Point taken. Summing any major piece of software in a single sentence is unlikely to be fair.
The underlying question I have remains: given the smorgasboard of existing protocols, how does this new effort simplify effort, or add capability? Or is it just counter-battery fire in response to C#?
Re:The future... (Score:1)
I think C# is the wrong comparison. The equivalent of JXTA is something like the gIFT/OpenFT. Both of these are libraries (written in C, incidentally) that help you write p2p apps by implementing a lot of the features an average p2p app needs.
If you were trying to write a p2p app, would you really want to go to all of the trouble of defining a communication protocol for inter-node messages, building a system that can route messages between nodes, etc. when all of this has already been done by other p2p applications? Or wouldn't it be easier just to start with a library containing an implementation of a communication protocol and a whole bunch of useful routines for peer discovery and communication? That's what JXTA and gIFT/OpenFT try to be. Neither is quite there yet, and I don't think there are any other Open Source projects that are further along (there are a handful of Open Source p2p apps out there.)
With one of these libraries, building a p2p app could be as easy as a) call some library routines to discover other peers on the network, b) start an engine thread that handles incoming messages and updates the list of nodes we're connected to, in case some drop out, c) upon receiving a request message, call a routine to send a reply message, or open a "pipe" to that node so we can send data. With a library that took care of all the tricky p2p stuff, you could write a variety of complex p2p apps very easily.
JXTA is trying to do a neat thing. Essentially, it helps abstract away all of the complicated stuff. Every node on your p2p network gets a unique ID number. If you want to communicate with that node, you can create a "pipe" class to that ID number. The library will then figure out the details of how to actually get your data to the node in question (it may involve routing through other p2p nodes, or transparently encrypting the data). If you know the IP address of one other node on the network, the JXTA library contains routines that help you find others. Your application can sit "above" the JXTA library and not trouble itself dealing with the complexities involved in a p2p network. Now, none of this seems to be implemented enough to be practical. But the concept is a great one.
Futhermore, I would submit that for p2p application development, protocol compatibility isn't a very big deal (at this juncture, at least.) If I want to write a p2p app for sharing files, and another app for chat, it's perfectly ok if they use different protocols, and build separate networks. I could use OpenFT/gIFT for my chat app, and JXTA for my file-sharing app. Unless I wanted the two applications to be compatible, there'd be no reason to settle on pick one just to use a standard. Maybe at some point in the near future, it'll be useful for all p2p apps to speak a standardized protocol so that clients with different needs can all combine their resources, but not now.
Re:The future... (Score:1)
The rest of your reply answers the question, though: Sun is not just producing a product as a direct attempt to blunt the market impact of C#/.Net.
Though who's to say what the long-term strategic thinking in the mind of McNealy might be?
The gist of '...abstract[ing] away all of the complicated stuff...' seems that it's a cleaner design/implementation. Other p2p protocols might be wrapped in classes for JXTA. The value added would then be some Grand Unified P2P Theory Application (GUPTA)!?!
Re:The future... (Score:1)
I imagine this'll be the way of things some day. Generally, you wouldn't write your own GUI library to draw windows and menu bars nowadays, so probably in a few years the same'll be true of p2p applications.
Though I doubt it'll be JXTA. Too kludgy, and written in Java. My guess is that the first library to garner popular use and support will be the one to take off, even if it's not as flexible as JXTA. And that'll probably be a more practically-oriented C/C++ implementation. JXTA reeks of "research project".
Groove Networks' comment.. (Score:2, Informative)
Re:Groove != pals with Micro$oft (Score:1)
Ray Ozzie, the inventor of Lotus Notes [notes.net] is the head of the Groove P2P product mentioned in the article. And it's a very interesting product at that (try it! [groove.net]).
I seriously doubt that this is anything more than a very casual marketing thing... Please don't use Ray Ozzie's creations in the same context as the Evil Empire, it pains me physically !!!
Thanks.
Legit uses of P2P (Score:1, Interesting)
THere are so many things that P2P seems like it would work great for so many things other then file exchange.
what uses does any one see for future use of P2P.
One use that I though of that could be cool it paying people to be part of a large scale cache of the net.. Well used web sites could make dynamicly mirror them selves very similar to the way Kazza and MORPHEUS Network share files.
What other uses do people see for P2P in the future?
Lets have fun!!
Whither SOAP? (Score:3, Insightful)
SOAP/UDDI - means of identifying and communicating with objects. Uses HTTP and XML. Widely deployed standard. Use for anything you'd like.
OT: Moderation (Score:1)
But I'd like to know if the moderator has some sort of insight here.
And yes, I can stand to lose some Karma...
In the end: tts an R&D Project Only! (Score:5, Interesting)
1. JXTA was written by a bunch of inexperienced Java developers. They broke all the rules of Java programming and wrote spagetti code. I think they discovered Design Patterns in the middle of their project and overused and abused them, yielding worse code.
2. They wrote demonstrations that used the pipe and filter architecture pattern to construct a unix shell essentially. One could list the peers on the network, pipe it through more, and wow your boss. But wait, it doesn't stop there - they created a chat program -- oooh.. IRC, IM anyone? When the time came to implement a real application, it was near impossible
3. The firewall/double firewall tunneling didn't work, so LAN deployment only folks!
4. The RVs, where peers gather and discover one another, were designed to only handle 10 socket connections, 4 of which were persistent. Nice and scalable! No failover support for the 1st release, BTW :)
5. There were a lot of holes in the specification and thus ports to other languages will yield them potentially incompatible above the basic network protocol(which is XML, BTW, and thus slow as binary exchange of files need to be BASE64 encoded)
6. The entire JXTA project is tagged as a research and development project only. This means that unlike Jini, which obtained a large marketing and development budget, Sun is throwing a lot of cheap developers and little marketing to this project.
In the end, it didn't deliver what it promised, it wasn't built for production use (Jini at least was, to some degree thank you Mr. Joy), and missed a lot of concepts necessary for effective peer networking.
Where are they now? Not sure.. We quit looking at their code around July and concentrated on other network alternatives - settling on Jabber.
What a disappointment!
Re:In the end: tts an R&D Project Only! (Score:1)
1. JXTA was written by a bunch of inexperienced Java developers. They broke all the rules of Java programming and wrote spagetti code. I think they discovered Design Patterns in the middle of their project and overused and abused them, yielding worse code.
You seem to miss the essence of what JXTA is. From the outset JXTA has been a project to develop a set of protocols for managing P2P interaction. To confuse JXTA with its implementation is both inaccurate and unfair. If you were expecting a turn key solution for the initial release I think you need to stop and really think about how you set expectations. P2P was and still is a moving target and the initial release of JXTA blatantly shows this. Trying to be all things to all people is not easy as linux has proven. I am quite confident when I say, had JXTA's only purpose been to create a cool file sharing app, thats what would have been delivered. Instead JXTA aimed to create a frame work for P2P protocols, this goes beyond just sending a copy of some song (that should be downloadable from the publisher for a reasonable price).
That said the initial release of the Java implementation of the JXTA protocols was pretty ugly. I can't say I can think of another open source project who's code didn't need a lot of rewriting after the first release. The source code has been cleaned up considerably and the great part about the Java implementation being open source is that you could have helped clean it up.
2. They wrote demonstrations that used the pipe and filter architecture pattern to construct a unix shell essentially. One could list the peers on the network, pipe it through more, and wow your boss. But wait, it doesn't stop there - they created a chat program -- oooh.. IRC, IM anyone? When the time came to implement a real application, it was near impossible
Yes JXTA was/is a R&D project, and yes the first application was a shell utility targeted at developers to get them accustomed to the concepts behind the protocols.
As far as implementation of new applications, you're very right. Early on the Java implementation API was cryptic and unfriendly. One of the most frustrating limitations of the Java implementation was the requirement on the part of the application to poll for events. While it is still not perfect this has been addressed in newer versions along with many other API problems. API naming changes and the addition of listener interfaces for events are just a couple of the changes.
3. The firewall/double firewall tunneling didn't work, so LAN deployment only folks!
Now your showing how early you gave up on the project. The limitations on connection were much improved rather early and today work quite well.
4. The RVs, where peers gather and discover one another, were designed to only handle 10 socket connections, 4 of which were persistent. Nice and scalable! No failover support for the 1st release, BTW
Where in P2P land does it say that all connections must be connected all the time? Having the 4 most used connections remain open with a pool of 6 connections available for transient communication seems like a reasonable starting point and IIRC thats why the 10 sockets were split as 4 and 6. I am honestly not sure how the connection pooling is implemented today but this sounds better than Gnutella where you have a fixed number of connections to a fixed number of peers regardless of how active they are.
5. There were a lot of holes in the specification and thus ports to other languages will yield them potentially incompatible above the basic network protocol(which is XML, BTW, and thus slow as binary exchange of files need to be BASE64 encoded)
Wow, a early release of an ambitious project with holes in the specification. Its a collection of protocols, and last I checked newer protocols contain versioning information because nobody expects them to be 100% out of the gate. Maybe if you stuck around long enough to offer some input (it is an opensource project after all) the protocols would be more to your liking and a little more cohesive.
6. The entire JXTA project is tagged as a research and development project only. This means that unlike Jini, which obtained a large marketing and development budget, Sun is throwing a lot of cheap developers and little marketing to this project.
It is a R&D project because the target is not fully defined. There are many uses for P2P type interaction beyond mp3 file sharing, some of which have yet to become apparent. If all the potential uses for P2P style interaction were known, JXTA or something else would already own the scene. Instead you criticize a project that is open not only in source but open in definition.
In the end, it didn't deliver what it promised, it wasn't built for production use (Jini at least was, to some degree thank you Mr. Joy), and missed a lot of concepts necessary for effective peer networking.
Jini also had a longer development period for a fixed set of goals before it was released. Had Sun waited till JXTA was more robust and better defined before opening the protocols and the java implementation source code to the public, you'd probably be here bitching that XYZ feature was unsupported. Instead the project was opened rather early so that it could evolve as the developers using it needed it.
Where are they now? Not sure.. We quit looking at their code around July and concentrated on other network alternatives - settling on Jabber.
Last I checked they were still trying to build the holy grail of P2P interaction. don't want to call you a liar, but after responding to your 3rd point I can say that you stopped looking before July.
What a disappointment!
I agree 100%, posting today using arguments based on facts from months ago is kind of dissapointing. By your logic linux sucks since it doesn't support XYZ video card. Next time maybe you could supply accurate time frames so people can judge for themselves, then again I guess thats asking a bit much from an Anonymous Coward.
I have been off and on with JXTA for quite some time now and not all your points have been totally off base. But JXTA tries to be many things and has come a long way in a rather short time. The great part about Open Source is that contributing talks and bullshit walks.
Don't expect to find anything useful soon.. (Score:2, Interesting)
Ever heard of samba? Windows file/print sharing?
Yep it's P2P
Yep it's useful
Thank you, and good night.
Simple Analogies.... (Score:2)
Napster = cool
Napster = sued
Napster = shut down
Gnutella = True P2P
Gnutella = slow
Gnutella = bandwidth-hogging
Gnutella = unsure future
JXTA = P2P Protocols
JXTA = has some developers
JXTA = coming from a company with a shaky past in "revolutionary new technologies"
JXTA = something that not many people understand
JXTA = not being marketed heavily by Sun.
The general public and some geeks equate "P2P" with "illegal music sharing". To make matters worse, Bill Joy has failed to put this invention into terms that non-computer-literates can understand.
I'm keeping an ear to the ground for cool new projects involving JXTA. However, I fear that like JINI before it, it will be relegated to obscurity because of a failure of marketing and a lack on understanding of how it will benefit consumers.
The #1 sales trick is "Explain benefits, not features." Consumers don't care if it provides "ground rules for P2P applications." They want to know what benefits it provides to them. So far, I've seen much discussion on JXTA's technical merits, but absolute zero discussion on what kind of cool applications are going to use it. Where is the "JXTA-enabled" widget that will "change your life"?
Industrial-strength (Score:1, Informative)
One of the things it's got going for it are the basics, if you read the material [jxta.org] on it, you will see it has taken the spirit of UNIX pipes and shells and extended it to P2P. This is a very powerfull Philosophy being applied to a modern concept, and I think it hols a little water. Having spent a lot of time disseminating various P2P technologies, I think this and jabber [jabber.org] have a good basic ideas, a fusion of both would be even better
A wierd idea I had (Score:2)
Basically, a mainframe/thin client implemented virtually on a peer network. The advantages as I see them would be keeping the centralized aspect of a mainframe (at least as far as software goes) and easy scalability of a peer network (just add workstations for more storage and processors).
I'm not sure that the advantages would outweigh the costs in terms of physical network requirements, or even if the advantages are real or just imagined, but I thought it was an interesting idea I could maybe throw out there for someone who actually knows enough to maybe pull it off.
The trouble with JXTA (Score:3, Insightful)
Essentially the problem with Jxta is that it is built on the assumption that P2P needs a communication standard above the TCP/IP level, and I am unconvinced that it does. The range of applications that call themselves P2P are sufficiently diverse that they each have different (and often mutually-exclusive) requirements of the communication layer that sits above TCP/IP, yet this is exactly the layer that JXTA tries to mandate.
As an example, Freenet has very strict requirements about how encryption is implemented at a low level, most other P2P architectures have no such requirement (and, in fact, would fail if such a requirement was forced upon them). Freenet, Fastrack, Mojo Nation and other systems also have very different ideas about how peer discovery is achieved, yet again, JXTA tries to mandate this too (adopting a Gnutella-inspired approach).
Standards are useful in some circumstances, but for P2P, TCP/IP is probably the highest-level standard we need.
Re:The trouble with JXTA (Score:2)
And in some cases, even TCP is too high level. One of the significant problems with peer networks is handling NAT's and using bandwidth efficiently.
A project I am working on requires a lot of very small messaging data be sent to a lot of peers directly. For this situation, UDP/IP is the best choice.
Not only does this UDP based protocol cross dual NAT chasms that TCP cant touch, but it is also very low overhead for simple messaging in terms of bandwidth and kernel.
But your basic premise still stands. JXTA will probably be usefull for many things, but it no way will it be usefull for _ALL_ things peer oriented. There is just too much diversity in requirements and functionality for JXTA to hope to support.
I agree (Score:2)
Many uses for P2P (Score:3, Informative)
1. The WWW itself is purely P2P. links form the backbone of the P2P network. Search engines make the spidering more efficient, but they are really just cached spidering. At the base level, to get around, you spider just as in Gnutella.
2. Samba is P2P.
3. CUPS is P2P, letting you share your printers.
4. NFS is P2P when you connect to and start using enough servers (although when you do this, let the hacking begin...)
Here is what *could* be done with it:
1. I'm currently heading a project to share genealogical information. Post your GEDCOM to your computer's P2P app, and it is automatically spiderable on the network. For those interested, its still at alpha/beta stage and at gntp.sourceforge.net.
2. Wouldn't a world wide library application be wonderful? Input your book or article, and all of the libraries worlwide that have your book show up. No, I'm not talking about the textual WWW. I'm talking about a strongly-data-typed library network.
3. What about a P2P e-business network. Again, it could be strongly-typed and object oriented. Much more powerful than WWW. I developed one of these and I'm publishing a paper on it right now. It would make today's registries and marketplaces useless. Allow anyone on, user-customizable categorization scheme, etc. This one would take a big player like MS or IBM to really implement, though, because you need lots of people on it all at once to make it useful.
My point is that there are many, many uses for P2P. People just need to open their minds to what has already been done and what could be done. File sharing is great, but it is only the beginning of the types of networks we could build.
Shoe event horizon (Score:1)
Useful P2P Is Here. Try Red Swoosh. (Score:2)
Think Akamai with peered nodes and intelligent network mapping.
Juck-sta? (Score:1)
It's a bad sign when you have to tell people how to pronounce the cutesy name of your technology. I look at Jxta and hear "Jicksta", or maybe "Jecksta".
No, it's Jackster! (Score:2)
It's all coming true!!! Is Bill Joy Sir-Paid-A-Lot's secret identity or something?
Is intermittent P2P useful? (Score:1)
Millions of people may have used Napster, but what percentage of them were solely consumers of other people's files? How many gave as many uploads as they took downloads?
Can you be a first class P2P participant if:
My serious problem with JXTA is that all four of those problems apply to me, and I do not see why I should put any intellectual effort into software that I cannot use. And I think that there are a lot of people like me out there.
---
Watch Red Dwarf? (Score:1)