Add DropReason and DropPeer structs to pass reason string to logs about Dropping a Neighbor

[jferrant]

Closes #5714

[jcnelson]

I like this approach overall. I think it may be worth consolidating DropPeer and DropNeigbor into a struct that only includes a PeerAddress and a DropReason (instead of a bare event_id or a full NeighborKey). I think at each call site where you derive a DropReason, you at least have the means of getting the PeerAddress.

Can this PR also implement a better formatter for PeerAddress, if that's what you end up using? Ideally it'd print the IPv4 or IPv6 address instead of the raw 16 byte address.

[jferrant]

I like this approach overall. I think it may be worth consolidating DropPeer and DropNeigbor into a struct that only includes a PeerAddress and a DropReason (instead of a bare event_id or a full NeighborKey). I think at each call site where you derive a DropReason, you at least have the means of getting the PeerAddress.

Can this PR also implement a better formatter for PeerAddress, if that's what you end up using? Ideally it'd print the IPv4 or IPv6 address instead of the raw 16 byte address.

Can do! EDIT: just a quick question, does this mean the event_id is not really relevant for matching on a neighbor key? just the neighbor_key.addrbytes, i.e. PeerAddress? Specifically...can multiple neighbor_keys with the same peer_address (even if sep port) match to the same event_id... Cause then it might not be so straightforward cause deregister_peer highly relies on event_id.

For example I see this in deregister_peer which makes me think that there are multiple matching neighbor keys per event id...

        let mut nk_remove: Vec<(NeighborKey, Hash160)> = vec![];
        for (neighbor_key, ev_id) in self.events.iter() {
            if event_id == ev_id {
                let pubkh = self
                    .get_p2p_convo(event_id)
                    .and_then(|convo| convo.get_public_key_hash())
                    .unwrap_or(Hash160([0x00; 20]));
                nk_remove.push((neighbor_key.clone(), pubkh, event_id));
            }
        }

[jcnelson]

Can do! EDIT: just a quick question, does this mean the event_id is not really relevant for matching on a neighbor key? just the neighbor_key.addrbytes, i.e. PeerAddress? Specifically...can multiple neighbor_keys with the same peer_address (even if sep port) match to the same event_id... Cause then it might not be so straightforward cause deregister_peer highly relies on event_id.

event_id is an opaque handle to the socket connected to the neighbor, which is used by mio to indicate which sockets are ready for read or write. It's not logged at the info level, so logging it for add/drop peers doesn't help us identify the peer being added/dropped.

The system won't register a new socket to a peer that already has a socket open, so there won't be multiple peer_addresses with the same event_id. The code in deregister_peer is defensively written; the local nk_remove list that gets built up in the function body should only ever have at most one element. You could get the NeighorKey for the given the event_id from the nk_remove list.

[jferrant]

Can do! EDIT: just a quick question, does this mean the event_id is not really relevant for matching on a neighbor key? just the neighbor_key.addrbytes, i.e. PeerAddress? Specifically...can multiple neighbor_keys with the same peer_address (even if sep port) match to the same event_id... Cause then it might not be so straightforward cause deregister_peer highly relies on event_id.

event_id is an opaque handle to the socket connected to the neighbor, which is used by mio to indicate which sockets are ready for read or write. It's not logged at the info level, so logging it for add/drop peers doesn't help us identify the peer being added/dropped.

The system won't register a new socket to a peer that already has a socket open, so there won't be multiple peer_addresses with the same event_id. The code in deregister_peer is defensively written; the local nk_remove list that gets built up in the function body should only ever have at most one element. You could get the NeighorKey for the given the event_id from the nk_remove list.

Perfect! This was my only concern I think. so I should be able ot make this work.

[jcnelson]

A couple things you could add here, potentially:

• could you log from what subsystem the peer was dropped by?
• it might be worthwhile to only log peers' acceptance after they've completed a handshake, since we often get peers that connect but never authenticate (e.g. because they're on a different network).

[jferrant]

@jcnelson I tried to combine DropPeer and DropNeighbor but I had a really hard time replacing it in much of the code base as the neighbor key is used to deregister and ban neighbors and it seems like a LOT of the code is based on the nieghbor key itself, not just the PeerAddress. I don't mind trying to refactor this code, but it will be substantial and I am worried that we might introduce bugs as the PeerAddress would ignore ports whereas NeighborKey would not.

Also, when you say "only log peers' acceptance after they've completed a handshake", do you mean maybe remove the "Neighbor accepted log" since we already have a debug log:

        debug!(
            "{:?}: Registered {} as event {} ({:?},outbound={})",
            &self.local_peer, &client_addr, event_id, &neighbor_key, outbound
        );

And then attempt to add an info level log in handle_handshake_accept and handle_handshake in chat.rs? I don't think I could gaurantee that we won't log a "dropping neighbor" for an unauthenticated neighbor though. Would need to include a bool in the DropNeighbor/DropPeer structs to prevent printing it when it as an unauthenticated connection.

[jcnelson]

This LGTM; just had one minor comment.

[obycode]

I think this looks good, just two minor comments.

[obycode]

Suggested change

	- Imrpovements to how a PeerAddress is logged (human readable format vs hex)
	- Improvements to how a PeerAddress is logged (human readable format vs hex)

[obycode]

Looks like this result is intentionally ignored. @jcnelson can you confirm?

[jcnelson]

Yes; this was written in a time when I was a lot less idiomatic in my Rust code and when we didn't really prioritize conforming to it.