You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

68 lines
1.8 KiB

7 years ago
7 years ago
7 years ago
rpc/lib/client & server: try to conform to JSON-RPC 2.0 spec (#4141) https://www.jsonrpc.org/specification What is done in this PR: JSONRPCClient: validate that Response.ID matches Request.ID I wanted to do the same for the WSClient, but since we're sending events as responses, not notifications, checking IDs would require storing them in memory indefinitely (and we won't be able to remove them upon client unsubscribing because ID is different then). Request.ID is now optional. Notification is a Request without an ID. Previously "" or 0 were considered as notifications Remove #event suffix from ID from an event response (partially fixes #2949) ID must be either string, int or null AND must be equal to request's ID. Now, because we've implemented events as responses, WS clients are tripping when they see Response.ID("0#event") != Request.ID("0"). Implementing events as requests would require a lot of time (~ 2 days to completely rewrite WS client and server) generate unique ID for each request switch to integer IDs instead of "json-client-XYZ" id=0 method=/subscribe id=0 result=... id=1 method=/abci_query id=1 result=... > send events (resulting from /subscribe) as requests+notifications (not responses) this will require a lot of work. probably not worth it * rpc: generate an unique ID for each request in conformance with JSON-RPC spec * WSClient: check for unsolicited responses * fix golangci warnings * save commit * fix errors * remove ID from responses from subscribe Refs #2949 * clients are safe for concurrent access * tm-bench: switch to int ID * fixes after my own review * comment out sentIDs in WSClient see commit body for the reason * remove body.Close it will be closed automatically * stop ws connection outside of write/read routines also, use t.Rate in tm-bench indexer when calculating ID fix gocritic issues * update swagger.yaml * Apply suggestions from code review * fix stylecheck and golint linter warnings * update changelog * update changelog2
5 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
rpc/lib/client & server: try to conform to JSON-RPC 2.0 spec (#4141) https://www.jsonrpc.org/specification What is done in this PR: JSONRPCClient: validate that Response.ID matches Request.ID I wanted to do the same for the WSClient, but since we're sending events as responses, not notifications, checking IDs would require storing them in memory indefinitely (and we won't be able to remove them upon client unsubscribing because ID is different then). Request.ID is now optional. Notification is a Request without an ID. Previously "" or 0 were considered as notifications Remove #event suffix from ID from an event response (partially fixes #2949) ID must be either string, int or null AND must be equal to request's ID. Now, because we've implemented events as responses, WS clients are tripping when they see Response.ID("0#event") != Request.ID("0"). Implementing events as requests would require a lot of time (~ 2 days to completely rewrite WS client and server) generate unique ID for each request switch to integer IDs instead of "json-client-XYZ" id=0 method=/subscribe id=0 result=... id=1 method=/abci_query id=1 result=... > send events (resulting from /subscribe) as requests+notifications (not responses) this will require a lot of work. probably not worth it * rpc: generate an unique ID for each request in conformance with JSON-RPC spec * WSClient: check for unsolicited responses * fix golangci warnings * save commit * fix errors * remove ID from responses from subscribe Refs #2949 * clients are safe for concurrent access * tm-bench: switch to int ID * fixes after my own review * comment out sentIDs in WSClient see commit body for the reason * remove body.Close it will be closed automatically * stop ws connection outside of write/read routines also, use t.Rate in tm-bench indexer when calculating ID fix gocritic issues * update swagger.yaml * Apply suggestions from code review * fix stylecheck and golint linter warnings * update changelog * update changelog2
5 years ago
  1. ---
  2. order: 5
  3. ---
  4. # Subscribing to events via Websocket
  5. Tendermint emits different events, to which you can subscribe via
  6. [Websocket](https://en.wikipedia.org/wiki/WebSocket). This can be useful
  7. for third-party applications (for analysis) or inspecting state.
  8. [List of events](https://godoc.org/github.com/tendermint/tendermint/types#pkg-constants)
  9. You can subscribe to any of the events above by calling `subscribe` RPC
  10. method via Websocket.
  11. ```
  12. {
  13. "jsonrpc": "2.0",
  14. "method": "subscribe",
  15. "id": 0,
  16. "params": {
  17. "query": "tm.event='NewBlock'"
  18. }
  19. }
  20. ```
  21. Check out [API docs](https://docs.tendermint.com/master/rpc/) for
  22. more information on query syntax and other options.
  23. You can also use tags, given you had included them into DeliverTx
  24. response, to query transaction results. See [Indexing
  25. transactions](./indexing-transactions.md) for details.
  26. ### ValidatorSetUpdates
  27. When validator set changes, ValidatorSetUpdates event is published. The
  28. event carries a list of pubkey/power pairs. The list is the same
  29. Tendermint receives from ABCI application (see [EndBlock
  30. section](https://github.com/tendermint/spec/blob/master/spec/abci/abci.md#endblock) in
  31. the ABCI spec).
  32. Response:
  33. ```
  34. {
  35. "jsonrpc": "2.0",
  36. "id": 0,
  37. "result": {
  38. "query": "tm.event='ValidatorSetUpdates'",
  39. "data": {
  40. "type": "tendermint/event/ValidatorSetUpdates",
  41. "value": {
  42. "validator_updates": [
  43. {
  44. "address": "09EAD022FD25DE3A02E64B0FE9610B1417183EE4",
  45. "pub_key": {
  46. "type": "tendermint/PubKeyEd25519",
  47. "value": "ww0z4WaZ0Xg+YI10w43wTWbBmM3dpVza4mmSQYsd0ck="
  48. },
  49. "voting_power": "10",
  50. "proposer_priority": "0"
  51. }
  52. ]
  53. }
  54. }
  55. }
  56. }
  57. ```