Cerebro

Layout information

Scaling properties

What is Cerebro?

Cerebro <ref>http://cerebro.mit.edu</ref> is a scalable, light-weight platform that provides presence information, efficient file sharing and an easy collaboration mechanism for activities.

Features

The following is a list of features that Cerebro offers. Some (marked with a *) are under development.

• presence information (including distance and route) for all other users in the network
• mesh network extended to regular 802.11b/g devices
• extensible user profile including nickname, colors, keys, IP addreses, picture of arbitrary size, status message etc
• file sharing using an efficient multicast mechanism
• simple collaboration mechanism
• connect to remote mesh networks over the internet (*)
• interoperability with regular x86 machines (*)
• internet connection even without a valid IP address (*)
• programming API based on dbus (see examples)

Presence Information

Presence information involves the set of users/XOs that are currently accessible over the mesh network. This information is decoupled from the user profile so as to increase the scaling properties of the presence mechanism. For example, it is possible that we know that there are 120 users in the network, but only have detailed profile information about only 100 users. Fore the rest, we have not received their profile information, yet!

A cache is used to store user profiles (so as to avoid having to retrieve all user profiles every time we join the network) and events are triggered whenever a user modifies her profile.

File sharing

Since we have a presence mechanism that provides network layout information, we can make better decisions on how to efficiently distribute files within the mesh network.

A mechanism for sharing files efficiently within the mesh network is offered. When enough file recipients are present as direct neighbors <ref>http://cerebro.mit.edu/index.php/Experimental_results</ref>, a file is simultaneously broadcasted to all of them instead of establishing sequential TCP sessions. The presence mechanism is consulted in conjunction with the set of receivers to decide whether it is worth using the broadcast mechanism or not. Experiments have shown that roughly when more than 15 recipients are direct neighbors, it is more efficient using the broadcast mechanism.

The file sharing mechanism is used by Cerebro itself to transport (potentially large) user profiles within the mesh network. Also, API calls allow activities to make use of this mechanism.

Collaboration

Since we have a means of sharing profiles and trigger events within the network, collaboration between activities is simply achieved by adding information in the user profile about what activities the user is currently sharing. Activity sharing information involves activity type and instance: Every activity is a of specific, "well-known" type and each instance being shared receives a unique identifier. This way it is possible to share new activities and join specific activities from across the network.

Again, API calls provide the primitives for sharing, joining and leaving activities.

Programming API

The API is currently under development. This means that slight changes may be done in the future to the arguments of the API interfaces and new interfaces will probably be added. Comments/suggestions/patches are most welcomed!

register (method)

Input : activity_type, dbus_name Output: A unique activity ID (aid) Description: Register a new activity instance in order to access the services and events offered by Cerebro. This method does not share with the activity with neighborhood.

---

unregister (method)

Input: aid Description: Unregister an activity instance (identified by "aid").

---

on_node_arrival (signal)

Output: Array of node IDs that joined the network Description: Receive notification when a new node joins the netowrk, The activity may choose to act on this.

---

on_node_departure (signal)

Output: Array of node IDs that left the network Description: Receive notification when a new node leaves the netowrk. The activity may choose to act on this.

---

get_personal_info (method)

Output: A buddy dictionary containing current user information Description: Retrieves user personal information.

---

set_personal_info (method)

Input: A buddy dictionary containing new user information Description: Updates user personal information.

---

received_data (signal)

Output: data, buddy, src, port, aid Description: A signal that gets emitted whenever "data" is received from "buddy" (who has the unique ID "src"), for activity instance "aid" which is of type "port" (eg Chat).

---

push_data (method)

Input: aid, data, port Description: Sends "data" to all users participating in the shared activity identified by "aid" which is of type "port".

---

exec_command (method)

Input: A command string Description: Executes "command" on the local machine. This method is provided for debugging and may be removed.

---

list_shared_activities (method)

Output: Returns a list of tuples, each containing 3 fields: nickname, aid, activity_type Description: This method returns a list of all activities currently shared in the network and the nicknames of the users that are participating. The activity ID "aid" provides the unique identifier for each of the shared activities and "activity_type" provides the type of the activity.

---

show_mst (method)

Output: A list of nicknames (or user ID, if we have not received profile information yet), the corresponding distance to each user, and the path (consisting of other nicknames) that needs to be followed to reach the remote nickname. Description: Returns the minimum distances from the current node to all other nodes present in the network.

---

show_network_tree (method)

Output: Same as "show_mst", but includes all possible paths known from the current node to the remote destination. Description: Returns all known paths from the current node to all other nodes present in the network.

Cerebro test plan