Actions

Byzantium: Difference between revisions

From HacDC Wiki

Line 47: Line 47:


=== Distributed DNS ===
=== Distributed DNS ===
[http://en.wikipedia.org/wiki/Distributed_hash_table Distributed Hash Table (DHT)] - Wikipeda page on DHTs. Has a decent overview of how they work.
[http://www.bamboo-dht.org/ Bamboo DHT] - A DHT implementation in Java.
[http://www.bamboo-dht.org/ Bamboo DHT] - A DHT implementation in Java.
[http://code.google.com/p/upright/ UpRight] - A library for building fault-tolerant distributed systems. Incorporates innovations from modern solutions to Byzantine fault tolerance.
[http://code.google.com/p/upright/ UpRight] - A library for building fault-tolerant distributed systems. Incorporates innovations from modern solutions to Byzantine fault tolerance.

Revision as of 04:02, 2 March 2011

This project will be launched with a sprint on Feb 25-27, 2011.

Project Goals

The goal of Project Byzantium is to develop a communication system by which users can connect to each other and share information in the absence of convenient access to the Internet.

The use cases for such a system would be:

  1. The infrastructure for accessing the internet has become damaged or inaccessible. (Eg, a natural disaster such as Hurricane Katrina.)
  2. A central authority has decided to explicitly block or shutdown key infrastructure. (Eg, Egypt's recent internet blackout.)
  3. A zombie apocalypse in which the personnel responsible for maintaining key infrastructure have all been turned.

The project aims to develop and publish the necessary documentation, best practices, and software to construct and support such a system. Our current approach is to start by investigating and documenting the existing technologies which would support such a system. In particular, mesh networking protocols, wireless networking technologies, and decentralized (or less-centralized) alternatives to internet addressing/naming systems such as DNS. In designing the system, we aim to reduce the dependency on exotic hardware or skill sets so that the system can be deployed quickly and easily by average internet users.

Sprint 1

Goal - Reliably bridge two different and separate wireless networks without using existing internet infrastructure.

Design goals 1) There should be a webserver on each network. 2) Nodes in either network should be able to reach both webservers. 3) Nodes on one network should be able to talk to nodes on the other network and vice versa. 4) Networks should have at least 3-5 nodes each.


Tentative schedule is as follows:

Friday - 8:00pm Pizza and planning (any particular request should email me off list). (COMPLETE!) Saturday - 9:00am Start showing up (IN PROGRESS!) Saturday - 10:00am Divide into groups and start the sprint. Sunday - 10:00am Start showing up. Sunday - 11:00am Finish the sprint! Sunday - Evening Debriefing (I'll be taking extensive notes to update the wiki).

Notes: BATMAN Babel Babel Setup BATMAN-Advanced Setup

Plans! We're gonna have two teams each will implement a mesh network using some existing mesh protocol. One team will be working with BATMAN and the other with BABEL. Each network will use at least one openwrt device the rest will be laptops and netbooks.

from Wikipedia: Byzantine

Interesting threads: A few comments on the BATMAN routing protocol A few more comments on the BATMAN routing protocol

Distributed DNS

Distributed Hash Table (DHT) - Wikipeda page on DHTs. Has a decent overview of how they work.

Bamboo DHT - A DHT implementation in Java. UpRight - A library for building fault-tolerant distributed systems. Incorporates innovations from modern solutions to Byzantine fault tolerance.

CoDoNS paper - A very good paper from 2004 on a distributed DNS alternative. It still relies on centralized domain name registration. CoDoNS main page - It appears that CoDoNS is operational and running on PlanetLab. Unfortunately, I don't see any code. I see no reason why we can't simply hijack their design.

Tutorial on DNS and DNSSEC

Intentional Naming System - "INS is a new naming system intended for naming and discovering a variety of resources in future networks of devices and services. It has the following interesting characteristics about the way it names resources and the way names are resolved."

Sprint 2