2015-10-15 17:07:19 +03:00
|
|
|
// Copyright 2015 The go-ethereum Authors
|
|
|
|
// This file is part of the go-ethereum library.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is free software: you can redistribute it and/or modify
|
|
|
|
// it under the terms of the GNU Lesser General Public License as published by
|
|
|
|
// the Free Software Foundation, either version 3 of the License, or
|
|
|
|
// (at your option) any later version.
|
|
|
|
//
|
|
|
|
// The go-ethereum library is distributed in the hope that it will be useful,
|
|
|
|
// but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
// GNU Lesser General Public License for more details.
|
|
|
|
//
|
|
|
|
// You should have received a copy of the GNU Lesser General Public License
|
|
|
|
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
2015-12-16 11:58:01 +02:00
|
|
|
package rpc
|
2015-10-15 17:07:19 +03:00
|
|
|
|
|
|
|
import (
|
2017-03-22 20:20:33 +03:00
|
|
|
"context"
|
2019-02-04 15:47:34 +03:00
|
|
|
"io"
|
2022-11-15 16:05:16 +03:00
|
|
|
"sync"
|
2015-12-16 11:58:01 +02:00
|
|
|
"sync/atomic"
|
2015-10-15 17:07:19 +03:00
|
|
|
|
2017-02-22 15:10:07 +03:00
|
|
|
"github.com/ethereum/go-ethereum/log"
|
2015-12-16 11:58:01 +02:00
|
|
|
)
|
|
|
|
|
2017-08-08 12:08:37 +03:00
|
|
|
const MetadataApi = "rpc"
|
2022-03-07 10:30:27 +03:00
|
|
|
const EngineApi = "engine"
|
2015-10-15 17:07:19 +03:00
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// CodecOption specifies which type of messages a codec supports.
|
|
|
|
//
|
|
|
|
// Deprecated: this option is no longer honored by Server.
|
2016-03-29 16:07:40 +03:00
|
|
|
type CodecOption int
|
|
|
|
|
|
|
|
const (
|
|
|
|
// OptionMethodInvocation is an indication that the codec supports RPC method calls
|
|
|
|
OptionMethodInvocation CodecOption = 1 << iota
|
|
|
|
|
2020-05-25 11:21:28 +03:00
|
|
|
// OptionSubscriptions is an indication that the codec supports RPC notifications
|
2016-03-29 16:07:40 +03:00
|
|
|
OptionSubscriptions = 1 << iota // support pub sub
|
|
|
|
)
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// Server is an RPC server.
|
|
|
|
type Server struct {
|
|
|
|
services serviceRegistry
|
|
|
|
idgen func() ID
|
2022-11-15 16:05:16 +03:00
|
|
|
|
rpc: add limit for batch request items and response size (#26681)
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: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
mutex sync.Mutex
|
|
|
|
codecs map[ServerCodec]struct{}
|
|
|
|
run atomic.Bool
|
|
|
|
batchItemLimit int
|
|
|
|
batchResponseLimit int
|
2019-02-04 15:47:34 +03:00
|
|
|
}
|
2015-10-15 17:07:19 +03:00
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// NewServer creates a new server instance with no registered handlers.
|
|
|
|
func NewServer() *Server {
|
2022-11-15 16:05:16 +03:00
|
|
|
server := &Server{
|
|
|
|
idgen: randomIDGenerator(),
|
|
|
|
codecs: make(map[ServerCodec]struct{}),
|
|
|
|
}
|
2023-05-04 11:54:45 +03:00
|
|
|
server.run.Store(true)
|
2019-02-04 15:47:34 +03:00
|
|
|
// Register the default service providing meta information about the RPC service such
|
|
|
|
// as the services and methods it offers.
|
2015-10-15 17:07:19 +03:00
|
|
|
rpcService := &RPCService{server}
|
2016-05-11 11:49:44 +03:00
|
|
|
server.RegisterName(MetadataApi, rpcService)
|
2015-10-15 17:07:19 +03:00
|
|
|
return server
|
|
|
|
}
|
|
|
|
|
rpc: add limit for batch request items and response size (#26681)
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: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
// SetBatchLimits sets limits applied to batch requests. There are two limits: 'itemLimit'
|
|
|
|
// is the maximum number of items in a batch. 'maxResponseSize' is the maximum number of
|
|
|
|
// response bytes across all requests in a batch.
|
|
|
|
//
|
|
|
|
// This method should be called before processing any requests via ServeCodec, ServeHTTP,
|
|
|
|
// ServeListener etc.
|
|
|
|
func (s *Server) SetBatchLimits(itemLimit, maxResponseSize int) {
|
|
|
|
s.batchItemLimit = itemLimit
|
|
|
|
s.batchResponseLimit = maxResponseSize
|
|
|
|
}
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// RegisterName creates a service for the given receiver type under the given name. When no
|
|
|
|
// methods on the given receiver match the criteria to be either a RPC method or a
|
|
|
|
// subscription an error is returned. Otherwise a new service is created and added to the
|
|
|
|
// service collection this server provides to clients.
|
|
|
|
func (s *Server) RegisterName(name string, receiver interface{}) error {
|
|
|
|
return s.services.registerName(name, receiver)
|
2015-10-15 17:07:19 +03:00
|
|
|
}
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// ServeCodec reads incoming requests from codec, calls the appropriate callback and writes
|
|
|
|
// the response back using the given codec. It will block until the codec is closed or the
|
|
|
|
// server is stopped. In either case the codec is closed.
|
|
|
|
//
|
|
|
|
// Note that codec options are no longer supported.
|
|
|
|
func (s *Server) ServeCodec(codec ServerCodec, options CodecOption) {
|
2019-11-18 11:40:59 +03:00
|
|
|
defer codec.close()
|
2017-04-06 09:56:41 +03:00
|
|
|
|
2022-11-15 16:05:16 +03:00
|
|
|
if !s.trackCodec(codec) {
|
2019-02-04 15:47:34 +03:00
|
|
|
return
|
2018-07-24 03:00:55 +03:00
|
|
|
}
|
2022-11-15 16:05:16 +03:00
|
|
|
defer s.untrackCodec(codec)
|
2015-10-15 17:07:19 +03:00
|
|
|
|
rpc: add limit for batch request items and response size (#26681)
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: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
cfg := &clientConfig{
|
|
|
|
idgen: s.idgen,
|
|
|
|
batchItemLimit: s.batchItemLimit,
|
|
|
|
batchResponseLimit: s.batchResponseLimit,
|
|
|
|
}
|
|
|
|
c := initClient(codec, &s.services, cfg)
|
2019-11-18 11:40:59 +03:00
|
|
|
<-codec.closed()
|
2019-02-04 15:47:34 +03:00
|
|
|
c.Close()
|
2015-10-15 17:07:19 +03:00
|
|
|
}
|
|
|
|
|
2022-11-15 16:05:16 +03:00
|
|
|
func (s *Server) trackCodec(codec ServerCodec) bool {
|
|
|
|
s.mutex.Lock()
|
|
|
|
defer s.mutex.Unlock()
|
|
|
|
|
2023-05-04 11:54:45 +03:00
|
|
|
if !s.run.Load() {
|
2022-11-15 16:05:16 +03:00
|
|
|
return false // Don't serve if server is stopped.
|
|
|
|
}
|
|
|
|
s.codecs[codec] = struct{}{}
|
|
|
|
return true
|
|
|
|
}
|
|
|
|
|
|
|
|
func (s *Server) untrackCodec(codec ServerCodec) {
|
|
|
|
s.mutex.Lock()
|
|
|
|
defer s.mutex.Unlock()
|
|
|
|
|
|
|
|
delete(s.codecs, codec)
|
|
|
|
}
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// serveSingleRequest reads and processes a single RPC request from the given codec. This
|
|
|
|
// is used to serve HTTP connections. Subscriptions and reverse calls are not allowed in
|
|
|
|
// this mode.
|
|
|
|
func (s *Server) serveSingleRequest(ctx context.Context, codec ServerCodec) {
|
|
|
|
// Don't serve if server is stopped.
|
2023-05-04 11:54:45 +03:00
|
|
|
if !s.run.Load() {
|
2019-02-04 15:47:34 +03:00
|
|
|
return
|
2015-12-16 11:58:01 +02:00
|
|
|
}
|
|
|
|
|
rpc: add limit for batch request items and response size (#26681)
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: Felix Lange <fjl@twurst.com>
Co-authored-by: Martin Holst Swende <martin@swende.se>
2023-06-13 14:38:58 +03:00
|
|
|
h := newHandler(ctx, codec, s.idgen, &s.services, s.batchItemLimit, s.batchResponseLimit)
|
2019-02-04 15:47:34 +03:00
|
|
|
h.allowSubscribe = false
|
|
|
|
defer h.close(io.EOF, nil)
|
2015-10-15 17:07:19 +03:00
|
|
|
|
2019-11-18 11:40:59 +03:00
|
|
|
reqs, batch, err := codec.readBatch()
|
2019-02-04 15:47:34 +03:00
|
|
|
if err != nil {
|
|
|
|
if err != io.EOF {
|
2022-12-07 16:02:14 +03:00
|
|
|
resp := errorMessage(&invalidMessageError{"parse error"})
|
|
|
|
codec.writeJSON(ctx, resp, true)
|
2015-10-15 17:07:19 +03:00
|
|
|
}
|
2019-02-04 15:47:34 +03:00
|
|
|
return
|
|
|
|
}
|
|
|
|
if batch {
|
|
|
|
h.handleBatch(reqs)
|
|
|
|
} else {
|
|
|
|
h.handleMsg(reqs[0])
|
2017-03-24 14:07:12 +03:00
|
|
|
}
|
2015-10-15 17:07:19 +03:00
|
|
|
}
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// Stop stops reading new requests, waits for stopPendingRequestTimeout to allow pending
|
|
|
|
// requests to finish, then closes all codecs which will cancel pending requests and
|
|
|
|
// subscriptions.
|
2015-12-16 11:58:01 +02:00
|
|
|
func (s *Server) Stop() {
|
2022-11-15 16:05:16 +03:00
|
|
|
s.mutex.Lock()
|
|
|
|
defer s.mutex.Unlock()
|
|
|
|
|
2023-05-04 11:54:45 +03:00
|
|
|
if s.run.CompareAndSwap(true, false) {
|
2019-02-04 15:47:34 +03:00
|
|
|
log.Debug("RPC server shutting down")
|
2022-11-15 16:05:16 +03:00
|
|
|
for codec := range s.codecs {
|
|
|
|
codec.close()
|
|
|
|
}
|
2015-12-16 11:58:01 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// RPCService gives meta information about the server.
|
|
|
|
// e.g. gives information about the loaded modules.
|
|
|
|
type RPCService struct {
|
|
|
|
server *Server
|
2015-10-15 17:07:19 +03:00
|
|
|
}
|
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
// Modules returns the list of RPC services with their version number
|
|
|
|
func (s *RPCService) Modules() map[string]string {
|
|
|
|
s.server.services.mu.Lock()
|
|
|
|
defer s.server.services.mu.Unlock()
|
2015-10-15 17:07:19 +03:00
|
|
|
|
2019-02-04 15:47:34 +03:00
|
|
|
modules := make(map[string]string)
|
|
|
|
for name := range s.server.services.services {
|
|
|
|
modules[name] = "1.0"
|
2015-10-15 17:07:19 +03:00
|
|
|
}
|
2019-02-04 15:47:34 +03:00
|
|
|
return modules
|
2015-10-15 17:07:19 +03:00
|
|
|
}
|
2022-01-20 14:45:07 +03:00
|
|
|
|
|
|
|
// PeerInfo contains information about the remote end of the network connection.
|
|
|
|
//
|
|
|
|
// This is available within RPC method handlers through the context. Call
|
|
|
|
// PeerInfoFromContext to get information about the client connection related to
|
|
|
|
// the current method call.
|
|
|
|
type PeerInfo struct {
|
|
|
|
// Transport is name of the protocol used by the client.
|
|
|
|
// This can be "http", "ws" or "ipc".
|
|
|
|
Transport string
|
|
|
|
|
|
|
|
// Address of client. This will usually contain the IP address and port.
|
|
|
|
RemoteAddr string
|
|
|
|
|
2022-08-19 09:00:21 +03:00
|
|
|
// Additional information for HTTP and WebSocket connections.
|
2022-01-20 14:45:07 +03:00
|
|
|
HTTP struct {
|
|
|
|
// Protocol version, i.e. "HTTP/1.1". This is not set for WebSocket.
|
|
|
|
Version string
|
|
|
|
// Header values sent by the client.
|
|
|
|
UserAgent string
|
|
|
|
Origin string
|
|
|
|
Host string
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
type peerInfoContextKey struct{}
|
|
|
|
|
|
|
|
// PeerInfoFromContext returns information about the client's network connection.
|
|
|
|
// Use this with the context passed to RPC method handler functions.
|
|
|
|
//
|
|
|
|
// The zero value is returned if no connection info is present in ctx.
|
|
|
|
func PeerInfoFromContext(ctx context.Context) PeerInfo {
|
|
|
|
info, _ := ctx.Value(peerInfoContextKey{}).(PeerInfo)
|
|
|
|
return info
|
|
|
|
}
|