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

Shift seen_addresses to store a SocketAddr #1764

Closed
AgeManning opened this issue Oct 13, 2020 · 1 comment
Closed

Shift seen_addresses to store a SocketAddr #1764

AgeManning opened this issue Oct 13, 2020 · 1 comment
Assignees

Comments

@AgeManning
Copy link
Member

Description

Currently we keep track of the IpAddr of connected peers. The new API endpoint wants addresses for each peer in a multiaddr form. Although we can use the ENR, sometimes this will be out of date and sometimes non-existent.

The best source of truth is to use the address that we see the peer connect to us on. That is what seen_address stores. However it currently only stores the IP address. If we also store the port, then we can construct a more valid multiaddr for the HTTP API.

In essence we need to update the seen_address field in the PeerInfo struct to store SocketAddrs.

bors bot pushed a commit that referenced this issue Oct 22, 2020
## Issue Addressed

`node` endpoints in #1434

## Proposed Changes

Implement these:
```
 /eth/v1/node/health
 /eth/v1/node/peers/{peer_id}
 /eth/v1/node/peers
```
- Add an `Option<Enr>` to `PeerInfo`
- Finish implementation of `/eth/v1/node/identity`

## Additional Info
- should update the `peers` endpoints when #1764 is resolved



Co-authored-by: realbigsean <[email protected]>
@divagant-martian divagant-martian self-assigned this Oct 26, 2020
@paulhauner paulhauner added A1 and removed A1 labels Nov 8, 2020
bors bot pushed a commit that referenced this issue Nov 9, 2020
@AgeManning
Copy link
Member Author

Resolved in #1841

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants