<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Remi,<div><br></div><div>Many thanks for taking a deep look into the proposed change, and sending us your detailed feedback.</div><div><br></div><div>Regarding your comment with respect to "getaddrinfo()" usage, the on-line <a href="http://www.regatta.cs.msu.su/doc/usr/share/man/info/ru_RU/a_doc_lib/libs/basetrf1/getaddrinfo.htm">POSIX reference</a> I found states this:</div><div>"<span class="Apple-style-span" style="font-family: Times; ">If the query is successful, a pointer to a linked list of one or more addrinfo structures is returned via the fourth argument."</span></div><div>This basically means to me that all DNS records matching the requested domain name will be returned, and in case this normative definition is not enough, let me assure you that I have tested the "smart connect" code under several operating systems including MacOS, Ubuntu and Windows XP, and all of them with no exception followed the normative requirement and returned all matching address records in the returned linked list. I did not however have an opportunity to test it with a DNS name that has a mix of "A" and "AAA" records for the same domain (server) name.</div><div><br></div><div>I have reviewed the "Happy Eyeballs" IETF draft you referenced with great interest, and I think it is a rather impressive body of work. However, I do not agree with paragraph 4.1 and its justification. The authors assume that the user of the computer is sufficiently competent to configure the address policy, and thus puts precedence on reducing load on some network elements (i.e. machines). In my experience the human will invariably be the weakest link, and cause for misconfiguration that will result in malfunction. To always put preference on IPv6 does not seem to me like the proper solution either. One should anticipate that in a dual-stack scenario one of the two stacks may not be properly configured and there will be connectivity issues. Hence <u>statically</u> selecting one protocol version over the other in failures and usability issues requiring competent manual intervention. It seems the authors of the "Happy Eyeballs" have not considered an option of automatically selecting the best of the two protocol versions in a fully dynamic manner, which is at the core of our proposition.</div><div><br></div><div>If however you remain unconvinced, an option to <u>filter the result</u> returned by "getaddrinfo()" based on protocol family can be easily added to comply with static protocol precedence, which will reduce the effectiveness of "smart connect" to a degree, but not entirely, as it will still be able to dynamically select the <u>closest server</u> in a given protocol family.</div><div><br></div><div>The issue if effectively directing client traffic to a server that is closest to it in terms of network topology has been around for many years, but mostly it was addressed from the server side, e.g. by adjusting the order of address records returned by DNS (assuming that clients will attempt in-order connection), but these have many shortcomings and can never be as precise or as optimal as this client-centric approach.</div><div><br></div><div>May I also add that a similar concurrent-connect approach has been successfully deployed in several IPTV networks to date,  and it is even more potent for OTT scenarios where the network topology is much more diverse in distance and performance.</div><div><br></div><div>Thank you for your consideration,</div><div>- Leonid Rosenboim</div><div>  Founder, CERTARETE<br>
<br><div><div>On Aug 27, 2011, at 1:58 AM, Rémi Denis-Courmont wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><span class="Apple-tab-span" style="white-space:pre">     </span>Hello,<br><br>Le samedi 27 août 2011 03:36:44 Kiran Kotla, vous avez écrit :<br><blockquote type="cite">       Here is a patch that makes the net_Connect function connect<br></blockquote><blockquote type="cite">to the fastest server attempting to connect to multiple servers from<br></blockquote><blockquote type="cite">DNS resolution in parallel by making the sockets non-blocking and<br></blockquote><blockquote type="cite">using select to choose the best among them. We call this new<br></blockquote><blockquote type="cite">mechanism 'smart connect'. It also stores the fastest server from the<br></blockquote><blockquote type="cite">previous resolution of a DNS name into a cache (with a configurable<br></blockquote><blockquote type="cite">timeout) and connects to it directly without performing DNS resolution.<br></blockquote><br>Is there any OS that returns more than one addrinfo structure per family per <br>protocol? As far as I know, if the DNS query returned multiple addresses in <br>the same familty, getaddrinfo() picks one pseudo-randomly. This being the <br>case, this patch will basically change the logic to determine which of IPv4 or <br>IPv6 is used, right?<br><br>That is covered by <a href="http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs">http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs</a> <br>and I suspect your proposed implementation does not adhere to the address <br>policy, as required by §4.1. Of course, this is only a draft, but I doubt this <br>requirement is ever going to be dropped. Probably the simplest solution is the <br>short timeout reportedly implemented by Chrome and Firefox (§6.0).<br><br>I am also not sure that caching DNS lookups in VLC is a good idea. VLC does <br>not know the lifetime of the DNS responses, so it cannot perform correct cache <br>expiration. DNS cache really ought to be maintained by the DNS resolver, and <br>indeed some operating systems do have a caching resolver (e.g. nscd on Linux).<br><br>(...)<br><blockquote type="cite">      The patch file is attached. We would appreciate any comments or<br></blockquote><blockquote type="cite">suggestions on the changes described.<br></blockquote><br>* net_Connect() normally returns sockets in non-blocking mode.<br><br>* select() is not used due to design bugs (FD_SET() does not check for buffer <br>overflow). poll() is used instead.<br><br>* net_Connect() is thread-safe. It cannot use unprotected non-constant global <br>data.<br><br>* strerror() is forbidden in VLC code base due to not being thread-safe.<br><br>* memset() is preferred over bzero().<br><br>* Identifiers with leading underscores are deprecated due for conformance with <br>the C standard.<br><br>-- <br>Rémi Denis-Courmont<br><a href="http://www.remlab.net/">http://www.remlab.net/</a><br>http://fi.linkedin.com/in/remidenis<br></div></blockquote></div><br></div></body></html>