Improve transport-settlement handshake.

[evanlinjin]

Depends on PR:#252

Description

We should depend on transport-discovery to settle transports, otherwise it may lead to some ambiguity. The following changes depend on deterministic Transport IDs (implemented within PR:#252).

The transport-settlement handshake SHOULD look as follows:

Legend
TpDisc - Transport Discovery.
Init-er - Transport Initiating Node.
Resp-er - Transport Responder Node.
E - Transport Entry.
S - Signature.
TpID - Transport ID.
Wait(<v>) - Repetitively query until the resource is obtained.

The current implementation of the transport-settlement handshake works very similarly to the aforementioned. The only differences include:

• The Resp-er replies with E+2S (Entry with two signatures) instead of TpID (Transport-ID).
• The Resp-er does not wait for the TpDisc to have the entry submitted.

Further Notes

For the implementation, ensure that:

• Only NEWLY-CREATED transports should go through the settlement-handshake. Always check the Transport Discovery whether the transport already has an entry. Both edges of the settlement-handshake should check this.
  • The Initiator should check with the Transport Discovery whether a settlement-handshake is needed.
  • The Responder should check the Transport Discovery whenever they Factory.Accept() a transport, if a settlement-handshake is required.

Tasks

• Make the aforementioned changes.
• Update tests.
• Update Skywire Specifications.

[jdknives]

@evanlinjin this should simplify the transport establishment. However, if the tpID is deterministic, then why would Resp-er even respond with the tpID? Would that not just increase the number of messages?

[evanlinjin]

@jdknives

1. We need a way for Responder to inform Initiator that it accepts the request.
2. Given the assumption that Responder will always agree to establish the transport, the alternate solution would be to have Initiator repetitively poll tpDisc as it awaits the confirmation of the Entry being submitted. Or have Initiator request tpDisc with a timeout, and the tpDisc keeps the connection with Initiator open until the Entry is submitted by Responder. I am not a fan of either of these solutions as it adds more logic and complexity than what I have suggested.