Investigate error - Message: multiple tcp connections created in a `MultiAddr`

[mrinalwadhwa]

Investigate why the second route doesn't work:

curl --proto '=https' --tlsv1.2 -sSfL https://install.command.ockam.io | bash
ockam reset --yes

ockam identity create a
ockam node create a --identity a --tcp-listener-address 127.0.0.1:5551

ockam identity create hop
ockam node create hop --identity hop --tcp-listener-address 127.0.0.1:5552
ockam tcp-connection create --from hop --to 127.0.0.1:5551

ockam identity create b
ockam node create b --identity b --tcp-listener-address 127.0.0.1:5553

ockam secure-channel-listener create a --at a --identity a --authorized $(ockam identity show b)

ockam secure-channel create --from b --identity b \
  --to /ip4/127.0.0.1/tcp/5551/service/a --authorized $(ockam identity show a) |
    ockam message send hello --from b --to -/service/uppercase

ockam secure-channel create --from b --identity b \
  --to /ip4/127.0.0.1/tcp/5552/ip4/127.0.0.1/tcp/5551/service/a --authorized $(ockam identity show a) |
    ockam message send hello --from b --to -/service/uppercase

OCK500

  x An error occurred while processing the request. Status code: 500 InternalServerError. Message: multiple tcp connections created in a `MultiAddr` (origin: Transport, kind: Unsupported, source
  | location: implementations/rust/ockam/ockam_api/src/nodes/connection/mod.rs:228:40) (origin: Api, kind: Serialization, source location: /Users/runner/work/ockam/ockam/implementations/rust/ockam/
  | ockam_core/src/api.rs:166:17)
  help: Please report this issue, with a copy of your logs, to https://github.com/build-trust/ockam/issues

  Version 0.91.0, hash: 9f2db0ed251232946489097230ee60cd9e746cb0

HELLO

---

We love helping new contributors! ❤️ If you have questions or need help as you explore, please join us on Discord. If you're looking for other issues to contribute to, please checkout our good first issues.

[SanjoDeundiak]

@mrinalwadhwa Have we ever supported such a use case? The MultiAddr resolution ends at node b. During that resolution, node b can't create a TCP connection from node hop to node a. So, how do you think node b should treat that part of the MultiAddr?

[etorreborre]

On my side, I would question hops from another angle. When you create a hop on a node and you allow a message to choose where to go after the hop you implicitly couple the knowledge of the network topology to the node sending the message.

I am not a networking protocol expert but it seems to me that it is contrary to encapsulation principles. In general a message should give its final destination at a high-level without having to know about the actual topology. Then that routing should be translated to concrete addresses of concrete machines as an implementation detail. Kind of what is presented in this video. Are there existing protocols where hops are actually part of the high-level route of a message?

[SanjoDeundiak]

@etorreborre that is easily achievable with the current implementation. If you instantiate the topology first, you can give it an alias and use it, which hides the implementation/topology details from the user

[etorreborre]

@SanjoDeundiak yes. My question is: shouldn't this be the preferred way to do this sort of things?

[SanjoDeundiak]

@etorreborre Secure Channels already kind of do this. We always have an open possibility to use this approach even more if we decide to, for now I don't see strong reasons to do it