What do I know[!?]

JXTA NetMap is a project helps to visualize JXTA network, we actually use this project to run the public rendezvous. Those public RDVs and relays assemble the JXTA public network serve as a playground/testbed so that people can test their JXTA applications without deploying a infrastructure. However, you should never use it for production, since those node can be down at any time without notice. Even for testing purpose, you are advised to use the public network to bootstrap your own peergroup.

The project has been packaged as a self-contained jar, which you can download and start it by 'java -jar jarfile', but the jar had not been updated for a while, meaning JXTA platform embedded is not up to date.

Seeing the cool "Next-Generation Java Plug-In" feature in Java 6 Update 10, I think it would be cool to make it an applet so that user can experience it and deploy it easily. Before I get to that point, I spent some time to JNLPlize it and make the project part of JXTA nightly build.

You can launch the applicaiton, seeing live is better than a screenshot IMHO. :-)

JXTA-C implementation used to use a lot of threads, that really bothers me. I am not against writing multi-thread applications or saying threads are bad, but thread is for doing things in parallel, not to create bureaucracy. Also thread is a system resource that I don't like to waste.

By bureaucracy I mean a common pattern I observed: Having objects create threads for processing requests. A task can then be handed over from a thread to another because of those object boundaries. This is an easy way to do things asynchronously, it also gives an illusion that the code is now a multi-threaded and the performance would be better. Unfortunately, this is usually not a good way to partition a task.

A pattern in JXTA-C was

• Each connection creates a thread to read in messages.
• The thread hands the message to a listener registered for that message based on the destination address of that message. It is not unusual a message can be enveloped to a different destination, so this can be a multiple hand over between listeners.

For those who are not familiar with JXTA, a listener is basically a queue for invoking a function, which can have one or more threads to handle requests on demand. In most cases, a message only needs a very short attention to process. But it has to go through threads waiting for its turn.

Situation has being improved in JXTA-C, callbacks has being replacing listeners. Thread pool is used when asynchronous or parallelism is really needed. And with the upcoming release, non-blocking I/O is used for TCP transport implementation.

With that, the model now becomes:

• One thread is monitoring a set of connections, reading all data from the wire.
• An idle thread(or a new thread could be created) from the thread pool will pick up the connection, deal with the data from parsing until finish its processing.
  

Immediate benefits are of course,

• The number of threads is now limited and manageable.
• Hand over between threads due to protocol stack is eliminated.
  

and we will see how that works. :-)

In an effort to reduce number of threads used in JXTA-C, we wanted to use a thread pool that can have a hard limit. With that and consolidating threads created to process different task queues into a single queue resides in thread pool, it is more efficient. Same amount of tasks can be served with less threads.

As JXTA-C use Apache Portable Runtime for portable layer, it is natural fit to contribute the work back to the project. After lengthy wait, due to the legal issue as well as waiting APR developers have cycle to help commit it, finally the initial commit was made. I have to thank wrowe for helping the process all the way.

Current implementation is very simple and straight-forward, and you can even use the thread pool as a timer or scheduler whatever you like to call it. You can review the API. Basically each task is given a priority or a wait period, and the low priority ones can be starving, nevertheless it is useful enough for general cases. Hopefully it can get evolved to support different queue process policies. For now, a small bug fix and improvement can be found at bug #41359.
 

There has been an email thread on JXTA discussion mailing list about the status of JXTA and questioning how much Sun is committed to the technology.

Here is what I think about the topic. As a community member, I understand there is a lot to be improved, and I wish there are more developers dedicate their time to the reference implementation projects, but let us be more realistic. After all, you have to set your expectation right when it comes to an open source project.

JXTA is a set of protocols that enables many possible applications by allowing a peer on the network to self-organized together and serve each other. You can imagine different projects demanding different features to be built atop JXTA.

JXTA is not a product sold by Sun, therefore expect Sun to have dedicate resources to support the community for free is not realistic nor fair. As a corporate, it is certainly understandable that developers from Sun works on projects align with Sun's objective. However, Sun does employee a team continuously working on the technology, and we do care and support the community with our limited time.

It is grateful that Sun initiated and open-sourced different reference implementations of JXTA: for Java SE, C and Java ME. As each project moving forward, makes sure they are inter-operable even though each has different level support of the protocols as each project moving forward. For example, the JSE supports most complete features available with JXTA today, such as reliable layer, JxtaSocket interface, PSE membership service, etc, while C/C++/.NET binding still working on relay server and TLS transport but support more advanced discovery query and a new peerview protocol is under development with C. With Java ME, a complete edge capability is supported.

However, JXTA is an open source project and you are welcomed to contribute. As a meritocracy, Sun is no different from others as a contributor to the project. Participate in the project, and benefit each other with contributions.

Kudo to Alexander Sack, the Debian developer for Firefox, Thunderbird, etc, JXTA-C now can be build as Debian packages.

One of the thing we want to do, is to provide binary build regularly, JXTA JSE provides nightly builds, I hope JXTA-C can do weekly builds. I happen to have a Ubuntu AMD64 running, so I decided to setup the build environment. Here is the steps on how it was done, and maybe it can help others who are interested in building JXTA-C on Debian or Ubuntu.

While most of JXTA-C depended libraries are available in Ubuntu dapper(I had included universe components), libapr1-dev and libaprutil1-dev are only available from Debian testing. While I am not comfortable to add Debian binary repo into sources.list(not sure how apt will handle duplicate packages available from multiple repos), I can build the deb package easily from the source deb.

So, I need to tell Ubuntu it can get the source deb from Debian testing repo by appending following line to /etc/apt/sources.list

deb-src http://http.us.debian.org/debian testing main contrib non-free

Before you can do apt-get update, you will need to add the Debian repo key to the keyring.

gpg --keyserver pgpkeys.mit.edu --recv-key 2D230C5F
gpg -a --export 2D230C5F | sudo apt-key add -

Next step is to get the source deb for libapr1-dev and libaprutil1-dev, it is as simple as:

apt-get update
apt-get source libapr1-dev
apt-get source libaprutil1-dev

Almost ready to build, just we need to make sure all build dependencies for libapr1 and libaprutil1 are met and build:

apt-get install libexpat1-dev libdb4.4-dev libpcre3-dev dpatch libpq-dev python uuid-dev doxygen libldap2-dev libsqlite3-dev
dpkg-buildpackage -rfakeroot

Now, we want to build the latest jxta-c, so I download the latest jxta-c release and the diff for Debian:

apt-get install libxml2-dev zlib1g-dev
wget http://download.jxta.org/build/release/c/2.5.1/jxta-c-2.5.1.tar.gz
wget http://people.debian.org/~asac/unstable/jxta-c_2.5.0.1-1.diff.gz
mv jxta-c-2.5.1.tar.gz jxta-c_2.5.1.0.orig.tar.gz
gzip -cd jxta-c_2.5.1.0.orig.tar.gz | tar xvf -
cd jxta-c-2.5.1
patch -Np1 < ../jxta-c_2.5.0.1-1.diff.gz

Last step, modify Debian control files, update version in debian/rules, and add information to debian/changelog, we are ready to build:

dpkg-buildpackage -rfakeroot

Now you can install the jxta-c Debian packages. :-)

We are pleased to announce the availability of another JXTA-C release, 2.5.1 "Cairo".

New Features & Significant Changes

• More conversion to use thread pool

  We are working toward to reduce resource consumption in JXTA-C platform. The first target is threads. We are moving all threads to using a common thread pool created in the NetPeerGroup.

  We would like to take away all threads created for periodic tasks. Instead, we will schedule the task in thread pool, which works like a timer.

  The thread pool implementation is being contributed back to APR project. Before the official APR release to include thread pool, we would have it in the JXTA-C code base. Alternatively, you can choose to build a patched version of APR.

• QoS API support

  JXTA-C now provide APIs to enable QoS for JXTA messages. A small set of QoS is now supported by core platform. Those include priority, TTL and lifespan. Learn how QoS API works and how to add more QoS capabilities, take a look at http://wiki.java.net/bin/view/Jxta/JxtaCQoS.

• Performance Improvement in Cache Manager

  Cache Manager now supports multiple SQLite3 databases and use transaction, which improves performance quite a bit.

• Discovery Service not to publish advertisement received

  In the past, discovery service will publish advertisements it received from the wire and cause SRDI be pushed to annouce availability of that advertisement. While this keeps the "Make popular resource information more available" philosphy, publish or not really should be a decision made by the application.

  With this release, discovery service will only publish advertisements it received when there is no particular listener registered for that query. This behavior is for applications send out a query and trying to search for local cache after a certain period of time.

Another release of JXTA-C arrived. You can read the Release Note. Don't be shy to nominate your codename. If you attended Bernard's session at JavaOne, guess what is to be deployed in Boeing FCS?

While we are happy to deliver another release, there are always more works to be done. Actually, we are looking for a contractor to work on JXTA-C. So if you know a potential candidate who is proficient in C, knowlegeable in network(JXTA or P2P woule be a big plus) and is a Citizen or Permenant Resident of United States, drop me a note.

Haven't post anything for quite a while, during this period, I had a great vacation in Taiwan and Thailand, and we did a JXTA-C 2.3 release when I was in Taiwan. :-)

Now, another quarter passed, and as we committed, another release of JXTA-C had arrived(So is JXTA JSE/JME).

Have a look at the release note, noted that we also have a .NET binding contributed by the community.

In an email back to April, Enzo Michelangeli wrote:

I believe that we are finally close to the point where all the bits and
pieces for a secure, multiplatform, decentralized, opensource Internet
phone + text IM are available, and it would only take some coding effort
to put them to work together:

- Codec: Speex (www.speex.org)
- Portable audio interface layer: Portaudio (www.portaudio.com)
- Bulk encryption and authentication: SRTP, now a standard-track protocol
(RFC3711) and with an opensource reference implementation available at
srtp.sourceforge.net .
- Key exchange: authenticated D-H (how to perform the authentication, as I
said, should be discussed: biometric is not viable if only the text chat
feature is used, and multy-party conferencing calls for suitable
extensions to the basic D-H scheme)
- Directory and presence: any good P2P content-addressable scheme.
Preserving some sort of interoperability with file-sharing applications
would solve the bootstrapping problem (hundreds of thousands of nodes are
already up and running), but the most popular networks (eMule, Overnet and
ReverseConnect) are based on Kademlia, which is a Distributed Hash Table
algorithm and therefore doesn't allow sorted access (useful, e.g., to
locate the reflector with the largest available bandwidth). I recently
discovered a few tree-based distributed algorithms which would allow just
that:

P-trees: http://techreports.library.cornell.edu:8081/Dienst/UI/1.0/Display/cul.cis/TR2004-1926

SkipGraphs: http://www.cs.yale.edu/homes/shah/html/pubs/skip-graphs.html

P-Grid: http://www.p-grid.org

JXTA would be very good for such a purpose. Anyone want to start such a open source project? Instead of waiting Skype to be available on my Solaris 10 laptop, such a project would be a nice fit.

For the last 2 weeks, I have being seeing a lot of returned(undeliverable) email for a spam with title 珍贵的中国人呀！ in my mailbox, but it is not me sending the email. Following is a sample:

Return-path: <>
Envelope-to: **my real email censored**
Delivery-date: Sun, 02 Oct 2005 01:14:23 -0700
Received: from s001.sfo.collab.net ([64.125.133.201] helo=jxta-DOT-org)
	by localhost.localdomain with smtp (Exim 4.50)
	id 1ELyzH-0002CM-I6
	for henryjen-AT-ztune-DOT-net; Sun, 02 Oct 2005 01:14:23 -0700
Received: (qmail 27832 invoked by uid 5000); 2 Oct 2005 08:14:14 -0000
Delivered-To: httpd-slowhog-AT-www.jxta-DOT-org
Received: (qmail 27827 invoked from network); 2 Oct 2005 08:14:13 -0000
Received: from asmx1.sfo.collab.net (64.125.133.81)
  by s001.sfo.collab.net with SMTP; 2 Oct 2005 08:14:13 -0000
Received: from mail.foodqs-DOT-com ([202.96.125.80])
	by asmx1.sfo.collab.net (8.12.8/8.12.8) with ESMTP id j928E6vg003207
	for ; Sun, 2 Oct 2005 01:14:10 -0700
Date:     Sun,  2 Oct 2005 16:12:08 -0500
Message-Id: <10510021612.AA67948034-AT-mail.foodqs-DOT-com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
From: "Postmaster" 
Sender: 
To: 
Subject:  Undeliverable Mail
X-Mailer: 
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on goldfish
X-Spam-Level: 
X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_12_24 
	autolearn=no version=3.0.3

User mailbox exceeds allowed size: 168-AT-mail.foodqs-DOT-com
User mailbox exceeds allowed size: csm-AT-mail.foodqs-DOT-com


Original message follows.

Received: from mail.hhujba.com [210.123.37.77] by mail.foodqs-DOT-com
  (SMTPD32-8.02) id AD262E701A6; Sun, 02 Oct 2005 16:12:06 -0500
Received: (qmail 18110 invoked from network); 02 Oct 2005 17:11:18 -0000

Reply-To: <slowhog-AT-jxta.org>

Message-ID: <20051002171118.BE4CD1594013-AT-nhujba>
From: xiufede-AT-gmail-DOT-com
To: 168-AT-foodqs-DOT-com,csm-AT-foodqs.com,lxf@foodqs.com
Subject: =?gb2312?B?1eS587XE1tC5+sjLo6GjoQ==?=
Date: Sun, 02 Oct 2005 17:11:18 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_0018_01C39816.2C871AA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_001_0018_01C39816.2C871AA0
Content-Type: text/plain;
    charset="gb2312"
Content-Transfer-Encoding: base64

[message truncated]

As you can see, the reply-to header is assigned to the email I registered for the JXTA project. I believe the "From:" is also spoofed. If you get a spam like that, I am sorry but it was not me.