Communication between subnets?


One thing I haven’t figured out yet from reading the documentation and this forum is what are the implications of communication across subnets?

I.E If Canister A is communicating with Canister B, all of the communication and calculations can be performed on the same machine that canister A lives on because that machine will also be responsible for Canister B by definition.

However, if canister A wants to communicate with Canister C which is an entirely different subnet, then now you need an additional layers of consensus (inter-subnet) in addition to the existing consensus (intra-subnet).

Is there any info on this? In the first version are applications expected to primarily only communicate with canisters in their own subnet?


Canisters can talk to any canisters, on a functional level there is no difference. Latency will be higher, though.


Does this mean that the difference in time to get a consensus each subnet is the latency of asynchronous processing?

XNet (cross-subnet) message latency is more or less equivalent to ingress message latency, or about 2 consensus rounds. We have measured ~5 consensus rounds (or ~5 seconds) for a XNet request-response roundtrip (assuming the request is processed in the round it is inducted in and immediately produces a response).

1 Like

Thank you.
The latency seems to be quite long, do you have any plans to reduce it in the future?

1 Like

Same as with block rate (limited by max network roundtrip latency between replicas x 3), there isn’t much that can be optomized here. You need the “server” subnet to induct the request (i.e. go though consensus once) and, once the response is produced, you need the “client” subnet to induct the response (go through consensus a second time).

I guess the frontend could skip the response part and gust query the “server” subnet directly for the response (assuming it doesn’t need further processing / aggregation by the “client” subnet), so from the user point of view you may in certain situations be able to cut that in half (with some effort).

But if you;re looking at this from the POV of the “client” subnet, there is no way around the 2 consensus rounds.