The Resonance Solution

This section describes my proposed solution, known as resonance, which is intended to rectify the current weaknesses of the internet

Intended audience for this system

This solution is intended to be aimed at any home user who performs many online activities with other people (such as games, card games, file sharing, etc). Even businesses however could potentially benefit off resonance as it could potentially allow them to perform common tasks such as remote administration easier.

Purpose of resonance

The purpose of resonance is to facilitate sharing of services on the internet with other friends, and keep users options open so they can easily and efficiently join in on activities shared, such as games, your website, file sharing, etc. It also prevents users having to know about the low level addressing the internet uses to connect to others, or manage ports to access others on the internet. It also opens up a whole new world of new programming techniques that can be used to allow users to easily connect to each other.

Basic design in a nutshell


Resonance is basically a service sharing tool, which means that if you want to start a service which your friends can easily join without any configuration, you just start it, and set it to be managed by Resonance. Any users who want to see services of the type you started, right after they are started will have a message pop up on their screen, so they know instantly that its started, and others will be able to just go down a small list of services their computer knows about and selects yours, which will automatically connect them to the service. No more fiddling with IP's, ports, or your firewall.. It all just works as it should.

What is Service sharing?

Service sharing is the sharing of services with other people. While the definition of a service is something which can be shared, service sharing in our context is where we actually share an entire list of services, broadcasting them to friends so that they have a full list available and can easily access them. Normally, sharing services involves informing friends manually that the service exists and giving them the details. Resonance will allow all authorized people to be aware of the service as it is started and allow them to join it with 1 or 2 clicks of the mouse.

Indirect benefits it may bring

Resonance will allow many unsuspected internet applications to indirectly benefit, such as new forms of firewalls that only let friends through, or even native file sharing protocols (like Samba/microsoft file sharing) to have their shares automatically mounted with a click of a button, so you can share files with your friends more easily. Other benefits include completely decentralised networks and decentralised radio relays. Finally, service sharing has the potential to make the internet much more stable, by reducing weakpoints in the system.

Instant messaging centric design

Currently, connecting to a friends server involves your friend sending the 'address' details of their computer to the users who want to access the service, and this process is normally done over an instant messaging system. Because it is most likely friends who want to access your services, IM naturally makes a good choice to share all your services with a roster list of people. Instead of creating masses of different networks though to allow this to happen, the aim of resonance is to blend naturally complementing services together to build up the network. The proposed design will use the jabber network, which will allow people to still communication with people who aren't sharing services, and will not require a mass migration to the network to communicate to other resonance users. Fortunately, jabber provides 'transports', which allows users from other instant messaging networks to their favorite jabber server.

Securing service information

To ensure the security of different services, services should be given different permissions to decide who should be permitted access to their content. This will involve keeping a list of each user level, and setting their privilages individually. The 3 levels of proposed user levels are:
  1. Anonymous: This covers everyone who isn't on your internal network, and who aren't on your user roster, basically just any joe blow off the internet.
  2. Friends: This covers everyone on your resonance roster. This level takes precedence over the others.
  3. Local network: This covers everyone on the same local network as you. Basically, anyone who is accessible within the 'Bon Jour' protocol, is covered by this level

Each user class has their own privileges, which are actions they are authorized to do with the service. The actions are:
  1. No access: this prevents the user class from accessing the service at all.
  2. On a per user/IP basis. This forces the service owner to specifically allow that usaer to use the service. Normally, this will involve a prompt popping up on the screen as they try to connect to see if they should be allowed through
  3. Full Access. This allows any user within the user class to access the service, without any intervention

These permissions will each be enforced on a per service basis, which means every service which is started is given their own permissions. The only exception of these permissions is to services running as a administrative user, in which case, it will not be possible to set them to allow full access, as that is a security risk.

Handling anonymous connections, and supporting online addresses

For services designed for anonymous users, unfortunately its not as easy to make connecting to others services a 1 click operation, because it is impossible, and impractical to broadcast everyones services to everyone else on the planet (it is actually a very high risk security flaw). It should however be possible to make it relatively easy by generating internet wide service addresses. This is done by creating a service handler for resonance, which can be used by the various web-browsers and applications. The items handled by this would appear similar to webpage addresses, and will look something like: resonance://UnrealTournyServer.Auzy.jabber.org, where the format is resonance://<servicename>.<username of the service owner>.<jabberserver>. Upon clicking a link such as the one above, resonance would automatically load the link, and connect first to the services jabber network, then to the user, and grab the details for the service. After grabbing the details, it would load the relevent service client (only after showing the details to the user though so that they know exactly what is being loaded) and the service is then connected to. This technique could just as easily be expanded to work with friends services just as easily as anonymous ones, making it easier for friends to collaborate with one another.

Connecting to resonance enabled services

Connecting to a resonance enabled service is designed to be very simple. The method used to connect to one will simply involve clicking on the dock applet, selecting a category (such as games), then selecting a subcategory (for instance, first person shooter), the name of the game (for instance, Nutters), and all the Nutter servers friends are hosting will be listed. After selecting the correct game, the user will be shown the full details of the service, which they can use to determine if they want to accept joining the service or not.

To connect to an anonymous server using a service handler involves clicking on the resonance type link (like resonance://fileserver.chicken.egg.com), and details on the server will pop up asking the user if they are sure they want to join the server they chose (as a security measure). If they accept, they are automatically linked to the server if they have the relevent application installed.

Setting up resonance based services

In the perfect case, setting up a resonance-based server will involve starting the computer (which will load the resonance backend and as the user logs in, the resonance applet), logging into jabber, starting the service, adjusting the settings on resonance to appropriate types, and finally, then its done. Provided the router (if there is any) supports upnp, resonance will manage forwarding the internet connections to the computer preventing the need for any router configuration. It will also announce the service to all of the users friends if requested, so they know when it is started. Normally, no configuration should be needed.

As an added bonus, if the application uses resonance exclusively and detects a port is being used on the server already, it will also automatically change the set port it should use from the default if requested, which will not only make the service a bit more secure against script kiddies (as they wont be able to find the service), but will make it easier to run many copies of the same server, on a single computer. Connecting to the service will still remain just as easy however, regardless of changes in port number or IP.

A quick overview of the internal architecture


Resonance will be composed of mainly 2 components, the frontend applet and services.

The frontend is the applet which allows a user to log into the system, and use resonance, and also ensures the security of the user (by using cryptographic methods).

To allow the backend and services to communicate, an internal communications system such as dbus, or possibly even TCP/IP will be employed. Even though it is slightly less reliable, and a bit less powerful, preferably, services will not retain a constant connection with the backend monitoring it, instead only sending simple messages. This makes the system easier for programmers to handle, and makes it slightly more efficient. The ability to maintain a connection will also most likely be provided, and will probably be done using TCP/IP, to allow more advanced/bulk processing of resonance services.

The aim of the system is to maximize portability of code to resonance on other platforms, allowing every operating system to easily benefit. Overall, resonance will be designed to work on at the very least: BSD/Unix, Linux, Mac OS X (probably tiger will be the recommended one), and possibly eventually Windows. Companies wishing to allow quicker support of course of their favorite OS should consider sponsoring the project ;)