Thanks for the feedback, Eric. On Wed, Jan 25, 2017 at 12:59 PM, 'Eric Anderson' via grpc.io < grpc-io@googlegroups.com> wrote:
> The Java implementation is going to have hurdles. I sort of expect issues > adhering to the design as precisely as it is defined. I've got to figure > out where ProxySelector > <http://docs.oracle.com/javase/8/docs/api/java/net/ProxySelector.html> > fits into all of this. > Is this just the concern you've mentioned about how authentication fits in, or is there something more here? > > Any references to "load balancing" should say "client-side load balancing". > I think that "client-side load balancing" is misleading when talking about grpclb, since the actual load balancing code happens on the balancers instead of on the client. But I do take your point here. I've changed it to use the term "per-call load balancing". > > nit: s/internet/Internet/ (is this really where I'm supposed to make > comments like this?) > Done. (I think the intent is to keep all significant design discussion in this thread, but it's probably fine to add comments about minor wording changes in the PR itself.) > > Note that load-balancing within gRPC happens on a per-call basis, not a >> per-connection basis. Because of this, use of a TCP-level proxy may limit >> the ability to do load balancing in some environments. > > > What is that talking about? If the first sentence said "client-side load > balancing" I could agree. But I don't understand what that has to do with > the second sentence. > > It seems like this is getting at something different: we can't resolve the > multiple backends. How about: > > Note that client-side load-balancing within gRPC requires knowing the > addresses of the backends. Because of this, use of a TCP-level proxy may > limit the ability to do load balacing in some environments. > > Thanks -- I like that wording much better. Updated. > > - *All* requests must go through the proxy, both for internal and >> external servers. > > > This is not true. It only applies to external servers. It directly > contradicts the earlier "outbound to the internet." I could maybe agree > with it if it said "may" instead of "must." > My understanding is that if the http_proxy environment variable is set, then the proxy is used unconditionally for all servers, so I think this is accurate. I've updated the wording in the description of this case to make it clear that this is not just for outbound traffic. > > such as the `http_proxy` environment variable or the Java registry > > > What is the Java registry? Do you mean Java system properties? > Probably. :) Updated. > > - For cases 2 and 3, in the subchannel, before we connect to the target >> address, we will call a new *proxy mapper* hook, which will allow >> selectively requesting the use of a proxy based on the address to which the >> subchannel is going to connect. > > > Yeah... that's very C-specific. > > Could you instead define the requirements, like "before each connection is > made, application code can dynamically choose whether to use CONNECT and to > which proxy based on the address of the destination?" You then say, "In C > core, this could be accomplished by..." > Done. > > Note that in case 1, because the client cannot know the set of server >> addresses, it is impossible to use the normal gRPC per-call load >> balancing. It *is* possible to do load balancing on a per-connection >> basis, but that may not spread out the load evenly if different client >> impose a different amount of load. > > > Note that it is possible to use multiple connections through the proxy. > And I'm expecting we'll support such a feature for other use-cases. What > can't happen is the client guaranteeing each connection goes to a different > backend, or using a non-hard-coded number of connections. > I've added a note about the fact that we have no guarantee that multiple connections to the proxy would go to different backends. > > In this case, there will be an external name service record for the server >> name that points to the IP address of the proxy and has the `is_balancer` >> bit set. (Note: We have not yet designed how that bit will be encoded in >> DNS, but that will be the subject of a separate gRFC.) The proxy mapper >> implementation will then have to detect two types of addresses: > > - When it sees the proxy address, it will set the HTTP CONNECT argument to >> the original server name. > > > Eww... So it actually changes the end-host. Note that ability is not > described earlier in the doc when proxy mapper is introduced. Nor is it > made clear here it is an additional feature. > I'm not sure that I completely understand this comment. It's definitely required that we be able to set the argument of the HTTP CONNECT request. Even without case 3, we needed that anyway, because in case 1 we want to use the server name and have the proxy do the name resolution for us, but in case 2 we want to use the IP addresses of the individual backends. (In case 3, we actually have both cases: we want the proxy to do the resolution for us when talking to the balancer, but we want to specify the individual IPs for the backend connections.) In C-core, the channel arg is defined as follows: /// Channel arg indicating the server in HTTP CONNECT request (string). /// The presence of this arg triggers the use of HTTP CONNECT. #define GRPC_ARG_HTTP_CONNECT_SERVER "grpc.http_connect_server" In other words, the presence of this channel arg triggers the use of the HTTP CONNECT handshaker, and the value of the channel arg is the argument to be used in the HTTP CONNECT request. I've attempted to clarify this wording in the document. > > > Why isn't the LB just made public? It can be behind some other type of > load balancer. That's what I had expected when discussing earlier. Yes, > that means there are more auth hurdles, but it seems more sound. > If I'm understanding you right, that is essentially what is being proposed here. The idea is that the grpclb balancer is accessed via the HTTP CONNECT proxy. > > > On Wed, Jan 18, 2017 at 2:12 PM, Mark D. Roth <r...@google.com> wrote: > >> I've created a gRFC describing how HTTP CONNECT proxies will be supported >> in gRPC: >> >> https://github.com/grpc/proposal/pull/4 >> >> Please keep discussion in this thread. Thanks! >> >> -- >> Mark D. Roth <r...@google.com> >> Software Engineer >> Google, Inc. >> > > -- > 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/CA%2B4M1oNAAHhp95%2BMwUsVd0rOVv-arQ7_pQsFdaUoHO9mSsTXQg% > 40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNAAHhp95%2BMwUsVd0rOVv-arQ7_pQsFdaUoHO9mSsTXQg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Mark D. Roth <r...@google.com> Software Engineer Google, Inc. -- 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/CAJgPXp6NqknCamG8arjiTGo2T_X92Ug6%3D77KWV6yT0F4cGHszA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
