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.
Any references to "load balancing" should say "client-side load balancing". nit: s/internet/Internet/ (is this really where I'm supposed to make comments like this?) 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. - *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." such as the `http_proxy` environment variable or the Java registry What is the Java registry? Do you mean Java system properties? - 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..." 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. 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. 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. 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. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
