Architectural diagram
The framework has two distinctive parts.
- A core that is developed by the Fetch.ai team as well as external contributors.
- Extensions (also known as packages) developed by any developer.
Currently, the framework supports four types of packages which can be added to the core as modules:
- Skills are the core focus of the framework's extensibility as they implement business logic to deliver economic value for the AEA.
- Protocols define agent-to-agent as well as component-to-component interactions (messages and dialogues) within agents.
- Connections wrap SDKs or APIs and provide an interface to network, ledgers and other services.
- Contracts wrap smart contracts for Fetch.ai and third-party decentralized ledgers.
The following figure illustrates the framework's architecture:
The execution is broken down in more detail below:
The agent operation breaks down into three parts:
- Setup: calls the
setup()
method of all registered resources - Operation:
- Main loop (Thread 1 - Synchronous):
react()
: this function grabs all Envelopes waiting in theInBox
queue and calls thehandle()
function on the Handler(s) responsible for them. As such it consumes and potentially producesMessages
.act()
: this function calls theact()
function of all registered Behaviours. As such it potentially producesMessages
.update()
: this function enqueues scheduled tasks for execution with theTaskManager
and executes the decision maker.
- Task loop (Thread 2- Synchronous): executes available tasks
- Decision maker loop (Thread 3- Synchronous): processes internal messages
- Multiplexer (Thread 4 - Asynchronous event loop): the multiplexer has an event loop which processes incoming and outgoing messages across several connections asynchronously.
- Main loop (Thread 1 - Synchronous):
- Teardown: calls the
teardown()
method of all registered resources
To prevent a developer from blocking the main loop with custom skill code, an execution time limit is applied to every Behaviour.act
and Handler.handle
call.
By default, the execution limit is set to 0
seconds, which disables the feature. You can set the limit to a strictly positive value (e.g. 0.1
seconds) to test your AEA for production readiness. If the act
or handle
time exceed this limit, the call will be terminated.
An appropriate message is added to the logs in the case of some code execution being terminated.