Yes, there has been a C++ in-process transport for about six months now. It is not a perfect replacement for the http2 transport as servers are referenced by pointer and not by name; we have another task in place to add naming for in-process but will probably deal with that after making related changes to better support the UDS transport.
On Monday, January 22, 2018 at 5:55:46 AM UTC-8, Robert Bielik wrote: > > What is the status of issue https://github.com/grpc/grpc/pull/11145 ? > Does this mean there is now C++ in-process transport ? > > > Den onsdag 30 augusti 2017 kl. 12:06:39 UTC+2 skrev Craig Tiller: >> >> There's not currently. That's not to say there can't be, but doing better >> would likely mean someone signs up to design and implement some kind of >> shared memory transport. Such an effort would likely be multi quarter to >> get it done right, and we've currently no plans to do so. >> >> On Tue, Aug 29, 2017, 7:44 PM <[email protected]> wrote: >> >>> Hi, >>> >>> This might be somewhat naive questions but are there alternatives to >>> TCP/IP. Basically we are using grpc for embedded system (on Ububtu, >>> currently C++ only) and will want to be communication between *two* >>> processes to be as fast as possible. >>> We have tested with unix domain sockets and results are faster, I am >>> wondering if there is any other means to get even better results. I am >>> assuming since these are two different processes we can't use inprocess >>> transport >>> >>> Regards >>> >>> >>> On Wednesday, May 17, 2017 at 10:48:20 AM UTC+5:30, Vijay Pai wrote: >>>> >>>> Hello there, >>>> >>>> I've recently initiated a pull request on this topic ( >>>> https://github.com/grpc/grpc/pull/11145 ) . It should be ready to go >>>> in the next week or so as we wrap up the last few corner cases. This is in >>>> gRPC C Core and includes a C++ API for starters ; we'd be glad to take >>>> input on putting this together as a C# API as well. This is true >>>> in-process >>>> transport using shared-memory addresses between the client and server, not >>>> any kind of file descriptor or pipe. >>>> >>>> - Vijay >>>> >>>> On Monday, May 1, 2017 at 11:43:06 AM UTC-7, Cole Harrison wrote: >>>>> >>>>> Craig, >>>>> I notice this tread is almost a year old, has there been any >>>>> movement on in process communication? Is there a possibility for Named >>>>> Pipe >>>>> support with windows systems? My team is interested in using the C# >>>>> implementation of gRPC but has a strong desire for Named Pipe support. >>>>> >>>>> Thanks for you help, >>>>> -Cole >>>>> >>>>> On Sunday, May 15, 2016 at 9:47:04 AM UTC-7, Craig Tiller wrote: >>>>>> >>>>>> For non-windows systems we support Unix domain sockets >>>>>> (unix:path-to-socket when adding a port to a server or creating a >>>>>> channel). >>>>>> >>>>>> I'd like to get pure in process up and going at some point, but there >>>>>> needs to be some design done first. Most of the building blocks exist >>>>>> however. >>>>>> >>>>>> On Sun, May 15, 2016, 9:41 AM Robert Bielik <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I'm planning on using gRPC for interaction between different >>>>>>> components, however, the client should not be aware of the ultimate >>>>>>> location of the server implementation. >>>>>>> >>>>>>> I.e. I want to be able to do a "in process" service implementation >>>>>>> that does not need TCP/IP for transport. Is there some other mechanism >>>>>>> available, like named pipes ? >>>>>>> >>>>>>> Or other ideas ? >>>>>>> >>>>>>> Regards >>>>>>> /Robert >>>>>>> >>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/grpc-io/9f315629-dcdc-4cdd-8417-35a8b5886353%40googlegroups.com >>>>>>> >>>>>>> <https://groups.google.com/d/msgid/grpc-io/9f315629-dcdc-4cdd-8417-35a8b5886353%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/grpc-io. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/grpc-io/f308b2d3-f1ba-4d0d-8d64-f6626c9d40f0%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/f308b2d3-f1ba-4d0d-8d64-f6626c9d40f0%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f0caf503-6f4f-42ea-83eb-2e545ada1bfb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
