If you're asking about Named Pipes on Windows, there is no support at the moment. On posix systems, if you have a raw file descriptor for a named pipe, I believe you can create a channel from it using `CreateCustomInsecureChannelFromFd`: https://github.com/grpc/grpc/blob/420180c6d7a5ad00870f099d2e2c79ad367fe9ee/include/grpcpp/create_channel_posix.h#L40-L47. Caveat: I have not tried this myself.
There is a long-standing open issue to design, scope, and add support for named pipes on Windows: https://github.com/grpc/grpc/issues/13447. The gRPC team will not have bandwidth to do this in the forseeable future, unfortunately. On Sunday, February 19, 2023 at 9:40:35 PM UTC-8 valerij zaporogeci wrote: > thank you, I am aware of that project. there is a mention from the author, > that his implementation uses custom wiring protocol and thus is > incompatible with other gRPC. the requirement to me is to be interoprable > with C++ client/server and C# client/server soultions. So, I am not sure > what is easier - reimplementing what Cyanfish has done in C# to C++ or > changing/adding directly to gRPC (core). > > понеділок, 20 лютого 2023 р. о 07:35:11 UTC+2 Manikandan V S пише: > >> We were also exploring the same and found this >> https://github.com/cyanfish/grpc-dotnet-namedpipes . We are yet to >> completely analyze it for our usage. >> >> Its dotNet based one but you can still look at the underlying grpc >> implementation on how its done. >> >> If you find any other solution, Let me know. >> >> Regards, >> Mani. >> >> >> On Monday, 20 February 2023 at 10:56:47 UTC+5:30 valerij zaporogeci wrote: >> >>> Hello, someone wants to use Named Pipes, but still insists on relying on >>> gRPC in doing so (shrugs), so I need your help, as the knowledgeable ones, >>> in clarifying on how feasible it is to make gRPC use Named Pipes instead of >>> network or domain sockets. I am a C guy, so this C++ stuff looks scary for >>> me. I can't get what I need to change. ports are going down to the deepest >>> guts of grpc, from the very start you set ports and then it goes down to >>> the grpc core, where still ports are everywhere. >>> >>> I am not asking to make a research for me, just an evaluation, since you >>> understand grpc internals and it might be easy to you to answer if changing >>> transport from a network based one to something else is feasible or it >>> would be too hard, since grpc is not flexible with this respect and a bit >>> of direction of where the change should primarily happen - on the surface >>> (API) is enough (doubtfully), grpc core. where? should it be rewritten or >>> it's more an addition? also, I would want to make it in a compatible way, >>> so that code wouldn't stop working with the next gRPC update. >>> >>> thank you in advance. >>> >> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b38e2b92-0ef6-455c-b835-f65f8cb4dc37n%40googlegroups.com.
