go-ethereum

Commit Graph

Author	SHA1	Message	Date
Seungbae Yu	38e002f464	rpc: check that "version" is "2.0" in request objects (#25570 ) The JSON-RPC spec requires the "version" field to be exactly "2.0", so we should verify that. This change is not backwards-compatible with sloppy client implementations, but I decided to go ahead with it anyway because the failure will be caught via the returned error.	2 years ago
Felix Lange	5883afb3ef	rpc: fix issue with null JSON-RPC messages (#21497 )	4 years ago
Felix Lange	245f3146c2	rpc: implement full bi-directional communication (#18471 ) New APIs added: client.RegisterName(namespace, service) // makes service available to server client.Notify(ctx, method, args...) // sends a notification ClientFromContext(ctx) // to get a client in handler method This is essentially a rewrite of the server-side code. JSON-RPC processing code is now the same on both server and client side. Many minor issues were fixed in the process and there is a new test suite for JSON-RPC spec compliance (and non-compliance in some cases). List of behavior changes: - Method handlers are now called with a per-request context instead of a per-connection context. The context is canceled right after the method returns. - Subscription error channels are always closed when the connection ends. There is no need to also wait on the Notifier's Closed channel to detect whether the subscription has ended. - Client now omits "params" instead of sending "params": null when there are no arguments to a call. The previous behavior was not compliant with the spec. The server still accepts "params": null. - Floating point numbers are allowed as "id". The spec doesn't allow them, but we handle request "id" as json.RawMessage and guarantee that the same number will be sent back. - Logging is improved significantly. There is now a message at DEBUG level for each RPC call served.	6 years ago

Author

SHA1

Message

Date

Seungbae Yu

38e002f464

rpc: check that "version" is "2.0" in request objects (#25570 )

The JSON-RPC spec requires the "version" field to be exactly "2.0",
so we should verify that. This change is not backwards-compatible with
sloppy client implementations, but I decided to go ahead with it anyway
because the failure will be caught via the returned error.

2 years ago

Felix Lange

5883afb3ef

rpc: fix issue with null JSON-RPC messages (#21497 )

4 years ago

Felix Lange

245f3146c2

rpc: implement full bi-directional communication (#18471 )

New APIs added:

    client.RegisterName(namespace, service) // makes service available to server
    client.Notify(ctx, method, args...)     // sends a notification
    ClientFromContext(ctx)                  // to get a client in handler method

This is essentially a rewrite of the server-side code. JSON-RPC
processing code is now the same on both server and client side. Many
minor issues were fixed in the process and there is a new test suite for
JSON-RPC spec compliance (and non-compliance in some cases).

List of behavior changes:

- Method handlers are now called with a per-request context instead of a
  per-connection context. The context is canceled right after the method
  returns.
- Subscription error channels are always closed when the connection
  ends. There is no need to also wait on the Notifier's Closed channel
  to detect whether the subscription has ended.
- Client now omits "params" instead of sending "params": null when there
  are no arguments to a call. The previous behavior was not compliant
  with the spec. The server still accepts "params": null.
- Floating point numbers are allowed as "id". The spec doesn't allow
  them, but we handle request "id" as json.RawMessage and guarantee that
  the same number will be sent back.
- Logging is improved significantly. There is now a message at DEBUG
  level for each RPC call served.

6 years ago

3 Commits (8363f79f8fd735d6264e7549e7f861467fbf6c78)