【Communication Model】
EOSIO actions operate primarily in a message-based communication architecture. A client invokes actions by sending (pushing) messages to nodeos. This can be done using the cleos command. It can also be done using one of the EOSIO send methods (e.g., eosio::action::send).
nodeos dispatches action requests to the WASM code that implements a contract. That code runs in its entirety, then processing continues to the next action.
EOSIO supports two basic communication models, inline and deferred.
1、An operation to perform within the current transaction is an example of an inline action,
2、while a triggered future transaction is an example of a deferred action.
Communication among contracts should be considered as occurring asynchronously.
1、Inline Communication
Inline actions operate with the same scopes and authorities of the original transaction, and are guaranteed to execute with the current transaction.
These can effectively be thought of as nested transactions within the calling transaction. If any part of the transaction fails, the inline actions will unwind with the rest of the transaction. Calling the inline action generates no notification outside the scope of the transaction, regardless of success or failure.
2、Deferred Communication
Deferred actions get scheduled to run, at best, at a later time, at the producer's discretion. There is no guarantee that a deferred action will be executed.
The transaction that creates the deferred transaction, it can only determine whether the create request was submitted successfully or whether it failed (if it fails, it will fail immediately).
【Transactions VS. Actions】
An action represents a single operation, whereas a transaction is a collection of one or more actions. 交易是 actions 的集合。
A contract and an account communicate in the form of actions.
Transaction with one action：
{
"expiration": "2018-04-01T15:20:44",
"region": ,
"ref_block_num": ,
"ref_block_prefix": ,
"net_usage_words": ,
"kcpu_usage": ,
"delay_sec": ,
"context_free_actions": [],
"actions": [{
"account": "eosio.token",
"name": "issue",
"authorization": [{
"actor": "eosio",
"permission": "active"
}
],
"data": "00000000007015d640420f000000000004454f5300000000046d656d6f"
}
],
"signatures": [
""
],
"context_free_data": []
}
Transaction with multiple actions, these actions must all succeed or the transaction will fail：
{
"expiration": "...",
"region": ,
"ref_block_num": ...,
"ref_block_prefix": ...,
"net_usage_words": ..,
"kcpu_usage": ..,
"delay_sec": ,
"context_free_actions": [],
"actions": [{
"account": "...",
"name": "...",
"authorization": [{
"actor": "...",
"permission": "..."
}
],
"data": "..."
}, {
"account": "...",
"name": "...",
"authorization": [{
"actor": "...",
"permission": "..."
}
],
"data": "..."
}
],
"signatures": [
""
],
"context_free_data": []
}
Action Name Restrictions
Action types are actually base32 encoded 64-bit integers. This means they are limited to the characters a-z, 1-5, and '.' for the first 12 characters. If there is a 13th character then it is restricted to the first 16 characters ('.' and a-p).
Transaction Limitations
Every transaction must execute in 30ms or less. If a transaction contains several actions, and the sum of these actions is greater than 30ms.
【Action Handlers and Action "Apply" Context】
Actions operate within transactions; if a transaction fails, the results of all actions in the transaction must be rolled back.
An action can have many side effects. Among these are:
- Change state persisted in the EOSIO persistent storage
- Notify the recipient of the current transaction
- Send inline action requests to a new receiver
- Generate new (deferred) transactions
- Cancel existing (in-flight) deferred transactions (i.e., cancel already-submitted deferred transaction requests)
参考：
1、https://developers.eos.io/eosio-cpp/docs/communication-model