Skip to content
This repository has been archived by the owner on May 26, 2022. It is now read-only.

Review by kuba #1

Closed
Stebalien opened this issue Mar 13, 2018 · 9 comments
Closed

Review by kuba #1

Stebalien opened this issue Mar 13, 2018 · 9 comments
Assignees

Comments

@Stebalien
Copy link
Member

No description provided.

@Kubuxu
Copy link
Member

Kubuxu commented Mar 27, 2018

I would rename this variable: https://github.com/libp2p/go-reuseport-transport/blob/master/reuseport.go#L59 it was a bit confusing at first.

Shouldn't we use global in this case? https://github.com/libp2p/go-reuseport-transport/blob/master/multidialer.go#L43-L47

@Kubuxu
Copy link
Member

Kubuxu commented Mar 27, 2018

We might want to catch: EHOSTUNREACH and redial using a different address.

@Stebalien
Copy link
Member Author

We might want to catch: EHOSTUNREACH and redial using a different address.

Different source or target? We always use the unspecified IP address for the source (this library just picks the source port). It's up to the transport to try multiple target addresses.

@Kubuxu
Copy link
Member

Kubuxu commented Mar 27, 2018

In case of a local network, we use a random address for Dial afaik.

@Stebalien
Copy link
Member Author

We pick a random source port from the set of reasonable source ports but we never manually specify the source address.

Note: The swarm no longer specifies source addresses when dialing. I moved that logic into the transport because the swarm doesn't really know enough to do so intelligently.

Really, the correct way to implement this library would be to:

  1. Ask the kernel, if I dial IP X, which source address will I use.
  2. Try a random port out of all the ports we have open on that source address.

Unfortunately, the "ask the kernel" part involves using netlink. We could do this (e.g., with the netlink package) but that adds some complexity (and I'd like to do it later, if ever).

@Stebalien
Copy link
Member Author

Stebalien commented Mar 27, 2018

Shouldn't we use global in this case? https://github.com/libp2p/go-reuseport-transport/blob/master/multidialer.go#L43-L47

No, but that needs a comment. Basically, we always prefer using the unspecified address over the global address because we don't actually know if the global address can dial the target. The logic is:

  1. If we're dialing loopback, choose a source-port in order of preference:
    1. A port in-use by an explicit loopback listener.
    2. A port in-use by a listener on an unspecified address (must also be listening on localhost).
    3. A port in-use by a listener on a global address. We don't have any other better options (other than picking a random port).
  2. If we're dialing a global address, choose a source-port in order of preference:
    1. A port in-use by a listener on an unspecified address (the most general case).
    2. A port in-use by a listener on the global address.
  3. Fail on link-local dials (go-ipfs currently forbids this and I figured we could try lifting this restriction later).

Stebalien added a commit that referenced this issue Mar 27, 2018
@Stebalien
Copy link
Member Author

Changes: 73d48b5...f431c22

@Stebalien
Copy link
Member Author

@Kubuxu when you get a chance, final review?

@Kubuxu
Copy link
Member

Kubuxu commented Mar 29, 2018

SGWM

@Kubuxu Kubuxu closed this as completed Mar 29, 2018
marten-seemann pushed a commit to libp2p/go-libp2p that referenced this issue Apr 26, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants