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/30a0fa89-8f0e-4ef6-b48b-528bf79cf609%40googlegroups.com.
