Skip to content
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

Implement jsonrpsee-ipc #5

Closed
tomaka opened this issue Sep 16, 2019 · 14 comments
Closed

Implement jsonrpsee-ipc #5

tomaka opened this issue Sep 16, 2019 · 14 comments
Labels
good first issue Good for newcomers

Comments

@tomaka
Copy link
Contributor

tomaka commented Sep 16, 2019

While the async-std crate provides Unix domain sockets, there's no new-futures equivalent of Windows named pipes.

@tomaka
Copy link
Contributor Author

tomaka commented Oct 8, 2019

@tomusdrw Is that still needed?
Maybe we can mark this issue as "very low priority".

@tomaka tomaka added the good first issue Good for newcomers label Oct 8, 2019
@tomusdrw
Copy link
Contributor

tomusdrw commented Oct 8, 2019

Sure.

@tomaka
Copy link
Contributor Author

tomaka commented Oct 8, 2019

See also async-rs/async-std#291

@Demi-Marie
Copy link
Contributor

@tomaka This is still needed, as IPC is considered the most secure transport.

@wadagso-trey
Copy link

Is there really no other interest being expressed in this? I wonder how difficult it would be

I'm surprised there's been no activity considering how commonly used it is. My project is currently using the other jsonrpc crate but we'd like to have more direct support for async/await instead of the hack we're doing now by blocking on a task in a tokio runtime.

@niklasad1
Copy link
Member

niklasad1 commented Mar 14, 2022

ok, it shouldn't be that hard to port over but no one has really shown interest in it.

fair enough we should look into this

@dvdplm
Copy link
Contributor

dvdplm commented Mar 16, 2022

I'm surprised there's been no activity considering how commonly used it is.

Is it? We must be living in somewhat disjoint bubbles then! :)

I thought the IPC transport was mainly a legacy from when chains were so small that it was reasonable to expect end users to run their own full nodes and thus could benefit from having IPC level access control.

Can you elaborate a bit more on your use case (and that of others if they differ)? What about IPC is useful to you? I'm happy to consider adding IPC if there's a valid use case for it.

@wadagso-trey
Copy link

Not sure why the needs of blockchains are relevant to a jsonrpc library, but unix sockets are just a very convenient way for multiple processes to communicate with each other without having to deal with what comes with using a network stack (managing ports, network namespaces, etc.) and allows a more convenient permissions model. It seems silly to make HTTP/WebSocket requests between two processes on the same machine that have nothing to do with the web doesn't it?

@seunlanlege
Copy link

yeah we had ipc in parity-ethereum for this reason, built on https://github.com/paritytech/parity-tokio-ipc

@tomaka
Copy link
Contributor Author

tomaka commented Mar 18, 2022

It seems silly to make HTTP/WebSocket requests between two processes on the same machine that have nothing to do with the web doesn't it?

It also seems silly to me to spend time and effort developing and maintaining an IPC library when HTTP/WebSocket work just as good.

IPC is maybe a bit faster than using the WebSocket protocol, but if having maximum performance is actually a criteria then using JSON-RPC should be a much bigger concern than using WebSocket.

If you have a concrete example where IPC is a better solution (other than performances) than HTTP/WebSocket, then sure, but otherwise I would actually doubt that it's worth the burden of having additional code.

@wadagso-trey
Copy link

Compiling an entire HTTP client/server and including it in our binaries when it provides no additional value over the alternative seems seems like an unnecessary burden as well.

Plus more generally speaking: if someone was writing an API wrapper to interact with another project they didn't control then they wouldn't have a choice in the matter.

@dvdplm
Copy link
Contributor

dvdplm commented Mar 20, 2022

Compiling an entire HTTP client/server and including it in our binaries when it provides no additional value over the alternative seems seems like an unnecessary burden as well.

You can use whichever of the two supported transports that you prefer without having to carry the burden of compiling the other.

Supporting a third transport carries a maintenance burden that we are unlikely to want to carry at this point. If this is very important to you and if you are prepared to commit to implement and maintain it in the future then that's another matter. :)

@jsdw
Copy link
Collaborator

jsdw commented Aug 17, 2022

Since we have no internal need for this feature, we'd be relying on external contributions. I'm going to close this for now, but if somebody is interested in stepping up and wants to discuss the complexity of this, then you're welcome.

(although for what it's worth, whipping together a completely independent library to solve the specific use case may be the easier path to take here)

@delbonis
Copy link

delbonis commented May 3, 2024

Just leaving this here for future readers, the reth repo has a client and server impl that works with jsonrpsee: https://github.com/paradigmxyz/reth/tree/main/crates/rpc/ipc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

9 participants