@Eric: I tried to access the service-agnostic grpc proxy link below, but I 
am getting 404 (not found):
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>

Please let me know if there is a new link for it.

Thanks

On Tuesday, 22 January 2019 at 17:30:09 UTC-5 Eric Anderson wrote:

> I wasn't saying "relay_request" was a "thing". I just used the terminology 
> because you used the terminology.
>
> Glad the service-agnostic proxy looks good. I would encourage you to 
> consider having a single port and choosing the service-agnostic proxy for 
> only certain services; it removes the client from having to know what goes 
> where.
>
> On Tue, Jan 15, 2019 at 11:51 PM <[email protected]> wrote:
>
>> @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
>>  
>> <https://groups.google.com/d/msgid/grpc-io/f0216e6a-7b05-4f8c-86b4-38b5217ae1cf%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/5ddc8f93-0590-478e-9c59-d4f4a8cdff16n%40googlegroups.com.

Reply via email to