<p>Lo de preferir v6 siempre venia de antes de HE, de hecho el trabajo que desemboco en HE vino en parte como respuesta al comportamiento anterior y los problemas que generaba. </p>
<p>Muy buenos tus otros comentarios sobre HE.</p>
<p>Abrazo</p>
<p>Carlos</p>
<div class="gmail_quote">On Feb 18, 2012 12:15 AM, "etrapani" <<a href="mailto:etrapani@unesco.org.uy" target="_blank">etrapani@unesco.org.uy</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Es que la idea de 'happy eyeballs' tal como se hablo en el IETF es<br>
preferir la conexion mas rapida y cachear ese resultado a nivel del<br>
sistema operativo, o de la aplicacion al menos. Ya no es mas el<br>
preferir IPv6 siempre, como era antes.<br>
</blockquote>
<br>
En el draft (miré el histórico, arriba de todo) nunca la opción fue preferir IPv6 siempre, en todas las versiones hablan de encontrar la manera óptima.  Igual en el último (07) le dan una "pequeña ventaja a IPv6" al seguir la preferencia del sistema operativo (manifestada en getaddrinfo()) y la explicación está buena, es para ahorrar tráfico sobre IPv4, porque es de esperar que cada vez haya menos infraestructura dedicada a IPv4 y más a IPv6.<br>


<br>
En MacOSX si anda IPv6 *y también* IPv4, se queda con el más rápido.  No sé si va en línea con el draft.  El ejemplo es que cuando andan los dos dejan caer IPv4.<br>
<br>
Sobre el cacheo, ojo que no es a nivel del sistema operativo, el cache se hace donde sea que se esté resolviendo el happy eyeballs, que puede ser exclusivamente de aplicación (tipo Firefox).  Lo importante es cachear en algún lado para no seguir haciendo todo doble.<br>


<br>
En una versión más vieja que encontré[1] de algo relacionado se habla incluso de ¡elegir entre IPv4, IPv6, TCP y SCTP!<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Esto tiene algunas consecuencias muy interesantes a la hora de<br>
desarrollar aplicaciones web, y me lo encontre cuando estuve<br>
trabajando en la aplicacion del concurso IPv6.<br>
Lo que pasa es que ya no es mas deterministico que stack se va a<br>
usar, lo cual hace que un reload de la pagina pueda venir por un stack<br>
diferente que el usado para la anterior, lo cual altera bastante la<br>
gestión de sesiones en PHP, Django y otros frameworks web.<br>
</blockquote>
<br>
El draft dice en esta sección[2] explícitamente que eso no debe suceder: "While it is tempting to use Happy Eyeballs to maintain responsiveness, web browsers MUST NOT change their Same Origin Policy because of Happy Eyeballs, as that would create an additional security exposure.".<br>


<br>
En particular en Rails no he visto a nadie hablar de ese problema con las sesiones (no digo que no exista, sólo que nunca lo oí mencionar).<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Incluso la<br>
carga de la *misma* pagina termina a veces trayéndose algunos objetos<br>
por v4 y otros por v6. Esto probado con Firefox y Chrome en OSX y con<br>
Chrome en Linux.<br>
</blockquote>
<br>
Si son objetos del mismo servidor, entonces está muy mal implementado o no es por el "happy eyeballs". O sea, si lo detectaste, yo creo habría que reportarlo como bug.  Después que se "rompió" IPv6 en Firefox agarré confianza para eso ;), si querés lo reporto yo.  Hay que tener una versión de navegador y una página donde pase el problema, algo que lo haga reproducible.<br>


<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
En algun momento el comportamiento de happy eyeballs<br>
supongo se va a ir al kernel, que es donde mas sentido tiene que esté.<br>
</blockquote>
<br>
¿En el kernel?  No veo que pueda ir ahí.  Primero llamás a getaddrinfo() y después a connect().  Visto desde el kernel, ¿cómo podrías implementar "happy eyeballs"?  Los pasos del algoritmo te quedan en dos llamadas diferentes.  EL draft en las estrategias sugiere que el kernel recuerde prefijos y direcciones que no conectan.  Eso ayudaría a la aplicación al volver inmediatamente la conexión, pero es eso, una ayuda, no la implementación.<br>


<br>
Para mí, como en MacOSX eso es parte de una biblioteca.  Yo entiendo que adentro del kernel no podés porque connect() ya trae *una* dirección y las alternativas (ipv4 o ipv6) están en espacio de usuario, las tiene la aplicación después de la llamada a getaddrinfo.  Y además no me suena mucho a tarea del kernel andar reintentando y buscando alternativas.  El kernel tiene que crear el socket y hacer el connect con la dirección que el programa le diga,punto.  Lo demás va afuera, creo yo.<br>


<br>
La única que se me ocurre es agregar alguna metafunción que haga el "happy eyeballs", pero más que en el kernel iría en libc, ¿no?  ¿O me estoy perdiendo algo?<br>
<br>
Eduardo.<br>
<br>
[1] <a href="http://tools.ietf.org/html/draft-wing-http-new-tech-00#section-1" target="_blank">http://tools.ietf.org/html/<u></u>draft-wing-http-new-tech-00#<u></u>section-1</a><br>
[2] <a href="http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs-07#section-5.6" target="_blank">http://tools.ietf.org/html/<u></u>draft-ietf-v6ops-happy-<u></u>eyeballs-07#section-5.6</a><br>
<br>
______________________________<u></u>_________________<br>
Uylug-varios mailing list<br>
<a href="mailto:Uylug-varios@listas.uylug.org.uy" target="_blank">Uylug-varios@listas.uylug.org.<u></u>uy</a><br>
<a href="http://listas.uylug.org.uy/listinfo.cgi/uylug-varios-uylug.org.uy" target="_blank">http://listas.uylug.org.uy/<u></u>listinfo.cgi/uylug-varios-<u></u>uylug.org.uy</a><br>
</blockquote></div>