What was the rationale for the XNet protocol? I guess my question is what is it ICP cannot do in case it did not have XNet protocol in place. It seems to be used for cross canister calls across subnets. Suppose canister in subnet A needs to invoke canister in subnet B why can’t the ICP just submit a transaction directly to one of the nodes in subnet B? Why go through the XNet protocol?
Thanks in advance.
That is already an XNet protocol 
Nitpicking aside, what it gives you is a set of guarantees that you can reliably work with. It offers pretty reliable (but not guaranteed) delivery of messages, handles authentication / TX signing, preserves message order (can be very helpful), regulates how cycles can be sent across subnets. Especially the cycles part would be impossible with directly submitting TXs to nodes.
1 Like
Thanks. How can message ordering be helpful?
There’s no one true answer. Bit of stream of consciousness on the topic:
Guaranteed message orders reduce the need for extra error handling and often can speed things up substantially. Imagine a canister requires advance payment before allowing you to call a function. As a user you can simply queue both a prepay and a do_work call and don’t have to think any further about it. No need to wait for prepay to return a response before sending off the do_work call. Other times you may want to send a chunked file and want to append chunks in the right order. If you send off the chunks in the right order they will arrive in the right order. On the receiving end your canister can define that if a call comes in before some other call then that is a error on the caller side, and doesn’t have to worry about networking delays and how to recover from that
1 Like