Skip to content

Conversation

@algorandskiy
Copy link
Contributor

Summary

  1. Do not run ERL in p2pNet tx handler - libp2p has own congestion control mechanism, plus we are using pubsub.
  2. Log dht.Close() errors if any.

Test Plan

Existing tests

@algorandskiy algorandskiy added Skip-Release-Notes p2p Work related to the p2p project labels Jun 25, 2024
@algorandskiy algorandskiy requested review from cce and gmalouf June 25, 2024 23:42
@algorandskiy algorandskiy self-assigned this Jun 25, 2024
@codecov
Copy link

codecov bot commented Jun 26, 2024

Codecov Report

Attention: Patch coverage is 30.76923% with 9 lines in your changes missing coverage. Please review.

Project coverage is 56.09%. Comparing base (d3114e8) to head (26d8426).
Report is 93 commits behind head on feature/p2p.

Current head 26d8426 differs from pull request most recent head dc2c885

Please upload reports for the commit dc2c885 to get more accurate results.

Files Patch % Lines
data/txHandler.go 0.00% 7 Missing ⚠️
network/p2pNetwork.go 33.33% 1 Missing and 1 partial ⚠️
Additional details and impacted files
@@               Coverage Diff               @@
##           feature/p2p    #6040      +/-   ##
===============================================
+ Coverage        55.95%   56.09%   +0.14%     
===============================================
  Files              482      488       +6     
  Lines            68287    69544    +1257     
===============================================
+ Hits             38213    39014     +801     
- Misses           27473    27858     +385     
- Partials          2601     2672      +71     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

// this TX message was found in the duplicate cache, or ERL rate-limited it
return network.ValidatedMessage{Action: network.Ignore, ValidatedMessage: nil}
// note, this is the same check as in incomingMsgDupErlCheck prologue
// but for p2p network handlers no ERL needed because libp2p has own congestion control
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe we could split incomingMsgDupErlCheck into dupCheck and erlCheck? the two halves don't have any relation to each other AFAICT

Copy link
Contributor Author

Choose a reason for hiding this comment

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

IMO it does not make much sense - a new function would be a single call inside two if-conds by cost of adding extra lines in caller to check return codes.

the two halves don't have any relation to each other AFAICT

they do (both signal if a messages should be rejected with the same code) and they don't since use different message traits to decide on.

Copy link
Contributor

Choose a reason for hiding this comment

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

Semi-orthogonal, do we understand the rate limiting behavior of libp2p vs our own implementation? It's reasonable to want to use that, but we should at least understand how they each perform relative to one another no?

@algorandskiy
Copy link
Contributor Author

Fix for the logging failure is in #6035

@algorandskiy algorandskiy merged commit a6248b2 into algorand:feature/p2p Jun 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

p2p Work related to the p2p project Skip-Release-Notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants