gRPC over any kind of reliable socket

[glert...@gmail.com]

Hello,

After taking the time to think a little bit about the problem I had some time ago, I got a little bit deeper and come up with a possible idea of approaching a general solution to these kind of problems.

I'm not creating a new transport, i'm just asking if it would be possible to add a way to inject a low level read-write interface to the gRPC library so that it would be possible to solve lots of 1-1 cases like:

• gRPC over Websocket: To avoid firewall and create a one to one communication with an edge gateway.
• gRPC over Bluetooth: To communicate with an IoT (edge or constrained-device) and get/set/* parameters on it.
• gRPC over WhateverLowLevelTransportYouCanThinkOf: Industrial ones like CAN, Modbus, ... 

This is already solved in Go by using custom listeners in the gRPC Server (https://github.com/glerchundi/grpc-boomerang/blob/994642fc35afe85b994f03daab89f420acdb6db8/cmd/websocket-client-grpc-server/main.go#L99-L102) and custom net.Conn through Dial in gRPC Client (https://github.com/glerchundi/grpc-boomerang/blob/994642fc35afe85b994f03daab89f420acdb6db8/cmd/websocket-server-grpc-client/main.go#L104-L110).

But, as far as I know, there is no easy way (forking the library and modifying it is not an option!) to get this done in other languages like ObjC or Java. I think that this could be achieved in C by doing socketpair+grpc_insecure_channel_create_from_fd with a custom middleware that does the translating job.

So my question is, how do you community people see the possibility to open up the API (in *all* languages), in a generalised way, so that we can inject our own read-write full-duplex interface and create a wide range of 1-1 connection possibilities?

Ref: https://github.com/glerchundi/grpc-boomerang

[Craig Tiller]

We're looking into ways of exposing the internal grpc_endpoint interface up through wrapped languages, which should accomplish this. I don't have a timeline for completion however.

[Craig Tiller]

For common things (Bluetooth, websockets) I think having these available by default for all core languages could make sense.

For Bluetooth I could imagine a bluetooth:// naming scheme, and for websockets a handshaker and wrapped endpoint that's toggled on via a channel arg?

[glert...@gmail.com]

Thanks Craig for your comments,

Seems reasonable and at least we're aligned. The idea of this thread was to know how open the grpc community would be to create an entrypoint to solve existing issues with these kind of transports (although transport in gRPC refers to application-level transport i.e h2, grpc-web, ...). I would like to start discussing the hows and put some on the table in order to push this forward, we're really interested to have an upstreamed solution.

WDYT if we start with the C based gRPC codebase, can you extend your idea on publishing grpc_endpoint with some pseudocode?

[glert...@gmail.com]

Cross-referencing a PR in nanopb to add gRPC support: https://github.com/nanopb/nanopb/pull/248.

[glert...@gmail.com]

Ok, sorry for being spammy but I don't know how I missed this:

• https://github.com/grpc/grpc/issues/8639
  
• https://github.com/grpc/proposal/pull/8