Now that we've seen a little of what eBrainPool can do, I thought I'd doodle a bit and do my best to explain how the current developer's release works under the hood :)
The above schematic shows how the different technologies used come together.
- Olsr Routing - as mentioned earlier for mesh networking and discovery of neighbouring devices we're using the OLSR protocol implementation developed by the olsrd project (www.olsrd.org). This is a seperate daemon that needs to be started independently at the moment.
- Olsr Plugin - we've created our own plugin and extended the core olsrd program. Whereas the core olsrd recognizes devices with olsrd running and sets up the routing table to form a mesh, the plugin explicitly publishes the current host as having the eBrainPool client working and thereby willing to share software. It also looks out for other such devices in the mesh. Finally it pushes out information such as IP of the found device and username to the client.
- eBrainPool client - this client offers the interface by which a user can see the other users in the Beehive mesh networked pool around them and select applications to run from these users. It first checks to see that the IP the olsr plugin has told it has a valid client up and running. If so, the username of this client gets added into the list. When a user clicks on a partciular username all software currently hosted by that user is pulled out and shown. If a user wishes to run a particular remote software, an SSH connection is formed between the two devices. For this connection a custom ssh server gets started (currently via scripts) at the end hosting the software. The ssh client at the users end connects to this and requests the specific remote software to be X forwarded back through this tunnel. FUSE allows for data to be abstracted so that even if you are using software from someone else you can still use only your data. Neither end can access or view the other persons data.
Whew :)...hope this helps understanding the mayhem :). And yes I know I have terrible handwriting ;)
1 Comment
on architecture, ssh and next release
Submitted by erle on
Comment:
We can see where the ideas for the next release come from :) . Getting it to this point was a mammoth effort (but loads of fun.... including a marathon 22 hrs straight ), and involved a wide array of technologies we evaluated before settling on the combination you see above.
Amongst the various things about the current design bothering us, was the fact the there are too many niggly bits and pieces which need to be setup correct for it to run. When setup, it runs and runs well, which is good, but need to lower the entry barrier. Not everyone can be expected to setup the little bits and pieces to get all running.
The need to reduce the complexity of setup is amongst our foremost concerns and implementing an easier mechanism for everyone to handle the ssh keys which are required for the connection is the first in a long list of concerns.
After that a nice clean Fuse integration would be nice, cleaning up the Olsrd implementation, maybe a plugin mechanism, to use this over other mesh protocols... just to name a few.
Wish ... wish.... we could do all of it quickly, but right now it is just Jeetu and myself who are building this up. Thankfully, we code fast :)
We could really...... really use any help. If you want to get involved, please drop us a message indicating the area of your interest and we can take things forward from there. Mail, Comment, Twitter, anything.
Pages
Add new comment