Patrick's idea is the happy eyeballs approach (see related work on IPv6 by Dan Wing et al). You're right, tho, that you probably can't do it in a single packet, but multiple rapid fired. That solves the issue you raise below. Eliot On 8/15/12 8:23 PM, William Chan (陈智昌) wrote: > I'm confused by this comment. My understanding is that multiple > questions per query does not work in practice. Also, how does the > response work? If the A record is cached, but the SRV record is > uncached, does the server not respond to the client until the SRV > record comes back? Or does it stream the records back somehow and have > the client block on responses? > > Patrick's explanation makes more sense to me. > > > On Wed, Aug 15, 2012 at 10:40 AM, Eliot Lear <lear@cisco.com > <mailto:lear@cisco.com>> wrote: > > > On 8/15/12 7:19 PM, William Chan (陈智昌) wrote: >> Can you elaborate how SRV would work here from a client >> perspective? Do you propose making the client block on the SRV >> lookup? Or are you proposing doing this out of band and switching >> to HTTP/2.0 if we discover support? > > Block is the wrong word. You're already doing A-Record queries. > Adding another record in the question only adds latency if you > must serially query. Also, I myself am not convinced that SRV > records are sufficient to the task. For instance, what happens if > there is a port # in the URL? How do you identify the version #? > > Paul Hoffman did some work on a draft that sort-of looked at this > problem. I'm going to guess that he stopped short because of > potential downgrade attacks. > > Eliot > >
Received on Wednesday, 15 August 2012 18:42:05 UTC