Documentation needed on network.inbound and network.outbound

[SmartLayer]

The documents such as web3py and web3js didn't explain what network.inbound and network.outbound means.

There are two plausible explanation.

1. For a peer, network.inbound means that the peer accepts inbound connection.
2. For a peer, network.inbound means that peer is connected to the current node through a inbound connection.

I'm not sure about you but I feel that two intuitions have equal chance of being true, so we can't pass it as a case of "self-explanatory - no document needed".

I experimented† with both cases and found that 2 is the correct answer. But for someone who look at peers and wonders how many of them are 'selfish' (not accepting incoming connections or behind NAT firewall), looking at how many have nework.inbound == true seem to be the most intuitive way to go - they would be in for a surprise.

†How I experimented

Example of both true and false are found in the following screen transcript:

> admin.peers
…
 {
    caps: ["eth/62", "eth/63"],
    enode: "enode://1855ff4c8d07db6c311f2940493739fd14d5d47b9e52f0e4161a4efef631a1dd4017d18efdf915373fb16e3182d4b1df212fab95c29d23bea2bfcdf22f8ffb57@46.105.78.246:46360",
    id: "ff476e8a4664654dc9d415dffda42a640c75aa305c3c4d53d4fac4e15ad90a81",
    name: "ethereumjs-devp2p/v2.5.1/linux-x64/nodejs",
    network: {
      inbound: true,
      localAddress: "192.168.47.109:30303",
      remoteAddress: "46.105.78.246:46360",
      static: false,
      trusted: false
    },
    protocols: {
      eth: {
        difficulty: 17179869184,
        head: "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3",
        version: 63
      }
    }
}, {
    caps: ["eth/63", "eth/64", "eth/65"],
    enode: "enode://dc79daf8d1b085f32279bfff419eb884a234b55927c577e26f692a5c68c59cf7359e83a62e79ab9f9b0dcbc703c9b5fc8afd666feec165a70385a01a78c075be@173.249.6.189:30301",
    id: "ff9a9ea0f4d5019497211cf6b98c98c86adc290d54f4475cb06725e5bba57e85",
    name: "Geth/v1.9.24-stable-cc05b050/linux-amd64/go1.15.5",
    network: {
      inbound: false,
      localAddress: "192.168.47.109:51182",
      remoteAddress: "173.249.6.189:30301",
      static: true,
      trusted: false
    },
    protocols: {
      eth: {
        difficulty: 1.9054455443752023e+22,
        head: "0x4aa4ac671dcd5a04179a8382e39453972382fb317a184d9ccd86ffa561f1cb3f",
        version: 65
      }
    }
}]

Given my node listens to "192.168.47.109:30303", the first peer should be connected through an inbound tcp connection and the second should be connected through an outbound tcp connection. Then we have the first with network.inboud: true and the second false, hence I conclude network.inboud is a property of the connection to the peer, not a property of the peer.

[karalabe]

Your explanation is correct. The flag means whether the connection with the peer is inbound (dialed remotely) or outbound (dialed locally). I don't think there's much more we can do.

[SmartLayer]

Your explanation is correct. The flag means whether the connection with the peer is inbound (dialed remotely) or outbound (dialed locally). I don't think there's much more we can do.

Is this not the correct repo to file an issue aginst documentation? The title said what is actionable - add mentioning of what you just said - "The flag means whether the connection with the peer is inbound (dialed remotely) or outbound (dialed locally). " - into the document.

[Jolly23]

@colourful-land @karalabe Thanks for your explain. Thus, can we make a conclusion that peer with inbound=false never contribute informations(head, tx, etc) to my node? They only acquire message from me, is this true?
do they never help me to propaganda my local transaction?

I am going to make a script to remove those kind of peer.

[karalabe]

No, that's not true. That's just the direction of the connection. Every peer is P2P and communication and information sharing goes both ways.

[Jolly23]

@karalabe Thanks!
I am going to build a script to find and remove "BAD" peer.
list all peers' information by admin.peers and then check their ['protocols']['eth']['head']. See how many blocks they behind from the highest block. If someone lags more than 20 block, remove it.

Is this a good criterion? Do you have any suggestion about this script?

Btw, I notice some peer does not provide ['protocols']['eth']['head'], show ['protocols']['eth']: 'handshake' instead.
What does this mean? Can I remove them too?

[holiman]

Your explanation is correct.

Question answered, closing