Home

Exchange

Previous

Next

Technical

Communication among nodes

The world is not perfect. During the tsunami incident in late 2004, network load peaked because of desperation to find the latest information. Due to lack of preparation for a disaster on this scale, information systems brought up on an ad hoc basis made it difficult to find anything quickly. While much information about victims was available, it was more useful to residents than non-residents because

1. most websites were written in Thai,
2. international bandwidth was congested due to high simultaneous demand,
3. network load was increased by people desperate to find their loved ones -- requesting for pictures to be posted in the hope of narrowing down the search. While clothing, body marks and other objects were of use in identification, these served only to help in narrowing down the search but did not comply with the Interpol DVI process and international protocols. Nevertheless, this approach, used by many NGOs, increased network load and in turn hurt everyone,
4. information was scattered all around Thailand, therefore it was necessary to browse to various sites to find the right information, and
5. priority at the time was safety and alleviation of suffering for the victims -- providing information was a by product of relief efforts.

Network load was painful especially for relatives of the victims. On some busy systems, relocating them to Gigabit Ethernet segments was barely enough to keep going; the entire world was fetching data from these servers. Different relief sites fixed the network load problem by using different approaches. Some relocated their sites to the Internet backbone outside of the country. Another placed their mirror on the backbone .

Should there be a disaster on this scale in the future, lessons from the Asian tsunami must be learned. OpenCARE avoids network congestion by replicating information from one node to another. Therefore, the latest information will be available at a node near the user. Information replication should not rely on a single node to be a single point of failure as in traditional Emergency Operations Centers or relief agencies where one gets the desired information from a single source.

In the three-tier software architecture, a node primarily implements the data and business logic tiers. The presentation tier is implemented in plug-ins which will be described in a subsequent section.

Technologies to move information across to other nodes are short-listed here:

• Tuple-spaces: Simple programming model; publish/read information on a virtual space; get it distributed by means of network services
  • JavaSpace (an introduction )
  • JXTASpaces
  • IBM TSpaces
• Peer-to-peer distribution: Alleviating network load from the original source using p2p
  • JXTA 2
  • Gnutella
  • GNUnet
  • XMPP /Libjingle
• Message Queue : Where only OpenCARE nodes can publish/subscribe. Simple RSS syndication , Podcasting or GData also works if up-to-the-minute information is not necessary
• SOAP /Web services : A widely accepted solution for interoperability. It is, however, questionable for a huge load on the scale of disasters that OpenCARE is planning to tackle.
• J2EE (Apache Tomcat or Geronimo or other Java application server) using SAX for XML processing, JMS for information queuing and distribution. Perhaps, Axis for SOAP. There are concern on server load in case a disaster strikes in an unprecedented scale.

Home Exchange Previous Next Technical

-- TrinTantsetthi - 29 May 2006