On Fri, Jan 27, 2017 at 12:16 PM, 'Mark D. Roth' via grpc.io < grpc-io@googlegroups.com> wrote:
> Yes. And that seems to agree with how the different proxy choosing logic >> will work; the first primarily consumes hostnames and returns proxy >> hostnames (which is http_proxy in C) and the second one primarily consumes >> IPs and returns proxy IPs. >> > > I don't think that's actually entirely correct. The first case doesn't > consume anything; it unconditionally sets the hostname to be resolved. > The first case will consume a hostname in Java. Observing the hostname is necessary to fix the mixed internal/external in an expanded view of case 1. Since the Java APIs support that mixed case, Java ends up needing to support them. And if C ever needed to support the mixed case (which seems likely to me), then it would also need to use the hostname. > And the second case can consume either the hostname or the IP. > And I wouldn't be surprised if only IP were used. We're not aware of a user of it. This is more philosophical than practical, > My further explanation there was meant to be more philosophical, as an explanation that this "special case" is pretty normal and sort of agrees with the rest of the design. But that philosophical debate aside, I think that we should focus on case >>> 3, because that's a concrete case that we do want to support. So far, at >>> least, I have not heard a workable proposal that does not require the proxy >>> mapper to control the CONNECT argument (although I'm certainly still open >>> to new proposals). >>> >> >> I've provided two proposals. Neither of which seem debunked as of yet. I >> could totally agree they may be worse than what you are proposing, but the >> discussion hasn't gotten to that point. The mentioned security issue of the >> first proposal seemed to ignore the fact that a reverse proxy could be used >> to "protect" the LB, in an identical fashion to any forward proxy. >> > > I don't quite understand the proposed reverse proxy approach. Can you > explain how that would work in more detail? > Case 3 as stated today (for contrasting) 1. client wants to connect to service.example.com 2. do DNS SRV resolution for _grpclb._tcp.service.example.com; you find it is a LB with name lb.example.com 3. do a DNS resolution for lb.example.com, get IP 1.2.3.4 4. ask the proxy mapper about IP 1.2.3.4, it recognizes the IP as the proxy and says to use "CONNECT service.example.com" via proxy IP 1.2.3.4 5. connect to proxy 1.2.3.4, it performs internal resolution of service.example.com and connects to one of the hosts Case 3 using reverse proxy for LB 1. client wants to connect to service.example.com 2. do DNS SRV resolution for _grpclb._tcp.service.example.com; you find it is a LB with name lb.example.com 3. do a DNS resolution for lb.example.com, get IP 1.2.3.4 4. (different starting here) connect to 1.2.3.4, which is a transparent reverse proxy 5. Perform an RPC to 1.2.3.4. Host header is lb.example.com. The proxy performs internal mapping of lb.example.com to internal addresses and connects to one of the hosts, forwarding the RPC. I agree that case 3 requires different parts of the system to be > coordinated. For example, assuming that your proxy mapper implementation > is getting the list of proxy addresses from a local file, you would need to > first push an updated list that contains the new proxy address to all > clients. Then, once all clients have been updated, you can add the new > proxy to DNS. > And the file needs to contain old proxy addresses that should be used for detection but not be used. Okay. So we're on the same page there. I agree that this is cumbersome, but I think it's an inherent problem with > case 3, because you need *some* way to configure the clients. > I agree you need to be able to configure the clients. I understand that something needs to tell the client what to do. My concern was the pain of updating the proxy mapping list in concert with name resolution. And because of that I would recommend implementors to use the magic IP, because it has less operational overhead and less likelihood of failing. If you assume "one proxy" which has "one static IP" and everything is >> hard-coded, then the design is fine. But that seems unlikely to describe a >> productionized system. And that's why I would feel forced to use the "magic >> IP" that it seems you have previously rejected. >> > > There are a couple of reasons that I don't like the "magic IP" approach. > First, it requires writing a custom resolver in addition to a custom proxy > mapper, > No, I'd just have DNS return the trash IP. I'm not a big fan of "sentinel" values, since it's often hard to find a > value that will never be used in real life. > I would gladly accept a magic value instead of needing to make sure two systems stay in sync and rollouts happen properly. And I would quickly recommend that to others. And if I started explaining the gotchas of the alternative, I'd expect them to quickly be thankful for the recommendation since it is less code to write and less operational complexity. -- 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%2B4M1oPLVHkdvVbMyHZyz9xN6XJN38SesSYacErvGU5H9KBv1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
