Sobre SP2 y las redes P2P

Están circulando por la red noticias sobre el SP2 debido a la limitación que impone del número de conexiones TCP/IP, la cual, según esos informes, impide o limita el uso de programas P2P.

A pesar de que yo no soy partidario del uso que se da a los programas P2P y nunca doy soporte a los mensajes sobre ellos, creo que merece la pena aclarar el punto de la limitación de las conexiones del SP2 y su posible influencia en los programas P2P.

La noticia que circula por la red es mentira, simplemente porque, o bien a propósito, o bien por desconocimiento de lo que hablan, es *incompleta*: Windows XP SP2, por motivos de seguridad y para impedir o limitar la reproducción de gusanos estilo Blaster y Sasser, efectivamente limita a 10 el número de conexiones salientes TCP/IP.

Veamos un poco la frase anterior: cualquier técnico en redes y TCP/IP, ante esa frase, simplemente diría: Windows XP no puede navegar en Internet. No puede funcionar en redes. 10 conexiones es un número ridículo para cualquier cosa. No es posible que Microsoft, ni nadie, haya puesto esa limitación

Realmente la noticia anterior es mentira: la frase exacta (que no la he visto todavía en ninguna de esas páginas de mentideros de la red) es: Windows XP SP2 limita a 10 el número de apertura de sockets salientes POR SEGUNDO siempre y cuando sean además AL MISMO PUERTO DESTINO.

Ligera matización... que cambia totalmente el panorama. Es decir, por ejemplo impide que un gusano que use las maneras de reproducirse del Blaster y Sasser, que en la actualidad abren miles de conexiones por segundo al mismo puertos destino (puertos RPC), sea capaz de reproducirse con la celeridad con que lo hicieron los gusanos anteriores en su día.

Esto no limita en absoluto los programas P2P. Veamos el por qué: los programas P2P abren conexiones normalmente al mismo puerto destino, ya que los usuarios no suelen tocar el número de puerto que usan (es configurable), por lo que normalmente podemos afirmar que un 99% de las máquinas tienen el puerto por defecto (4662 TCP). Los usuarios pueden configurar cualquier puerto del 1024 al 65535, por lo que puede haber una distribución del rango de puertos que haría improbable el conectarse siempre al MISMO puerto.

Pero, y lo mas importante: el propio eMule sólo permite 20 conexiones cada 5 segundos (4 por segundo) -configurable también, pero este es el valor por defecto-, por lo que el SP2 permite incluso 2.5 veces más de conexiones que lo que necesita el propio programa P2P. La limitación de las conexiones por segundo es muy normal en todos los programas TCP/IP, sean o no programas P2P, ya que en otro caso, se corre peligro de saturar las conexiones en la pila TCP, debido precisamente a los time-out de las conexiones finalizadas y que existen tal y como está definido en las RFC del TCP/IP (las normas TCP) que respetan al pie de la letra todos los sistemas operativos, sean o no de Microsoft.

¿Conclusiones?: noticia tergiversada a propósito, bien por mala fe, o bien por incultura de los que publican dichos artículos. Meditad sobre la calidad de las páginas que difunden dichas afirmaciones.

Por otra parte, este parámetro del número de conexiones por segundo, está 'hardcoded'. Es decir, está implementado en el driver TCP/IP y no puede configurarse en el registro de Windows (otra información incorrecta de algunas webs).

Igualmente en otras páginas, se ha difundido un "fix" para parchear el driver tcpip.sys de Windows.
Por ejemplo: http://www.lvllord.de/
Evidentemente el tocar "a pelo" un driver del propio sistema operativo implica quedarse sin soporte del producto. Esto puede que no haga meditar a las personas que lo instalan, pero que se planteen igualmente un par de cuestiones:

* ¿por que montar una cosa que no es necesaria ya que el programa P2P necesita por segundo la cuarta parte de conexiones por segundo que el SP2 le permite?

* ¿por que usar un "fix" de procedencia dudosa que puede meternos cualquier otro "regalo" en nuestra máquina?. Recordemos, que si únicamente el fix hace lo que dice hacer, también podemos hacerlo nosotros "a mano" con un editor hexadecimal sobre el propio driver -un proceso totalmente elemental-.

Meditad sobre lo anterior...

--

José Manuel Tella Llop jmtella@compuserve.com

31 - agosto - 2004