We need the ability to adapt the arcology as it scales. A few goals:

• Multiple Hyperion processes, each listening on different domains.
• Clustered Hyperion, where the front-end manages the connection and farms out the processing to other machines (using concept of a district).
• Multiple AeonDb processes, each with their databases. We could have a central dispatcher that knows the location, and clients then cache the appropriate address (at the message transport level).

Hyperion

Add Arc.domains, which keeps track of the binding between domain name and service. When a service is loaded we create entries in Arc.domains, but they can also be modified by the administrator.

Each domain is handled (for now) by one and only one machine, which must have Hyperion running.

We add a command to move a domain from one machine to another. This sends a message to all Hyperion modules to refresh their listeners.

AeonDb

Each AeonDb module owns its own tables. The location of every table is stored in Mnemosynth (so that all AeonDb instances know where every table lives).

When AeonDb receives a request, we check the location of the table. If the table is local, we service it. If it is remote, we forwards the message appropriately (with the proper reply address).

We add an Aeon command to move a database from one machine to another.