Chameleon Group Communication Framework for Smartphones Last build - 010 2012 Roy Friedman David Sainz Sourceforge project

News

Overview

Chameleon works by building a user-space multi-layered protocol, which is placed above an IP network and below the application. Instead of using sockets, the application communicates with this protocol. The protocol takes care of networking aspects and provides the application with various notification in form of events. Multiple layers are supplied within and more can be easily added. To get started, download some sample projects.

While not strictly limited to, Chameleon is intended to work in Ad-Hoc, or local LAN networks.

Features

Available layer features for protocol stacks

• For UDP
  • Discovery
  • Discovery
  • Reliability
  • Sender FIFO
  • Flow control
  • Fragmentation
  • Broadcast
  • Software CRC32
• For TCP
  • Framing
• Idle detection
• View management
• Virtual Synchrony (strong)
• Total Order
• ...some others...

Automation features

• Automatic generation of header objects and their serializers from XML schema. Massively assisted by JiBX.
• Configuration and bridging of missing functionality to allow automatic translation of J2ME compatible code based on Chameleon to .NET Compact Framework with Sharpen.

Group Communication

(or why all this is needed)

Suppose you want to build a multi-user application with some kind of interaction between the users. It could be a multi-player game, a chat app or maybe some kind of content sharing application. The generally accepted approach for such needs would probably be client-server. The always-on server resides in a well-known location, clients tell it what they "do", the server aggregates the actions of all clients, decides on the new state and disseminates it to clients, tells them what they "see".

Sometimes, however, you can't, or don't want to use a server. It's expensive, it's not convenient to your users, especially if all they need is connectivity to each other. In such case you might be tempted to try and do without, utilizing only the local Ad-Hoc, or local LAN connectivity. However, this might turn out not be so trivial, as many communication properties that come free in a client-server model become not so easy to achieve in a fully distributed model. Especially if you want to avoid having a single point of failure, and thus allow your users to connect and disconnect at will. Just think, how would you monitor who's currently connected? How do you maintain this connection knowledge consistent between peers? How do you enforce properties on message ordering? If you don't, then different peers might receive messages in different orders, making it hard to maintain an illusion of a single consistent state. When we had the server it performed all these tasks. But, luckily, all these problems can be solved with appropriate distributed algorithms. Better yet, the problems are rather generic, so it makes sense to build a library to solve them. And this is what Group Communication is all about - allowing easy, reliable, consistent communication in distributed environment.

For much more complete information see Group communication specifications: A comprehensive study.

Build

Check out the code from source forge and follow READMEs.