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 <robert...@gmail.com> 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 grpc-io+u...@googlegroups.com. >>>> To post to this group, send email to grp...@googlegroups.com. >>>> 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 grpc-io+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@googlegroups.com. 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. For more options, visit https://groups.google.com/d/optout.
