Geth v1.4 and later support publish / subscribe using JSON-RPC notifications. This allows
clients to wait for events instead of polling for them.
Geth v1.4 and later support publish / subscribe using JSON-RPC notifications. This allows clients to wait for events instead of polling for them.
It works by subscribing to particular events. The node will return a subscription id. For
each event that matches the subscription a notification with relevant data is send
together with the subscription id.
It works by subscribing to particular events. The node will return a subscription id. For each event that matches the subscription a notification with relevant data is send together with the subscription id.
1. notifications are sent for current events and not for past events. If your use case
requires you not to miss any notifications then subscriptions are probably not the best
option.
2. subscriptions require a full duplex connection. Geth offers such connections in the
form of WebSocket and IPC (enabled by default).
3. subscriptions are coupled to a connection. If the connection is closed all
subscriptions that are created over this connection are removed.
4. notifications are stored in an internal buffer and sent from this buffer to the client.
If the client is unable to keep up and the number of buffered notifications reaches a
limit (currently 10k) the connection is closed. Keep in mind that subscribing to some
events can cause a flood of notifications, e.g. listening for all logs/blocks when the
node starts to synchronize.
1. Notifications are sent for current events and not for past events. For use cases that depend on not to miss any notifications subscriptions are probably not the best option.
2. Subscriptions require a full duplex connection. Geth offers such connections in the form of WebSocket and IPC (enabled by default).
3. Subscriptions are coupled to a connection. If the connection is closed all subscriptions that are created over this connection are removed.
4. Notifications are stored in an internal buffer and sent from this buffer to the client. If the client is unable to keep up and the number of buffered notifications reaches a limit (currently 10k) the connection is closed. Keep in mind that subscribing to some events can cause a flood of notifications, e.g. listening for all logs/blocks when the node starts to synchronize.
## Create subscription
Subscriptions are created with a regular RPC call with `eth_subscribe` as method and the
subscription name as first parameter. If successful it returns the subscription id.
Subscriptions are created with a regular RPC call with `eth_subscribe` as method and the subscription name as first parameter. If successful it returns the subscription id.
Clef listens to HTTP requests on `http.addr`:`http.port` (or to IPC on `ipcpath`), with the same JSON-RPC standard as Geth. The messages are expected to be [JSON-RPC 2.0 standard](https://www.jsonrpc.org/specification).
Some of these calls can require user interaction. Clients must be aware that responses may be delayed significantly or may never be received if a user decides to ignore the confirmation request.
Some of these calls can require user interaction in the Clef terminal. Responses may be delayed significantly or may never be received if a user decides to ignore the confirmation request.
The External API is **untrusted**: it does not accept credentials, nor does it expect that requests have any authority.
@ -41,6 +41,7 @@ See the [external API changelog](https://github.com/ethereum/go-ethereum/blob/ma