MetaNet is a software project initiated by ErikWalthinsen as an attempt to make building network services easier. At a high level it is a message-passing infrastructure designed to allow programs to tap into each others' control flow. Services such as sockets and HTTP servers are objects with their own set of mailboxes (in the form /daemon/object/message), some of which are hooked by the object itself, some of which are intended for their users to hook.
A good example of the reason for this architecture is the case of DHCP and LDAP. Start with a DHCP server implemented on MetaNet. It will create a listening socket on the right port, and attach a function to catch incoming packets. Those are converted to a DHCP request message, which normally is hooked by a function that does the normal DHCP lookup in the free-pool. That function sends a message to the DHCP-reply mailbox, which triggers a function to send the right packet.
Say you had an LDAP database that held the mapping from hostname/mac to IP, and you wanted to drive DHCP with this. You'd write a function that would hook the DHCP-request message and instead create an LDAP request. A second function would take the LDAP response and reformat it to the DHCP reply, to be handled again by the DHCP code to convert it to a packet and send it to the machine.
Captive Portal Feature Requests
- A simple blog/guestbook so people can leave comments and the node owner can post messages. Perhaps loading in portions of the splash page into a text box (psuedo wiki style) would be a good way to allow node owners to do updates and customize their page with relevant information.
- Actually a better way to do this is to point it at the NodeXXX wiki page for comments. It should be able to retrieve it's node ID number from the mapping software or possibly just provide a text box which will just append to a wiki page for them to make it easier.
Another more decentralized way to do this would be to store comment data within MetaNet and then to write a wiki module for (eg. [[NodeData(351)]]) which pulls basic information from the MappingSoftware and then also pulls comment data from the MetaNet instance itself. If it's not up you probably don't care about the comments
- Some way for ICQ/Jabber address to be listed on the status page so people can find each other.
A UrlDaemon implementation. It could feed status page information and perhaps have a web front end to allow the owner to update the broadcasts.
Should be able to update the MappingSoftware with a date stampe everytime it's used. Feedback of this sort is the absolute best monitoring we can get.
Map maintenance front end. The owner of a node should be able to put in all their information into the admin interface of MetaNet, and MetaNet should be able to publish (or send updates) to the map server. An advantage of this is that the node then has information like latitude and longitude which an AdhocRouting protocol could potentially take advantage of.
It should keep track of locally (and ideally post to the MappingSoftware) statistics on node use. Number of times used per day/week/month/year, amount of bandwidth used, number of visitors etc. This allows people to have a sense of ownership and accomplishment from running their node. For example, I have no idea if anyone ever uses my node ... thus I tend to be very casual about fixing it when it breaks. If I know that it was getting regularly used then I would be much more willing to put in some effort to keeping it running.
So this is getting a little disorganized. I've been thinking a lot about how to make MetaNet interoperate with the maps server and how to make the whole thing as decentralized as possible. It would be cool if all node maintenance could be done via MetaNet (which acts as a map server client). When you click on the map software to few a nodes details it could be served straigh from the web server in MetaNet (proof that it's up).
When first created it should be able to create or download a config from the MappingSoftware.
I'd like to be able to offer my wireless machine services not available to the public wireless users of my node. For example, I'd like my wireless laptop to see my shared drives on my home's server, but I don't want public users of my node to be able to use these services. DavidSmith