Local in process server

[Robert Bielik]

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

[Craig Tiller]

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.

--
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.
For more options, visit https://groups.google.com/d/optout.

[Robert Bielik]

Thanks Craig,

Den söndag 15 maj 2016 kl. 18:47:04 UTC+2 skrev Craig Tiller:

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.

Indeed. As a crude design idea, the ServerBuilder could get hold of the same "Channel" object as the client, i.e. no need to specify a naming for the channel/port ?

ServerBuilder::SetChannel(std::shared_ptr<Channel> channel);

and a:

std::shared_ptr<Channel> gprc::CreateLocalChannel();

which is used on both client and server sides. Something along those lines ?

[Craig Tiller]

Maybe. Another path I've been thinking about is having an internal registry, and adding an inprocess: uri scheme to our naming system. It'd allow fairly transparent migration from in process to out of process subsystems and really drive home a "grpc is your linker" story that seems appealing.

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/29a17950-7835-4c46-a459-d86cdc92921b%40googlegroups.com.

[Josh Humphries]

On Sun, May 15, 2016 at 4:38 PM, 'Craig Tiller' via grpc.io <grp...@googlegroups.com> wrote:

Maybe. Another path I've been thinking about is having an internal registry, and adding an inprocess: uri scheme to our naming system.

FYI, the Java implementation already has something very similar to this: https://github.com/grpc/grpc-java/tree/master/core/src/main/java/io/grpc/inprocess

 

To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAAvp3oMTdFysn%3D62DUDRd9i1ibzTsh0F9U5xD5EDbDOYAc5AdA%40mail.gmail.com.

[Robert Bielik]

Den måndag 16 maj 2016 kl. 16:02:45 UTC+2 skrev Josh Humphries:

On Sun, May 15, 2016 at 4:38 PM, 'Craig Tiller' via grpc.io <grp...@googlegroups.com> wrote:

Maybe. Another path I've been thinking about is having an internal registry, and adding an inprocess: uri scheme to our naming system.

FYI, the Java implementation already has something very similar to this: https://github.com/grpc/grpc-java/tree/master/core/src/main/java/io/grpc/inprocess

Thanks Josh, that looks very interesting!

[Cole Harrison]

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

[Vijay Pai]

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

[sriva...@gmail.com]

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

[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.

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.

[Robert Bielik]

What is the status of issue https://github.com/grpc/grpc/pull/11145 ? Does this mean there is now C++ in-process transport ? 

[Vijay Pai]

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.

[christon...@gmail.com]

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

[anothe...@gmail.com]

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!

[Anton Smirnov]

Hi, I've found InProcess transport incompatible between the languages (C++ + Java). Please find my follow-up thread.