Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
The Internet

Industrial-Strength P2P 104

Posted by CmdrTaco from the something-to-think-about dept.
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.
This discussion has been archived. No new comments can be posted.

Industrial-Strength P2P More

Industrial-Strength P2P

Comments Filter:

  • I hope it changes my life as much as Jini did! (Score:3, Insightful)

    by JMZero ( 449047 ) on Monday December 10, 2001 @03:59PM (#2683545) Homepage
    Unless a new technology:

    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.
    • ... killer ...

      In both senses of the word.
    • Next up, Sun launches new ad campaign, "The Network is the Network" complete with diagrams of computer terminals and arrows and happy faces. Under their definition of "peer" which could mean anything from running shoes to supercomputers (this is from the article, people) their radical new plan connects those computers together in a mostly decentralized way to share information. This changes everything!
    • I think sharing illegal files was the killer app of P2P.

      Was?

      • You're right, file sharing is still a killer app. But it's no longer one that Sun can exploit to sell Jxta.

        Though I'm sure the RIAA would love to see it try.

    • 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.
      • I think that Jini was fine. As is Jxta, I'm sure (though I've only briefly looked at the thing). The problem is Sun.

        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.
    • Jini lacked a killer application. P2p already has one (mp3 sharing, instant messaging) so JXTA needs another one to prove it is worth bothering with. Unless it is found it will die slowly and will eventually disappear.

      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.

  • Who pays for P2P? (Score:4, Insightful)

    by Artifice_Eternity ( 306661 ) on Monday December 10, 2001 @04:01PM (#2683559) Homepage
    This is what I don't understand. Unless it's either a paid-subscription model (pay to join) or a truly, totally distributed and open-source system (there are NO central servers of any kind), I'm not sure how P2P can make money.

    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)

      by bourne ( 539955 ) on Monday December 10, 2001 @04:10PM (#2683626)

      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!)

    • The typical reason for "open source" software projects to be viable is not that the people involved expect to see lots of licensing and royalty fees to roll in, but rather that they expect the results to be useful.

      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.

      • 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.

        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?

    • It depends on the application. P2P systems need not be on the open web, or open to all comers: Jxta is very nice for developing P2P systems that work within corporate intranets, for example.

      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.
    • The web makes no money. Some companies/people use the internet standards to make money, but the "web" itself does not. (For example, www.slashdot.com makes some money on the web through advertising.)

      How will p2p make money? It will not. Some companies/people might figure out a way to leverage it though.
    • That's a way of thinking that's really about filesharing applications, which were just the launching point for P2P. In the long run P2P is a bag of techniques (like location independent naming) that are being absorbed into the web. Asking who pays for those techniques is like asking who pays for tuplespaces -- the people that pay for P2P are the employers of the programmers who use P2P techniques to solve business problems.
    • I'm not sure how P2P can make money.

      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.
    • Having P2P features could make a commercial product more successful. You're not going to make any money being a bottleneck in a P2P system, but providing a good front end for a particular use of a P2P system is a reasonable business model for selling software, and adding such features to a product adds value. In order to be able to sell such programs, you need there to be a network of worthwhile content for it to access, which means encouraging the enthusiasts to use a common format that you can tap into.

      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.
    • True, it wasn't always reliable but by and large it worked, it was free, and it was largely unencumbered by the great unwashed masses that polute the internet these days...
    • People seem to be confused in to thinking that P2P is just file sharing, P2P includes: Instant Messaging, Networked Devices(such as bluetooth), web services and even a lot of old school stuff such as Usenet fits under the P2P definition. What is the definition of P2P some may ask? Well, according to the Oreilly P2P book in a chapter written by Clay Shirkey the P2P Litmus test is:
      • Does it allow for variable connectivity and temporary network addresses?
      • Does it give nodes at the edges of the network significant autonomy?
      I don't think Sun is funding this on the idea that there will be instant monetary benefits from Jxta, but I do think Sun is looking to implement features of P2P in to their own product line sometime in the future. Even if they don't incorporate any P2P features in future projects, what they are trying to do is get a head start over Microsoft for the "Next Big Thing." Is P2P going to be the "Next Big Thing?" Well, that is obviously debatable but one only needs to look at the top ten applications on Download.com to see that at least the file sharing and IM P2P applications are incredibly popular. [download.com]
    • Gosh, all these people talking to each other, and no central servers of any kind (except for a few 900 numbers). How does anybody make money?

      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.

  • While I thought it was a good article - and I can't tell you how much I like the thin format they have now - remember lugging those 2 inch thick ones back in the .com heydays - one must ask oneself how viable any private non-Open Source P2P system will be.

    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)

    by Christopher B. Brown ( 1267 ) <cbbrowne@gmail.com> on Monday December 10, 2001 @04:06PM (#2683600) Homepage
    There's actually a set of downloads of code available at www.Jxta.org. [jxta.org]

    They provide considerably more details, to wit:

    The Project JXTA platform initially defines the following protocols:

    • NetPeerGroup Protocol
    • Peer Discovery Protocol
    • PeerGroup Discovery Protocol
    • Peer Information and Management Protocol
    • PeerGroup Membership Protocol
    • PeerGroup Resolver Protocol
    • PeerGroup Sharing Protocol

    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)

    by zoftie ( 195518 ) on Monday December 10, 2001 @04:09PM (#2683617) Homepage
    Sun has definately is omnious in its presence on unix market, but their contributions to unix communities, while cool for programmers - were not for sysadmin. RPC, NFS and NIS(+) were some the most exploted system blocks, running right behind bind and sendmail. Going to next point, does industrial strength means free gateways for hackers scanning cable and xDSL address ranges?
    2c
  • I have a lot of respect for Joy's technical acumen. Perhaps someone else can do something deeper than this press release.
    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?
    • My favorite quote from the Wired article you mentioned:

      Bill Joy, 1998: "It's better to be Yahoo than Netscape."

      Now, who said this man wasn't a visionary? ;)
    • The future needs something like JXTA, although having messed with the code, I get the feeling that JXTA isn't quite it. Yet.

      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.)

      • That's a very poor way of characterizing it.

        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#?
        • 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#?

          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.

          • I was too colloquial: '...counter-battery fire in response...' != 'comparison'.
            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)!?!
            • Other p2p protocols might be wrapped in classes for JXTA. The value added would then be some Grand Unified P2P Theory Application (GUPTA)!?

              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 was quoted in the article. They gave jxta a luke-warm reception. I wonder if the following article has anything to do with their response?

    Microsoft and Groove Networks Announce Strategic Relationship [microsoft.com]

    Microsoft Invests $51 Million as Groove Networks Closes Financing Round; Companies to Pursue Shared Vision for Web and Peer Services


    • 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.
  • I am glad to hear some thing new out of the P2P industry even if it is so light on details.

    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)

    by JMZero ( 449047 ) on Monday December 10, 2001 @04:43PM (#2683786) Homepage
    JXTA - means of identifying and communicating with objects. Uses HTTP and XML. Brought to you by Sun. P2P! P2P!

    SOAP/UDDI - means of identifying and communicating with objects. Uses HTTP and XML. Widely deployed standard. Use for anything you'd like.
    • I wish that moderators would also leave replies to comments. I don't particularly disagree with the idea that my post here is a Troll (as I'm an idiot and prone to say stupid things).

      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)

    by Anonymous Coward on Monday December 10, 2001 @04:51PM (#2683817)
    I was involved in the use of JXTA immediately after its launch in April of 2001. I led a team of experienced Java developers who used JXTA to produce a Groove-like product that ran on Linux, Windows, and Sun. Here were our findings:

    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!

    • I was involved in the use of JXTA immediately after its launch in April of 2001. I led a team of experienced Java developers who used JXTA to produce a Groove-like product that ran on Linux, Windows, and Sun. Here were our findings:

      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.
  • Ahh..

    Ever heard of samba? Windows file/print sharing?
    Yep it's P2P
    Yep it's useful

    Thank you, and good night.

  • Napster = P2P
    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)

    by Anonymous Coward
    Wrong title, but good technology
    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 distributed mainframe.

    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)

    by Sanity ( 1431 ) on Monday December 10, 2001 @05:12PM (#2683922) Homepage Journal
    Adam Langley, a Freenet [freenetproject.org] developer, wrote an interesting article for OpenP2P.com on Jxta a few months back which, from reading the article, still seems to hold true today - read it here [openp2p.com].

    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.

    • ... but for P2P, TCP/IP is probably the highest-level standard we need.

      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 did consider saying IP rather than TCP/IP since I do think that UDP/IP is likely to become more popular with P2P apps, but since today most P2P apps use TCP I stuck with that. As you say, this is orthogonal to my main point.

  • Many uses for P2P (Score:3, Informative)

    by conan_albrecht ( 446296 ) on Monday December 10, 2001 @05:37PM (#2684068)
    I can't believe P2P gets such a rap from this crowd. There are *lots* of things you can do with it besides file sharing or MP3 thieving. First, let's take a look at what has already been done with it (although it wasn't called P2P at the time):

    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.
  • Hmm. I can see some big shoe manufacturers buying into this. Your shoes gathering data like how much you wear them, how many G's they take while you walk, how the tread pattern is holding up. At night when you're sleeping, the shoes jack in and Big Shoe Company trolls the P2P network looking for data. Pretty soon, every shoe company is putting larger and larger chips into their shoes, sending up more and more data. Incredible bandwidth is sucked up by shoe data, and advertisers join in on the game. All too soon, it is unprofitable to do anything but shoe related networking. The process reaches the "Shoe Event Horizon", after which civilization collapses, and those with the right genetic makeup mutate into large vulture like birds... (my apologies to Mr. Adams).
  • Useful (and potentially profitable) P2P is here. Check out Red Swoosh [redswoosh.com], done by the same fine folks as brought you Scour.net. They're already serving up pages for Deviant Art [deviantart.com], where you can get art and skins for things like Trillian [trillian.cc] (which I'm very happy with), and are closing other deals with certain varied media empires.


    Think Akamai with peered nodes and intelligent network mapping.

  • Joy's new pet project is called Jxta (pronounced "Jucksta," and short for "juxtapose"), [...]

    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".

  • I'll admit to being one of those with a P2P-is-useless bias. I can imagine a lot of uses for P2P. However, the P stands for peer, and the internet is not made up of peers.

    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:

    • You dial in to the internet for one or two hours a day (that is less than 10% of the time).
    • And/or your maximum available bandwidth is 28.8K or less
    • And/or you do not have a fixed internet address.
    • And/or your service provider does not allow you to be the server side of an IP connection.

    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.

    ---

  • According to RD, Jxta is the noise a cat makes when it catches it's spuds in a door....

Slashdot Top Deals

This restaurant was advertising breakfast any time. So I ordered french toast in the renaissance. - Steven Wright, comedian

Close