Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address agnostic p2p #5117

Closed
mversic opened this issue Oct 3, 2024 · 5 comments · Fixed by #5176
Closed

Address agnostic p2p #5117

mversic opened this issue Oct 3, 2024 · 5 comments · Fixed by #5176
Assignees
Labels
Enhancement New feature or request

Comments

@mversic
Copy link
Contributor

mversic commented Oct 3, 2024

We uniquely identify peers only by public key. However, p2p still requires to know exact address of peers. What we would like to do is that network keeps working even if a peer changes it's address. I think we should do periodic address gossiping to make this work.

Related #4249 #1375

@mversic mversic added the Enhancement New feature or request label Oct 3, 2024
@mversic mversic added this to Iroha Oct 3, 2024
@mversic mversic moved this to Work in Progress in Iroha Oct 7, 2024
@dima74
Copy link
Contributor

dima74 commented Oct 15, 2024

How things currently work:

  • Topology of the peers (public keys and addresses) are stored on-chain.
  • There are (Un)RegisterPeer instructions for changing topology.
  • Initial topology is provided in the genesis block (via RegisterPeer instructions)
  • In case genesis block is not provided to the peer, there is sumeragi.trusted_peers config parameter with addresses of initial peers

Planned changes:

  • Peer addresses will not be stored on-chain (removed from topology)
  • Each peer will store current peer addresses off-chain and do periodic gossiping
  • Peer A will accept connection from peer B if peer B public key is in topology
  • Peer external port will be added to the config.
    • External port will be sent when connecting to other peers - so that other peers will know our peer's full address and can broadcast this address to other peers (more details in "Use case: New peer added")
    • Note that peer internal port is already in config - network.address
    • External port can be different from internal port e.g. in case when peer is in docker or behind nginx

Use case: Peer changes address

  • Initially there are three peers: A, B, C
  • C changes its address
  • C knows addresses of other peers and tries to establish connection with them
  • Other peers accept connection because C public key is in topology

Use case: New peer added

  • Initially there are peers A and B with addresses iroha1:8000 and iroha2:8000
  • We want to add peer C with address iroha3:8000
  • First, we invoke RegisterPeer instruction to add C public key to topology
  • Then peer C is started with the following config:
    • sumeragi.trusted_peers - only peer A
    • network.external_port - 8000
  • C tries to connect to A
    • A receives connection from iroha3:52143 (52143 is some random port chosen by C for outcoming connection)
    • A accepts such connection because C public key is in topology
    • C sends its external port (8000) to A
    • A now knows full address of C - iroha3:8000
    • A gossip address of C to B
    • B receives address of C and connects to C

@mversic
Copy link
Contributor Author

mversic commented Oct 16, 2024

Note that peer internal port is already in config - torii.address

Do we still need this in the config?

@mversic
Copy link
Contributor Author

mversic commented Oct 16, 2024

when registering a peer should the register instruction include initial peer address? So that network can also try to reach the new peer. What do you think about that?

@dima74
Copy link
Contributor

dima74 commented Oct 16, 2024

Note that peer internal port is already in config - torii.address

Do we still need this in the config?

Yes, internal port is needed to listen incoming connections on that port

when registering a peer should the register instruction include initial peer address? So that network can also try to reach the new peer. What do you think about that?

Do you mean to also store initial peer address on chain?

@mversic
Copy link
Contributor Author

mversic commented Oct 16, 2024

Do you mean to also store initial peer address on chain?

no, I just meant when registering. I wouldn't though even when registering

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants