Daniel Brookshier's Blog: April 2005 Archive

We have another crop of new projects in in the Global Education and Learning Community (GELC). This week we have a system to publish theses, a Bliki written in Java, a Java Exam simulator, masters thesis investigating an agent-based privacy directive, a recorder that watches you work and listens to your speech, a compression database, language parser, and a purchase calculator. Take a look at these great projects and lend a hand to help them start.

liber-theses - Publish and catalog theses online
jrapido - Simple Java Bliki (Blog+Wikki)
JMockgen - Online Mock Simulator
Information-Agents - Investigating needed software for an active privacy directive
Copycat - A notepad that records writing and speaking
Compression - Compression of files to a database
CNLangParser - CN Language parser
Checkboxes - Display currency

Read on for more details on these projects

Peer Presence in JXTA

Posted by turbogeek on April 11, 2005 at 10:53 PM | Permalink | Comments (0)

First, I apologize for my long absence from blogging at java.net. I have a busy job as Chief Architect at No Magic. I do talks at conventions, training, run development in three countries (Lithuania, Thailand, and the US), and sing and dance for customers. Kind of hard to get time to blog on my passions of P2P and Java. So without further ado, no more excuses.

Lots of people assume you can just ask for who is online. Not going to work, unfortunatly.The problem is that the request is done through the protocol rather than a DB call which is what you would expect.
In the current implementation the RDV has an in-memory knolledge of the peers and their information. As each new peer arives, its info is added to the list plus broadcast to all connected peers. The new peer gets a copy of the list so that it knows about everyone currently on line.

In my new version, the data passed around will be minimal with just the peer ID, an email, and a last update date. The brunt of the data will be stored in an advertisement indexed by the peer ID. If the last update is newer than the local advert, the peer fetches the advert by specifying the peer ID and using the peer ID as the index (confused yet?). This works because the advert is matched via a primary key. If you just asked for adverts of a particular type, you only get the first few advertisements.

Now, if the peer is coming online and it has never done so before, it gets a list of peers online. It iterates through this list, asking for an advert of each peer. It only asks for the advertisement, but does not specify that only that peer be searched. So, what happens is that the nearest peer that has that advertisement will reply. The peer then checks the date of the last update and the date in the advertisement. If the date is older, it then re requests an advertisement from the peer+peerID so that it gets the most up to date copy. The upshot of this is that the info about the peer gets replicated so that no one peer is inundated with info plus each peer caches its view so that requests are limited to peers that have just changed their resume'.

Why not store all this on a RDV? The problem with that is it turns the RDV into a server. It loads it down with cpu, bandwidth, and memory reduction. It also causes it to be a greater point of failure. The less information stored on a RDV, the better.

Now for the magic of the presence system. I had said we don't want the RDV to serve. Well, it has to do a little, but only to peers connected. The data is also transient. As a peer connects it adds data. As it disconnects, it removes data. But if the RDV fails or is taken offline, peers will reconnect to a new RDV and add their info to the new RDV. So this is in fact fault tolerant.

Now for my next trick. Peers need to belong to peer groups. These help to do three things. First is just the address space, second is the ability to accept messages between peers only in the peer group, and finally to only use resources within the peer group. The final bit is of most concern to us. Since the core of peer presence is run from the RDV, only the peers in the peer group will get messages and be able to see data about fellow peers. This helps scale the system plus if we are doing this the most efficient way, a couple of peers within each group are volunteered as RDV which means no single computer does the duty for all peers.

New projects in the Global Education and Learning Community for April 5th, 2005

Posted by turbogeek on April 05, 2005 at 10:00 AM | Permalink | Comments (0)

We have another crop of new projects. This week we have learning with orangutans, a study group using Java, the implementation of a belief-system algorithm, and a system for managing a volunteer organization. Take a look at these great projects and lend a hand to help them start.

Orangutan
A game for learning using
https://orangutan.dev.java.net/
Owner: kauzet@dev.java.net

A game for learning by helping orangutan survive in the Bornean forest.
An interactive game for children 3-12 years old. they can learn how Bornean orangutan can survive in the natural Bornean forest.

fuja
https://fuja.dev.java.net/
Projects, articles and sample code produced by a Brazilian study group
Owner: dwildt@dev.java.net

FUJA (FACENSA Usuários de Java) is a Java study group that works inside FACENSA (www.facensa.com.br) College. These students get together and produce Java code, articles and proofs of concept in many Java Technologies, like WebServices (Axis), Mobility (J2ME), Enterprise Apps (EJB), Web Standards (Struts, JavaServerFaces, Servlets, JSTL, JSP), IDEs (Eclipse, NetBeans), Persistence (Hibernate, Torque, POJOs), XML and other technologies.

Dempster-Schaffer - Dempster-Schaffer algorithm - Measuring belief and plausibility to make a decision based on multiple inputs.

https://dempster-schaffer.dev.java.net/

Owner: soticia@dev.java.net
Development of the Dempster-Schaffer algorithm in Java. To learn more, see: http://www.eng.man.ac.uk/mech/merg/Research/datafusion.org.uk/techniques/dempster.html which has information about this algorithm. Here is what that web site has to say about the algorithm: “Dempster-Shaffer theory allows us to allocate probability-like weights to a set of events in a way that allows statements of ignorance about likelihood of some of the events. From the allocation of weights we get two numbers; the degree to which an event is supported by the evidence (Belief), and the degree to which there is a lack of evidence to the contrary (Plausibility). These two numbers are the basis on which any belief-based decision is made.”

DonorManagementSystem

https://DonorManagementSystem.dev.java.net/

A system for managing people and resources for volunteer Organizations.
Owner: smartware@dev.java.net

This is a system that will Enterprise Java Beans used to manage donors and sponsor in Volunteer organizations. The system will be able to track down the donors, sort them into groups, generates their history, produce donor certificates. The system will also map volunteers with their favorite chores. The system will have a simple management display to help in decision-making.

Powered by
Movable Type 3.01D

java.net RSS Feeds