On Tue, Jan 31, 2017 at 10:11 AM, Eric Anderson <ej...@google.com> wrote:

> On Fri, Jan 27, 2017 at 3:41 PM, Mark D. Roth <r...@google.com> wrote:
>
>> On Fri, Jan 27, 2017 at 1:31 PM, Eric Anderson <ej...@google.com> wrote:
>>>
>>> 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
>>>
>>> That's not actually an accurate representation of how case 3 is proposed
>> to work in the current document.
>>
>
> Oh, sorry. #4 and 5 should have used lb.example.com instead of
> service.example.com. That seems to be the only changes you made.
>

Well, I also added a few additional steps after step 5, but perhaps they
are less relevant to the current discussion.


>
> Just thinking out loud here about whether there's another alternative --
>> this is a purely brainstorming-level idea, so please feel free to shoot
>> holes in it.  What if we had another type of SRV record specifically for
>> HTTP CONNECT proxy use?
>>
>
> I considered something of that ilk, but wasn't very excited. I do agree it
> could work. I don't think we want a separate SRV for it, because that means
> another lookup for *all* clients for this one rare case.
>
> But maybe we could shoe-horn it somewhere. Like service config. Probably
> icky.
>
> This does have the advantage that it can be rolled out seemlessly, without
> an update to the client.
>
>
>>    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 DNS SRV resolution for _grpc_proxy._tcp.lb.example.com; you
>>    find it is a proxy with name proxy.example.com
>>
>> Whoa. So do a SRV for the *LB*. I didn't quite expect that as it goes a
> bit against normal SRV, but it makes sense. It's interesting. Again, for
> reasons above, I don't think we want to go with this, but it does seem like
> it could work.
>

Yeah, it seems a bit unnecessarily complex to me, too.


So I think this leaves us with the current design.  I've added a note to
the doc explaining the need for coordination between the resolver and the
proxy mapper for case 3.

-- 
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/CAJgPXp7OaXo30cbX-Y8xR%2Bnkvm1%2Bm20zCD_pdnHJ-Ov5A_Dcjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to