@Eric, I did not find any mention of relay_request in the documentation. However, I *loved* the service-agnostic proxy. While reading the code it dawned on me that I can run an instance of this proxy on L, and the client will simply send to port X to get to L, and to port Y to get to R. I'm going to give this a try.
Thanks a lot! Dan On Wednesday, January 16, 2019 at 9:13:17 AM UTC+2, [email protected] wrote: > > That is half correct ;-) in my scenario L is also a service provider, but > it is also a proxy for requests I need to send to R. > I was not aware of relay_request. I'll definitely check it out, as well as > your service-agnostic example. > > Thanks, > Dan > > > On Tuesday, January 15, 2019 at 5:57:43 PM UTC+2, Eric Anderson wrote: >> >> It sounds like L is just a proxy in that case. You use the relay_request >> if that feels natural to you. You can also do "L7 load balancing" by >> relaying requests at the HTTP/2 or gRPC level. I have made an example >> service-agnostic gRPC proxy in Java >> <https://github.com/ejona86/grpc-java/blob/grpc-proxy/examples/src/main/java/io/grpc/examples/grpcproxy/GrpcProxy.java>. >> >> My example proxies everything, but it is possible to also proxy only >> services or methods. I think you can do semi-similar things in other >> languages, although the difficulty may vary. >> >> On Mon, Jan 14, 2019 at 11:40 AM 'Carl Mastrangelo' via grpc.io < >> [email protected]> wrote: >> >>> Yes, this is possible. You'll need to implement some unpacking scheme >>> on L, but it can then forward the raw bytes of the request. Note that if >>> you are using Proto, you may not be able to use all the generated stub >>> code. If C, L, and R all know about the same message types, then you can >>> use the proto stubs. >>> >>> Note also that the headers will need to be captured from C->L, and the >>> response trailers from R->L. If you wanted this to be "delayed" in any >>> way, it may get more tricky. >>> >>> On Sunday, January 13, 2019 at 12:52:29 AM UTC-8, [email protected] >>> wrote: >>>> >>>> Consider a grpc client C, and servers L & R (local & remote). >>>> Servers L & R are connected. Client C can reach only server L. >>>> >>>> Client C needs to send a request to server R. >>>> >>>> Can I create a "relay_request" message that server L will support, >>>> where the body is the request to send to server R? (also dealing with >>>> relaying the reply) >>>> >>>> Is there anything better I can do for such a scenario? >>>> >>>> Thanks, >>>> Dan >>>> >>> -- >>> 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/fc766ee0-a9b7-46f2-bbd5-024c1fba3e1a%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/grpc-io/fc766ee0-a9b7-46f2-bbd5-024c1fba3e1a%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/f0216e6a-7b05-4f8c-86b4-38b5217ae1cf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
