Hi, I've found InProcess transport incompatible between the languages (C++ + Java). Please find my follow-up thread <https://groups.google.com/g/grpc-io/c/jAvNYl-_i30>.
On Tuesday, June 23, 2020 at 11:27:21 AM UTC+5 [email protected] wrote: > 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/91008bcf-b2d2-4a42-9bfd-46f424fa1f0fn%40googlegroups.com.
