In your case, 1 Channel, 1 connection. Since there is one single IP address, all traffic will be routed to it. (if you had 4 IP addresses, it would be 1 channel, 4 connections).
I'm not sure what to say about the usage of Netty. The connections are actually synchronous, but use non blocking IO. When they go bad they notify the channel which notifies the client side load balancer. On Sunday, December 2, 2018 at 4:41:22 AM UTC-8, [email protected] wrote: > > > > On Sunday, December 2, 2018 at 6:04:02 PM UTC+5:30, [email protected] > 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 [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/d19f6e08-64d6-4100-ac2d-754414a46582%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
