Skip to content
New issue

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

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

Already on GitHub? # to your account

Algorithm for concurrent connection resolution #182

Closed
whyrusleeping opened this issue Oct 17, 2014 · 4 comments
Closed

Algorithm for concurrent connection resolution #182

whyrusleeping opened this issue Oct 17, 2014 · 4 comments
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) kind/support A question or request for support

Comments

@whyrusleeping
Copy link
Member

issue #174 is (probably) a result of two nodes connecting to eachother at the same time. I have also created a test case where two nodes attempt connections to eachother at the same time which hangs and times out. We need to discuss what to do in such a scenario.

@whyrusleeping whyrusleeping added kind/bug A bug in existing code (including security flaws) help wanted Seeking public contribution on this issue kind/support A question or request for support labels Oct 17, 2014
@jbenet
Copy link
Member

jbenet commented Oct 17, 2014

Oh i'm already fixing this. I've it 80% of the way there. Works like this:

  • added Conn interface
  • Conn struct -> singleConn, implements Conn
  • PeerConn implements Conn, has map[multiaddr string]Conn (*singleConn) objects
  • PeerConn routes traffic to whatever child conn it makes sense to (i.e. always one)
  • PeerConn times out child conns after a period of idleness
  • Swarm has map[peerID]Conn (*PeerConn)
  • Swarm uses a conn.Listener and adds singleConns to PeerConn

@whyrusleeping
Copy link
Member Author

What if A and B are doubly connected and each pick the other connection? I guess traffic would still make it to each peer properly, but one connection wouldnt time out

@whyrusleeping
Copy link
Member Author

I guess, how does a peer decide which connection "makes sense"?

@jbenet
Copy link
Member

jbenet commented Oct 17, 2014

For now, we can select deterministically by ordering the addresses.

Later, we can measure latency and stuff!

@aschmahmann aschmahmann mentioned this issue May 14, 2021
71 tasks
ariescodescream pushed a commit to ariescodescream/go-ipfs that referenced this issue Oct 23, 2021
buffer writes when sending protobufs
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) kind/support A question or request for support
Projects
None yet
Development

No branches or pull requests

2 participants