feat: implement IPC transport support #260
Conversation
austinabell
changed the title
|
You can launch a |
|
Is there a reason I'm missing for why a BTreeMap is used for the request ID lookups in the ws impl? I don't understand why the BTreeMap overhead is needed for lookups. I'm going to use a regular HashMap, but happy to switch back if there is a good reason. |
ethers-providers/Cargo.toml
Outdated
| @@ -24,6 +24,7 @@ serde_json = { version = "1.0.64", default-features = false } | |||
| thiserror = { version = "1.0.24", default-features = false } | |||
| url = { version = "2.2.1", default-features = false } | |||
| auto_impl = { version = "0.4.1", default-features = false } | |||
| ahash = { version = "0.7", default-features = false, features = ["std"], optional = true } | |||
There was a problem hiding this comment.
If you really need higher performance than SipHasher (I would suggest measuring), and don't care about hashDoS (the ahash crate is not designed to be hashDoS resistant, despite what the author might claim), I would suggest using the twox-hash crate which implements the XXHash algorithm.
There was a problem hiding this comment.
Yeah I'm aware of this, but figured this usage wouldn't require that property, but maybe I'm overlooking some concern. Thanks for the link, I'll look into that, but I'll just change to whatever @gakonst prefers since I don't have an opinion.
There was a problem hiding this comment.
I've switched it to siphash as a default, but happy to switch to whatever is preferred :)
There was a problem hiding this comment.
Sounds good. I think using what the standard library provides is a reasonable starting point, and if you need better performance, it would be good to measure whether a 3rd-party hashing crate actually provides an improvement.
|
Merged, thank you! If you want to join, we're discussing the library in this chatroom. |
This commit ports the `seth tx` command to `cast`. It follows the implementation of `cast block` and includes the feature to print a specific field in the transaction as well as printing the result in JSON. ``` $ cast tx --rpc-url <url> <tx-hash> [field] ``` The flag `-j`/`--json` is used to print the result as JSON.
Motivation
#106 I'm just playing with it to learn more about IPC connections and Tokio
Solution
This is very rough as is. Just opening draft and I'll hopefully cleanup tomorrow and do more extensive testing.
The connection seems to happen alright, but a warning is coming up that the method doesn't exist, so I'll look into that tomorrow tooBasic requests are now functional, but will test subscription based requests later. Is there any specific workflow that's ideal to test this?