Implement jsonrpsee-ipc

[tomaka]

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

[tomaka]

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

[tomusdrw]

Sure.

[tomaka]

See also async-rs/async-std#291

[Demi-Marie]

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

[wadagso-trey]

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]

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]

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]

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]

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

[tomaka]

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.