-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
archive/storageDiff: Suggestion to make storageDiff subscription-based #160
Comments
I would also want to change The main benefits of it:
I think it would beneficial to make it subscription-based but I haven't followed discussion why it's not, WDYT? |
There are big differences between None of these reasons are related to backpressure/DoS attacks, and In theory,
This is already covered by the function:
I don't see how this helps against DoS attacks. You suggest that the server sends a small amount of data then waits for the client to send back some kind of message before the server continue. This is exactly what happens on the TCP connection with ACK messages. There's no need to build a similar mechanism on top of what TCP/IP already does. The |
The one aspect where turning But again this is just to help the client, and if the client experiences this problem it can simply decide by itself to send smaller queries in a row. There's no need to adjust the API of |
Sure but when it comes Am I understanding you correctly that you think is more of implementation thingy which would be achieve with a single method response? It would certainly be easier to implement such a thing with a subscription instead by iterating and sending one a value at the time but bounding the number of storage queries in each call works as well for now. |
Yes! I don't think that the lack of streaming JSON serializer is a big problem. JSON is a very simple language, and you can simply generate JSON manually as strings. Send something like I realize that this might conflict with your existing abstraction layers (which I'm not familiar with anymore), but between having a complicated JSON streaming system or having a complicated notifications system for that RPC function, or simply sending strings, IMO simpler is better. |
Note: I'm only really thinking about
I guess this is the main point yeah. We could implement the method in a nice way by manually streaming it as you described, but that also requires punching through our JSON-RPC abstraction to the websocket implementation so that we can break the message into multiple frames (and avoid sending a length up front), which I suspect is very difficult for us to do. And so, my argument for having it be subscription based would be that it's difficult for us to implement nicely, and (if we cared) I suspect it would be difficult for anybody else to do the same. If we instead use the tools available at the JSON-RPC abstraction layer (ie subscriptions) we'll avoid this difficulty (and also happen to have the nice side effect of avoiding head-of-line blocking, since you can't interleave anything other than opcodes with partial websocket frames). Owing to this difficulty/complexity of implementation, we'll likely have to build up a response in memory and error if that grows too large, which is less nice for users (who have to then figure out how to break their requests up to avoid such errors) but also doable. |
If I summarize, we agree that ideally the JSON-RPC API would stay as it is, and the implementation would be modified, but in practice it is too difficult to do so. But I'd like to raise another trade-off: is someone actually going to attack a JSON-RPC node by repeatedly sending large requests? As far as I'm aware no DoS attempt has ever happened to Parity, and I also have never heard of this happening to anyone. On the negative side, this modification to the JSON-RPC API is essentially a hack, and makes the life of the JSON-RPC client more complicated. On the positive side, it would prevent some DoS attacks. But if DoS attacks are in reality not really a concern, is it really worth doing this? |
My summary would be more like (again focusing only on Pros of current API:
Pros of subscription based API:
Even if they are not a reality, would it not be better to avoid such a potentially easy target? Overall, I don't overly love having to complicate the API for users even a little bit, but in return we would also make it more likely to succeed (for eg large responses), more resilient (to eg DoS attacks) and more performant (than the non-difficult implementation at least, for users too). So I can't help but think that it is worthwhile overall. |
At the moment,
storageDiff
is a plain method.To implement
storageDiff
of two arbitrary blocks, we'll have to iterate through the keys of both blocks and access the storage of those keys requested by the user.This operation might be expensive enough to DoS the node, considering users might request differences between
genesis
<->latest-finalized
.Another benefit of having a subscription-based approach for
storageDiff
is that we can leverage the backpressure system implemented for the chainHead subscription.On the other side, users will have to adapt their code to work with a subscription-based approach.
Implementation ref: https://github.com/paritytech/polkadot-sdk/pull/5997/files#diff-ac650a2e540d8d37576d05083cce78260192944382ecf1e68f0db50b5d86907eR350-R369
// cc @paritytech/subxt-team @tomaka @josepot Would love to get your thoughts on this 🙏
The text was updated successfully, but these errors were encountered: