Support IPC transport

[mattsse]

The deprecated jsonrpc crate has IPC support, which this crate currently lacks.

Are there plans to add support for IpcClient/Transport?

After skimming some parts of the codebase, it looks like this is the main entrypoint:

https://github.com/paritytech/jsonrpsee/blob/990c120dc6f72eace65be4a1976b82cfad055a75/core/src/client/async_client/mod.rs#L158

the ws implementation provides the transport types like this:

https://github.com/paritytech/jsonrpsee/blob/990c120dc6f72eace65be4a1976b82cfad055a75/client/transport/src/ws/mod.rs#L242-L244

I guess for ipc this could look similar?

If there no plans for adding this, I'd be happy to take this on.

[lexnv]

The deprecated jsonrpc crate has IPC support, which this crate currently lacks.

The IPC support is a nice feature to have, but its not really required for the purposes of substrate. The performance boost from having an IPC would be marginal compared to HTTP, even to WS for the substrate extrinsics and payloads.

Are there plans to add support for IpcClient/Transport?

IIRC, we decided to not implement the IPC to keep a minimal maintainable code in place.

Any contributions would be welcomed, thanks for being available for this.

I'm wondering tho, is there a real use-case/demand for having the IPC into the jsonrpsee?

CC: @niklasad1 What do you think?

[niklasad1]

hey @mattsse

The idea is that we already have async client abstraction so it should be sufficient for you implement TransportReceiverT and TransportSenderT for IPC similar to what we have in client/transport

so pretty much similar to how WS is implemented yes. Have a look here, I think it explains how it works it pretty much the same approach but you have to provide some similar for IPC.

IPC support could even live in some other repo as long it implements TransportReceiverT and TransportSender but I think it's fine to support it if you are willing to contribute it. Would be good to know the reason why you need it though (we/parity) have no real need for IPC currently and that's why we don't support it for client or server.

[XOR-op]

@niklasad1 I think the biggest difference between IPC and localhost HTTP is security. IPC is able to utilize the permission control mechanism provided by OS, for example uid or gid. Instead, HTTP has no runtime access control mechanism. Although pre-shared key may be seen as an access control method if we inject some logic into HTTP/WS, they must be predefined and static as long as there is no sideband (using another IPC for key exchanging and then using HTTP is weird and not elegant), while uid and gid can be dynamically set at runtime.

Another reason is that jsonrpsee doesn't provide a async server for user to implement their own IPC server if they want. If users want to implement a IPC server themselves, they cannot easily manage it. So I think jsonrpsee should consider implementing IPC transport, or at least provide an approach to cusomize the server.

[AArnott]

FWIW I too am keenly interested in IPC scenarios. And I'd be happy to contribute to this crate.

However my approach to this is to build up the code required to divorce the APIs from being per-transport. I have an IPC-supported bit of code that works with this crate already, but it works with any transport via AsyncWrite and AsyncRead traits (in tokio). So the fact that it works with IPC is a (contrived) coincidence.

Fundamentally, JSON-RPC is a P2P protocol and shouldn't be tied to any particular transport either.

[niklasad1]

I belive reth-ipc has a nice implemenation for this that you could use but it doesn't seem to be published on crates.io