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

eth: handler BlockHeadersMsg if statement is always true #14848

Closed
wants to merge 1 commit into from

Conversation

sorpaas
Copy link
Contributor

@sorpaas sorpaas commented Jul 22, 2017

This statement len(headers) > 0 || !filter is just always true and sometimes can be confusing.

  • when len(headers) == 0: !filter is true.
  • when len(headers) == 1: len(headers) > 0 is true.
  • when len(headers) > 1: len(headers) > 0 is true.

@GitCop
Copy link

GitCop commented Jul 22, 2017

Thank you for your contribution! Your commits seem to not adhere to the repository coding standards

  • Commit: e96a6c588c388c9952c903dca2d048f5f61020c6
  • Your commit message body contains a line that is longer than 80 characters

Please check the contribution guidelines for more details.


This message was auto-generated by https://gitcop.com

This statement `len(headers) > 0 || !filter` is just always true and
sometimes can be confusing.

- when `len(headers) == 0`: `!filter` is true.
- when `len(headers) == 1`: `len(headers) > 0` is true.
- when `len(headers) > 1`: `len(headers) > 0` is true.
@@ -444,11 +444,9 @@ func (pm *ProtocolManager) handleMsg(p *peer) error {
// Irrelevant of the fork checks, send the header to the fetcher just in case
headers = pm.fetcher.FilterHeaders(headers, time.Now())
}
if len(headers) > 0 || !filter {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, this is not always true, because headers is changed 2 lines above, and len(headers) becomes 0, while filter was true (hence !filter false).

Copy link
Member

@karalabe karalabe Jul 26, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is explicitly how the fetcher works, it keeps anything sent to it, and forwards the rest to the downloader. If the fetcher kept the header delivered, and forwards an empty slice to the downloader, the downloader will abort the sync thinking the peer doesn't have any more headers available.

Copy link
Member

@karalabe karalabe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, this change breaks sync.

@karalabe karalabe closed this Jul 26, 2017
sorpaas added a commit to ethereumproject/go-ethereum that referenced this pull request Jul 26, 2017
…not necessarily always true

See ethereum/go-ethereum#14848 for an explanation of why the line `len(headers) > 0 || !filter` is added back.

I still don't think we should check total difficulty of the peer with the fork header like ETH does. It might break light clients that only keep the last 256 blocks and does not prevent network attacks. See #313 for an explanation.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants