Now blogging at diego's weblog. See you over there!

the last of futurama

Just saw the last episode of Futurama. I had read recently that Fox had disbanded the team that was working on it, and that they had one full season in the can, but I wasn't sure whether I was actually watching those episodes or not. It seems I was. I wonder if another show will ever follow in their "footsteps". The writing was as good (better, at times) than The Simpsons. And the characters... the ideas... oh, man....


Futurama is no more. Long live Futurama.

Posted by diego on August 17, 2003 at 7:36 PM

chaos, complexity and power cuts

Last Thursday, as I heard about the power cuts in the Eastern US, it got me thinking about Complexity and Chaos. Not that I think it was original, of course, but I was still a bit surprised to find an article written along those lines, published the very next day. Cool.

Categories: science
Posted by diego on August 17, 2003 at 10:36 AM

the one-minute-guide to JXTA

After my IEEE article on P2P network topologies I got some comments (including one in the entry) about JXTA. Recently I was looking in more detail at the JXTA site and I realized that there's a lot of documentation, but a lot (and I mean a lot) of it is in PDF form, and so not "browser ready". Heretics that suggest that opening a PDF inside a browser is still web browsing--so comparing HTML with what is essentially a Postscript derivative and the experience and simplicity of dealing with one as with the other--should continue along their path and don't bother trying to convince me that PDF is like the web but better, or something like that. It's a nice format for eBooks and documents meant to be printed or archived at high resolution, or where formatting is key. Period.

But I digress. Lack of HTML documentation in the JXTA site (at least docs that are easily accessible for intro material, the "tutorials page" is quite useful as a hands-on programming guide however) seems to be a problem to those looking for a short introduction. So here goes a one-minute introductory guide of JXTA concepts (ie., sans programming examples). For more detail check out this longer article from a couple of years ago at O'Reilly's website. Also useful.


JXTA is a generic, protocol-independent P2P system. JXTA is not based, or dependent on, Java. JXTA depends on XML as a message passing format, and nothing else. Although the first implementation of JXTA was written in Java, there are JXTA implementations under way in other languages, such as C, Perl, Python and Ruby.

JXTA is open source, and its code is licensed with the Apache Software license. There always seems to be a fair amount of activity in the projects section (including the core), quite a number of projects going on, even if some of them are not evolving too fast.

abstractions and protocols

JXTA is a set of specifications to handle the core functions of P2P communication. Through these protocols and abstractions, JXTA establishes a P2P network on top of the Internet and non-IP networks, allowing peers to directly interact and organize independently of their network location. All nodes connected using the JXTA system form the JXTA network. JXTA employs five abstractions to abstract existing computing networks:

  • Addressing. A uniform peer addressing scheme that spans the entire JXTA network. Every node is uniquely identified by a Peer ID, connected to a peer endpoint. Peer endpoints encapsulate all the network interfaces available to a node.
  • Peergroups. Nodes can organize autonomously into protected domains called peergroups. A node can belong to as many peergroups as it wishes. Users, service providers, and network administrators can create peergroups to control peer interactions.
  • Advertisements. Advertisements are XML documents that allow a node to to publish and discover network resources through a uniform interface.
  • Binding. JXTA defines a universal binding mechanism, called the resolver, to perform all resolution operations required (for example, resolving a name to an IP address, binding an IP socket to a port, or locating a service).
  • Pipes. Pipes are dynamically defined communication channels that enable services and applications to advertise communication access points through advertisements. Pipes allow nodes to dynamically connect to each other. Pipes can be of multiple types: point-to-point, point-to-multipoint, encrypted, and others.

These abstractions are handled through a set of protocols (although the mapping between abstractions and protocols is not
one-to-one), as follows:

  • Peer Discovery Protocol. Enables nodes to discover services on the network.
  • Peer Resolver Protocol. Allows nodes to send and process generic requests. This search/retrieval mechanism is what enables nodes to locate each other, to find peergroups, find services, and retrieve content, also performing authentication and verification of credentials.
  • Rendezvous Protocol. Defines the details of message-propagation between nodes.
  • Peer Information Protocol. Allows nodes to obtain information about other nodes in the network.
  • Pipe Binding Protocol. Provides a mechanism to bind a virtual communication channel to a peer endpoint.
  • Endpoint Routing Protocol. Provides a set of messages used to enable message routing from a source peer to a destination peer.

Each JXTA protocol defines a set of XML messages to coordinate one of the aspects of JXTA interactions. In JXTA, all resolution operations are unified under the simple discovery of one or more advertisements. All binding operations are implemented as the discovery or search of one or more XML documents. However, JXTA does not specify how the search of advertisements is
. Each peergroup can tailor its resolver implementation to use a decentralized, centralized, or hybrid search approach to match the peergroup's requirements.

back to the real world

JXTA has made a lot of progress recently, but using it can still be difficult at first, particularly if you'd like to tinker with the source (check out the instructions in the core build download page and see for yourself), and in some cases its performance is terrible. However, it's very useful as a base to whip up a quick P2P prototype (quick in terms of development times, not in performance :-)).

Hm. If I keep typing, this is going to take longer than one minute to read. Okay, I'll stop. Done.

Posted by diego on August 17, 2003 at 10:28 AM

Copyright © Diego Doval 2002-2011.