Skip to content

G
Geth-Modification
Switch branch/tag
  1. 22 Jun, 2023 1 commit
  3. 21 Jun, 2023 2 commits
  5. 20 Jun, 2023 5 commits
  7. 19 Jun, 2023 18 commits
  9. 18 Jun, 2023 2 commits
  11. 16 Jun, 2023 2 commits
  13. 15 Jun, 2023 3 commits
  15. 14 Jun, 2023 3 commits
  17. 13 Jun, 2023 4 commits
    • Freeman Jiang's avatar
      core/types: add "chainID" field to legacy tx JSON encoding (#27452) · 8bbaf882
      Freeman Jiang authored 
      Co-authored-by: 's avatarlightclient <14004106+lightclient@users.noreply.github.com>
      8bbaf882
    • mmsqe's avatar
      rpc: add limit for batch request items and response size (#26681) · f3314bb6
      mmsqe authored 
      This PR adds server-side limits for JSON-RPC batch requests. Before this change, batches
were limited only by processing time. The server would pick calls from the batch and
answer them until the response timeout occurred, then stop processing the remaining batch
items.

Here, we are adding two additional limits which can be configured:

- the 'item limit': batches can have at most N items
- the 'response size limit': batches can contain at most X response bytes

These limits are optional in package rpc. In Geth, we set a default limit of 1000 items
and 25MB response size.

When a batch goes over the limit, an error response is returned to the client. However,
doing this correctly isn't always possible. In JSON-RPC, only method calls with a valid
`id` can be responded to. Since batches may also contain non-call messages or
notifications, the best effort thing we can do to report an error with the batch itself is
reporting the limit violation as an error for the first method call in the batch. If a batch is
too large, but contains only notifications and responses, the error will be reported with
a null `id`.

The RPC client was also changed so it can deal with errors resulting from too large
batches. An older client connected to the server code in this PR could get stuck
until the request timeout occurred when the batch is too large. **Upgrading to a version
of the RPC client containing this change is strongly recommended to avoid timeout issues.**

For some weird reason, when writing the original client implementation, @fjl worked off of
the assumption that responses could be distributed across batches arbitrarily. So for a
batch request containing requests `[A B C]`, the server could respond with `[A B C]` but
also with `[A B] [C]` or even `[A] [B] [C]` and it wouldn't make a difference to the
client.

So in the implementation of BatchCallContext, the client waited for all requests in the
batch individually. If the server didn't respond to some of the requests in the batch, the
client would eventually just time out (if a context was used).

With the addition of batch limits into the server, we anticipate that people will hit this
kind of error way more often. To handle this properly, the client now waits for a single
response batch and expects it to contain all responses to the requests.

---------
Co-authored-by: 's avatarFelix Lange <fjl@twurst.com>
Co-authored-by: 's avatarMartin Holst Swende <martin@swende.se>
      f3314bb6
    • hero5512's avatar
      internal/ethapi: remove error return on RPCMarshalBlock (#27449) · 5ac4da36
      hero5512 authored 
      rm error when marshal block to rpc type allen
      5ac4da36
    • jwasinger's avatar
      miner: log number of withdrawals in block upon payload update (#27457) · 174d267f
      jwasinger authored
      174d267f