The C++ implementation that Vijay referred to is here: https://github.com/grpc/grpc/tree/master/src/core/ext/transport/inproc
Currently, the documentation is a bit sparse and, in general, there seems to be more momentum behind the grpc-web implementations than in-process ones but they require similar abstractions. Hopefully, implementing grpc over HTTP/1.1 required enough refactoring that in-process transports are now easier to create. If done well, then it seems like in-process grpc can gain a lot of adoption, replacing FFI/JNI boundaries where one language needs to call into another language in the same process--such as Android, iOS, desktop and web code all interacting with the same business logic layer that runs locally. This is something I'm currently pursuing for security and privacy applications but it doesn't seem to exist in a portable way. Our applications use Rust and trying to shoehorn in this C++ transport seems like overkill. For now, we're sticking with custom in-process layers on each platform but I'm hoping that can soon be replaced by one in-process transport layer to rule them all! On Wednesday, August 21, 2019 at 9:36:20 PM UTC-4, [email protected] wrote: > > Hi All, > > I'm in process of creating C++ components but I need 2 suggestions > > will in-process transport will be faster r we can use HTTP/2 and also > someone please point me to some examples for in-process examples for C++, > Most of the places I'm seeing only samples for JAVA. > > Thanks in advance > > On Thursday, 25 January 2018 05:18:06 UTC+5:30, Vijay Pai wrote: >> >> 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/b0432df5-a5dd-4ac2-8103-af2fcd1f797fo%40googlegroups.com.
