* ip-echo-server: Name the header length magic number
(cherry picked from commit aab5f24518)
* ip-echo-server: Add helper to compute reply length
(cherry picked from commit 7481ba5618)
* ip-echo-server: Limit socket read to expected reply length
(cherry picked from commit d2cfeb31b9)
Co-authored-by: Trent Nelson <trent@solana.com>
* Fix slow/stuck unstaking due to toggling in epoch (#13501)
* Fix slow/stuck unstaking due to toggling in epoch
* nits
* nits
* Add stake_program_v2 feature status check to cli
Co-authored-by: Tyera Eulberg <tyera@solana.com>
(cherry picked from commit 89b474e192)
* Fix conflict
* PartialEq<Vec<T>> is not impl for &[T] on rust v1.45.1
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
Co-authored-by: Tyera Eulberg <tyera@solana.com>
* Add builtin mem tests (#13429)
(cherry picked from commit 84b139cc94)
* resolve crate version
* port to v1.3 conventions
* nudge
Co-authored-by: Jack May <jack@solana.com>
* Add failing tests
* Fix stake split
* Calculate split rent-exempt-reserve and use
* Add comment in rent.rs
* Add tests for edge cases when splitting to larger accounts, and reject overflow splits
* Reframe InsufficientFunds checks in terms of lamports var
* Test hardening review comments
(cherry picked from commit 4c5f345798)
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Clarify the commitment levels based on questions
Many people have asked about what commitment levels mean, and which to
choose. This update includes some of the language at
`sdk/src/commitment_config.rs` and a recommendation for different use
cases.
Additionally, the preflight commitment documentation was out of date,
specifying that "max" was always used, and this is no longer the case.
* Update docs/src/developing/clients/jsonrpc-api.md
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Update docs/src/developing/clients/jsonrpc-api.md
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Update docs/src/developing/clients/jsonrpc-api.md
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
* Fix typo
Co-authored-by: Tyera Eulberg <teulberg@gmail.com>
(cherry picked from commit ede891a6c6)
Co-authored-by: Jon Cinque <jon.cinque@gmail.com>
* Small code cleanup and typo fixes
* Clean up calculate_points_and_credits
(cherry picked from commit 0e4509c497)
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
* implements ping-pong packets between nodes (#12794)
https://hackerone.com/reports/991106
> It’s possible to use UDP gossip protocol to amplify DDoS attacks. An attacker
> can spoof IP address in UDP packet when sending PullRequest to the node.
> There's no any validation if provided source IP address is not spoofed and
> the node can send much larger PullResponse to victim's IP. As I checked,
> PullRequest is about 290 bytes, while PullResponse is about 10 kB. It means
> that amplification is about 34x. This way an attacker can easily perform DDoS
> attack both on Solana node and third-party server.
>
> To prevent it, need for example to implement ping-pong mechanism similar as
> in Ethereum: Before accepting requests from remote client needs to validate
> his IP. Local node sends Ping packet to the remote node and it needs to reply
> with Pong packet that contains hash of matching Ping packet. Content of Ping
> packet is unpredictable. If hash from Pong packet matches, local node can
> remember IP where Ping packet was sent as correct and allow further
> communication.
>
> More info:
> https://github.com/ethereum/devp2p/blob/master/discv4.md#endpoint-proof
> https://github.com/ethereum/devp2p/blob/master/discv4.md#wire-protocol
The commit adds a PingCache, which maintains records of remote nodes
which have returned a valid response to a ping message, and on-the-fly
ping messages pending a pong response from the remote node.
When handling pull-requests, those from addresses which have not passed
the ping-pong check are filtered out, and additionally ping packets are
added for addresses which need to be (re)verified.
(cherry picked from commit ae91270961)
# Conflicts:
# Cargo.lock
# core/src/cluster_info.rs
* resolves mergify merge conflicts
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
ClusterInfo::process_packets handles incoming packets in a thread_pool:
https://github.com/solana-labs/solana/blob/87311cce7/core/src/cluster_info.rs#L2118-L2134
However, profiling runtime shows that threads are not well utilized and
a lot of the processing is done sequentially.
This commit redistributes the work done in parallel. Testing on a gce
cluster shows 20%+ improvement in processing gossip packets with much
smaller variations.
(cherry picked from commit 75d62ca095)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* passes through feature-set to down to gossip requests handling
* takes the feature-set from root_bank instead of working_bank
(cherry picked from commit 48283161c3)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
