You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
clients: reduce mem usage, refactor protocol handling (#247)
JSON-RPC is modelled as request-response where each response corresponds
to one request, sent in the same order. In addition, batching is
possible where several requests can be sent as one batch, receiving one
batch of responses in return, but still maintaining the general 1:1
messaging structure.
This PR exploits this 1:1 relationship between request and response to
simplify the client implementation and improve efficieny (reduces mem
usage from 1.2gb to 800mb to send a 128mb message - still a lot, but
quite a bit better) while at the same time cleaning up error handling
and moving the JSON-RPC specifics out of the transports so that they're
equal and shared between each transport.
The transports themselves now just provide the simple ability to
transfer request-response pairs.
In doing so, protocol adherence in edge cases is increased to more
closely follow the semantics suggested in the spec.
* match messages by order, getting rid of unnecessary matching table
* move all JSON-RPC protocol implementation details such as
encoding/decoding etc to `clients`, avoiding it being spread out and
repeated in each transport - this also opens the door to using a
different encoding than JSON in the future (ie CBOR)
* stream-encode requests and use `seq[byte]` throughout to avoid costly
`string` conversions / copies
* clean up error raising - in particular, differentiate between
transport and protocol errors more clearly and strive to raise similar
exceptions in similar situations for each transport
* add `maxMessageSize` parameter to each transport, make it work the
same
* remove socket client reconnect loop to match websockets - possibly it
should be re-added to both instead in a future PR
* add `raises` to `async`, where relevant
* order request/response json fields the way they're ordered in the spec
* this makes it more efficient to parse messages following the same
order
* make parser more spec-compliant, moving some of the validation to an
earlier stage in the parsing pipeline
* limit the length of string-based `id` fields to avoid having the log
spammed
* stream-write requests, avoiding an extra copy of the parameters
* use raw async procs where applicable to avoid copies and async
overhead
0 commit comments