Scalable Messaging Model

Roadmap
67

Hi all - excited to share the good news: best-effort responses are available for experimentation in dfx, and we’re excited to see what you folks can build with this feature!

Dfx version 0.24.1-beta.1 includes a replica version with best-effort response support. You can install it using dfxvm:


dfxvm install 0.24.1-beta.1

DFINITY will be adding documentation on this new feature to the Internet Computer website soon. For the moment you can check out these demos, written in Rust, since the Rust CDK already offers support for this feature on its next branch:

We hope to also have Motoko support soon.

The feature is currently still disabled on mainnet. There are a few other pieces that need to be in place before it’s safe to enable this in production, but we wanted to enable the community to experiment with the feature as soon as possible. The two main immediate benefits of using best-effort responses are:

  1. It’s safe to call out to untrusted canisters using best-effort responses. The callee cannot make your canister wait for a response forever, which means that they cannot prevent you from stopping and safely upgrading your canister.

  2. It’s predictable how long a canister call is going to take, making it easier to build responsive applications.

To finish off, let me also list a couple of cases where one has to be careful using best-effort responses:

  1. If the call makes the callee perform state changes (e.g., transfer tokens), then care must be taken to ensure that either the call can be safely retried, or that its results can be obtained. Note that this is similar to what should currently be done for ingress messages; see the documentation on safe retries for more details. Any kind of read can be safely performed with best-effort response calls, and, if necessary, safely retried in case of timeouts, since reads are idempotent.

  2. Cycle transfers. If timeouts occur when depositing cycles to another canister, or when cycles are added to the call, the cycles will currently be lost. While this is something that we want to improve later on, given enough interest, cycle-transferring calls should currently stick with the guaranteed response model, or limit themselves to small amounts where potential losses are acceptable.

If you have concrete plans to use best-effort responses in your app, we’d love to hear about them!

12 Likes