Server design

Device Detection with Zeroconf

We use the ruby (dnssd library) (http://dnssd.rubyforge.org/dnssd/) and [Avahi] (http://avahi.org/) in our zeroconf setup. Using these, we have each roomtrol client broadcast itself via Multicast DNS when it comes online, and when it leaves. roomtrol_server is constantly browsing for _roomtrol_tcp zeroconf devices and notices when the device (the actual Ubuntu box in the classroom) broadcasts itself and the roomtrol_server code does the following:

• Resolves the device to a specific ip address and port.

• Establishes two SSH port forwards with Net::SSH:Service::Forward

  • one forwards from a port on the server to couchdb on the client (port 5984)
  • the other forwards from a port on the server to the roomtrol-daemon on the client (port 1412)

• A document is created in the servers couchdb which contains the room name, port used for forwarding and the last time the room was interacted with. This document is a metaroom in a sense,

• Once port forwarding is established, CouchDB replication is setup from client to server.

Database syncing

The server gets updates on everything that happens on the clients by means of CouchDB's [continuous replication] (http://books.couchdb.org/relax/reference/replication#Continuous%20Replication) feature, from the clients to the server. That way, the server is constantly up to date and the info we show users is good. Since continuous replication isn't remembered over restarts of the couchdb daemon, we'll need a script that runs on couchdb start (upstart lets us do this) that starts replication.

Device detection

Device detection should happen automatically, probably using ZeroConf networking (Bonjour). There are several ruby libraries that do this, but we probably want to use "this":http://dnssd.rubyforge.org/dnssd/ one because it's cross platform and can use either Bonjour (on OS X) or [Avahi] (http://avahi.org/) on Linux. Avahi can also be interacted with over DBus, but that only works on linux and in the past I've found the ruby DBus library to be iffy.

Sending commands to devices

We need a secure way to send commands from the server to the devices. I see two options: either establish ssh connections with the clients and tunnel all traffic over those (we could also do this for replicating couch, which is nice) or use private key authentication in WescontrolHTTP itself (i.e., the server's public key is installed on all the clients and it has to send a message signed with its private key in order to communicate). The former is probably simpler because the OpenSSH people have done the hard work already, but the latter might be more reliable.

Configuring devices

This is a little bit tricky, because obviously in order for configuration to do any good it has to be in the client's couchdb database. However, I'm not sure if we want to do replication from the server to the clients, because then every client will get everybody else's data which it has no use for. Maybe we should send the commands directly to the client's couchdb which will then get replicated by to the server automatically.

EDIT: Actually, it turns out that in CouchDB 0.11 (released in May) [replication filters] (http://blog.couchone.com/post/468392274/whats-new-in-apache-couchdb-0-11-part-three-new) were added. This will let us use replication to do what we need, because we can specify that only the documents belonging to that client will get synced back. In other news, CouchDB is still incredibly awesome.

Eigenrooms

An eigenroom should act exactly like a device for the server's roomtrol-daemon instance. However, each eigenroom couchdb document will also have additional information for the how to contact the eigenroom including: * room_id - which is the couchdb _id value of the represented room. So, all sources for a given room should have belongs_to equal to the room_id for that room's eigenroom. * room_name - the hostname of the device in the room. * ip_address - the ip_address of the room * daemon_forward_port - a ssh forward should exist from server:daemon_forward_port to ip_address:1412. Note: this should be somewhat equivalent to doing a manual ssh [email protected] -L 9001:roomtrol-dev2.class.wesleyan.edu:5984 -N command. * couch_forward_port - a ssh forward should exist from server:couch_forward_port to ip_address:5984.