Re: [grpc-io] Re: GRPC with istio for public clients and internal applications

[Isuru Samaraweera]

This implies that even internal applications sitting behind the ingress
invoke grpc services through the ingress like public client applictions
.Please verify?

On Mon, Dec 3, 2018 at 5:32 AM 'Srini Polavarapu' via grpc.io <
grpc-io@googlegroups.com> wrote:

> gRPC clients have only round-robin and pick-first built-in LB policies
> available to them. You are probably better off using Istio ingress LB to
> share LB policy unless you want to run your own gRPCLB service and
> implement your LB policy in there.
>
> On Wednesday, November 14, 2018 at 8:35:36 PM UTC-8, Isuru Samaraweera
> wrote:
>>
>> Hi,
>> I am going to expose GRPC services to public clients using istion ingress
>> and proxy load balancing.
>> In addition to public grpc clients I want internal applications to use
>> the same grpc cluster with a common load balancing policy for both public
>> clients and internal applications.
>>
>> Should the internal applications use istio ingress to achieve shared load
>> balancing policy or can it be done via a separate client side load
>> balancing mechanism only for internal apps?What is the recommended approach?
>>
>> Thanks,
>> Isuru
>>
> --
> 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/ed569881-f2b5-4aa1-a4e6-0b4917ed848a%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Isuru Samaraweera

-- 
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/CAOtGh-rBBbPvA%2BPOzzT0KWUTtsQqA95Egdm49%3DTPjYYe0U9zmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: GRPC with istio for public clients and internal applications

['Srini Polavarapu' via grpc.io]

gRPC clients have only round-robin and pick-first built-in LB policies 
available to them. You are probably better off using Istio ingress LB to 
share LB policy unless you want to run your own gRPCLB service and 
implement your LB policy in there.

On Wednesday, November 14, 2018 at 8:35:36 PM UTC-8, Isuru Samaraweera 
wrote:
>
> Hi,
> I am going to expose GRPC services to public clients using istion ingress 
> and proxy load balancing.
> In addition to public grpc clients I want internal applications to use the 
> same grpc cluster with a common load balancing policy for both public 
> clients and internal applications.
>
> Should the internal applications use istio ingress to achieve shared load 
> balancing policy or can it be done via a separate client side load 
> balancing mechanism only for internal apps?What is the recommended approach?
>
> Thanks,
> Isuru
>

-- 
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/ed569881-f2b5-4aa1-a4e6-0b4917ed848a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [grpc-io] Linux build - cmake generated Makefile vs checked-in Makefile?

[Nicolas Noble]

The short answer to "why provide both" could be resumed to "so that people
have options". There are pros and cons to each build mechanism that is, and
cmake doesn't necessarily fit everyone's needs. There's consumers of the
Makefile that is, such as the Ruby or the Python build, which can't call
cmake beforehand. That's a byproduct of having to deal with many platforms
and languages.

On Fri, Nov 30, 2018 at 7:06 AM  wrote:

> I'd like to understand the difference between the checked in Makefile and
> the cmake generated Makefile on Linux.
>
> On Windows, we must use cmake and then do a build with visualstudio. I
> understand the reasons for using cmake.
>
> On Linux, it seems there are two options. 1) we could use the Makefile
> checked into the project. 2) we could also use cmake and then build with
> the generated Makefile. Both seem to work ok although binaries are put into
> different directories.
>
> What are the build differences when using the checked in Makefile vs the
> cmake generated Makefile for the linux build?
> Why provide both?
> Which approach is recommended?
>
> Thanks,
>
> Steve Nikopoulos
>
> --
> 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/78a74796-d045-4a57-813a-ea4f6780e2a3%40googlegroups.com
> 
> .
> 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/CAEvr0PELst_yL%2BqDR8P-XrWa8ZHhociN%3DT6d0vqa0j8arRRDxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: grpc connections

[mailarifkhan]

On Sunday, December 2, 2018 at 6:04:02 PM UTC+5:30, mailar...@gmail.com 
wrote:
>
>
> Thanks Carl, appreciate your detailed response, helps clear my confusions.
>
> Regarding Load balancer, yes, you are right, i was talking about server 
> side LB like a LinkerD or Ngnix.
>
> Actually this is my setup 
>
  grpc client  --> Virtual IP > Load balancer 1 - grpc 
server 1, grpc server 2
  Load balancer 
2 - grpc server 3, grpc server 4


   Based on the setup above, assuming everyone is on "round robin", 
will there be 4 connections / channel ? or 1 channel used across multiple 
grpc servers.
Internally i see that netty is used, and async stubs, which implies async 
connections. It adds to the confusion, how are async connections managed ? 
do they follow the same pattern as synchronous . 

Thanks again !

AK

 

>  
>
>
>
>
> On Saturday, December 1, 2018 at 12:40:41 AM UTC+5:30, Carl Mastrangelo 
> wrote:
>>
>> gRPC uses a "channel" rather than a "connection" as the surface level 
>> API.   A channel is a managed set of connections to your server(s).  The 
>> number of connections could drop down to 0 if they are idle, or be as large 
>> as every server returned by your DNS entries.   gRPC has two pluggable 
>> components called a "name resolver" and a "load balancer" which both run 
>> inside of your client.   The name resolver (typically DNS), converts the 
>> "target" string you connect to, and turns it into a set of addresses.  The 
>> load balancer is notified of the addresses, and decides which ones to 
>> create connections to, and which ones received your RPCs.   By default, we 
>> use a "pick first" load balancer which only makes one connection.
>>
>> If the connection between a client and a particular server breaks, the 
>> connection is removed from the set, and if another connection is available, 
>> gRPC will fire RPCs on the healthy one.  If not, gRPC will attempt to 
>> establish a new connection, up until the point that your RPC is not 
>> canceled or the deadline has exceeded.
>>
>> The word load balancer is overloaded here, because client side load 
>> balancing is different than server side.   I think you are talking about 
>> server side.   You will need to modify your client side load balancer to 
>> "round robin", which will establish connections to every backend server you 
>> have.   When servers terminate, or are added to the pool of backends, it's 
>> up to the client side load balancer / name resolver to notice these 
>> differences and adjust the connections.  gRPC does this by default (via the 
>> connections actually breaking), but it's faster if your name resolver 
>> (again, typically DNS) notices the server set has changed. 
>>
>> On Friday, November 30, 2018 at 7:20:27 AM UTC-8, fairly accurate wrote:
>>>
>>>
>>> Hello All,
>>>   I'm a newbie grpc user. Actually, i'm using a product that is built 
>>> over grpc.
>>> I have read stuff about grpc, pardon my ignorance, some basic questions 
>>> on grpc connections.
>>>
>>> 1. I understand it is 1 connection per client server pair. Does this 
>>> mean a connection is established between client and server, and stays alive 
>>> until one of them ceases to exist ?
>>> Also, if the connection drops, a new connection is initiated ?
>>>
>>> 2. I have a load balancer placed between the client and server. The LB 
>>> has 2 servers. In this case is 1 connection to each server or just one to 
>>> LB and the load is balanced between the tow servers or 2 connections ?
>>>
>>> Appreciate your response.
>>>
>>> AK
>>>
>>

-- 
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/3dc2f1bc-352b-4a4c-a1eb-e6b3c3f00250%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[grpc-io] Re: grpc connections

[mailarifkhan]

Thanks Carl, appreciate your detailed response, helps clear my confusions.

Regarding Load balancer, yes, you are right, i was talking about server 
side LB like a LinkerD or Ngnix.

Actually this is my setup 




On Saturday, December 1, 2018 at 12:40:41 AM UTC+5:30, Carl Mastrangelo 
wrote:
>
> gRPC uses a "channel" rather than a "connection" as the surface level 
> API.   A channel is a managed set of connections to your server(s).  The 
> number of connections could drop down to 0 if they are idle, or be as large 
> as every server returned by your DNS entries.   gRPC has two pluggable 
> components called a "name resolver" and a "load balancer" which both run 
> inside of your client.   The name resolver (typically DNS), converts the 
> "target" string you connect to, and turns it into a set of addresses.  The 
> load balancer is notified of the addresses, and decides which ones to 
> create connections to, and which ones received your RPCs.   By default, we 
> use a "pick first" load balancer which only makes one connection.
>
> If the connection between a client and a particular server breaks, the 
> connection is removed from the set, and if another connection is available, 
> gRPC will fire RPCs on the healthy one.  If not, gRPC will attempt to 
> establish a new connection, up until the point that your RPC is not 
> canceled or the deadline has exceeded.
>
> The word load balancer is overloaded here, because client side load 
> balancing is different than server side.   I think you are talking about 
> server side.   You will need to modify your client side load balancer to 
> "round robin", which will establish connections to every backend server you 
> have.   When servers terminate, or are added to the pool of backends, it's 
> up to the client side load balancer / name resolver to notice these 
> differences and adjust the connections.  gRPC does this by default (via the 
> connections actually breaking), but it's faster if your name resolver 
> (again, typically DNS) notices the server set has changed. 
>
> On Friday, November 30, 2018 at 7:20:27 AM UTC-8, fairly accurate wrote:
>>
>>
>> Hello All,
>>   I'm a newbie grpc user. Actually, i'm using a product that is built 
>> over grpc.
>> I have read stuff about grpc, pardon my ignorance, some basic questions 
>> on grpc connections.
>>
>> 1. I understand it is 1 connection per client server pair. Does this mean 
>> a connection is established between client and server, and stays alive 
>> until one of them ceases to exist ?
>> Also, if the connection drops, a new connection is initiated ?
>>
>> 2. I have a load balancer placed between the client and server. The LB 
>> has 2 servers. In this case is 1 connection to each server or just one to 
>> LB and the load is balanced between the tow servers or 2 connections ?
>>
>> Appreciate your response.
>>
>> AK
>>
>

-- 
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/241984eb-b0f3-4b6f-9401-43c2e9550a71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.