On Wed, Jan 25, 2017 at 2:00 PM, Mark D. Roth <r...@google.com> wrote:
> 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? > It wasn't an auth issue. It's more of an issue of needing to work with pre-existing APIs and expectations. We will, for example, be able to support a mixed CONNECT usage in case 1. I wouldn't be surprised if you need to eventually as well. That is what wpad.dat <https://en.wikipedia.org/wiki/Web_Proxy_Auto-Discovery_Protocol> solves, after all. 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". > Moving discussion to PR. - *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. > That's conflating two things: the environment and the configuration. Your description of the environment is not true. When in this environment we expect the http_proxy environment variable as the form of configuration, but that has no impact on how the environment actually behaves. 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. > I'm not certain there's a fundamental need for special behavior between case 1 and 2 concerning the CONNECT string, but in any case, I don't see why the *proxy mapper* must do it. I'd expect the proxy mapper to return one of two things: - no proxy needed - use CONNECT with proxy IP x.x.x.x That gives the mapper the control it needs without opening the ability to do outrageous things. I think "when it sees the proxy address" also has fundamental issues, like requiring the proxy to have a hard-coded stable IP. That means you couldn't add a new proxy to the rotation if experiencing too much load. More likely, in your scheme, I'd expect the "proxy address" to become 100% fake. "Oh! It's 1.1.1.1! That's our secret code for proxy address." 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. > No. I'm proposing that case 3 is the same as case 2, but with a different server configuration. Case 1 would use the hostname in CONNECT. Case 2 would use IP in CONNECT. If I want Case 2, but don't want to expose internal IP addresses to unauthenticated clients, I'd just make GRPCLB public and connect to it directly, without CONNECT. DNS returns public IPs, and the GRPCLB communication can be authenticated. -- 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%2B4M1oN%3DqjqQx9sXWEmwRYjTyw1Z3ZLMfLa%2B_NFRLFof8Jgnxw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
