Caida del Skype

El pasado 16 de agosto Skype sufrió una caída de dos días que dejó sin servicio a miles de usuarios. El caso ha tenido mucha repercusión en los medios por la popularidad del servicio y por el tiempo que se extendió. Skype explicó que la disfunción se debió a un reinicio masivo de los ordenadores de los usuarios causada por una actualización de Windows Update. Skype quiso dejar claro que el problema no era de Windows, sino de un fallo que desconocían en su programa, que salió a la luz cuando miles de ordenadores volvieron a conectarse al servicio de Skype a la vez, creando una avalancha de conexiones que llevaron a que Skype dejara de funcionar.

¿Se podría haber evitado la caída?
Desde Skype nos mandan un mensaje tranquilizador asegurándonos de que han solucionado el problema y que el sistema es capaz de manejar tantos intentos de conexión simultáneos como los ocurridos el 16 de agosto. Pero en HighScability se preguntan si el fallo fue de Skype o de la estructura de los sistemas P2P.

¿Cómo funciona Skype internamente?

Poco se conoce sobre el funcionamiento real de Skype porque es un protocolo propietario y de código cerrado, que además cifra sus comunicaciones, aunque hay análisis de ingeniería inversa sobre el protocolo de Skype que lanzan algo de luz El funcionamiento de Skype es similar al de otras redes P2P como la que usa eMule en la que los usuarios (llamados Peers) son los que aportan los recursos de su ordenador para que la red funcione. Prácticamente hay un único punto que sí se gestiona desde los servidores de Skype: el proceso de login. Y ese es el cuello de botella, o dicho de otra manera, un punto débil del sistema.

Cuanta más gente se una a la red de Skype más recursos se necesitarán (habrán más registros, más llamadas…). La ventaja de los sistemas P2P es que todos los usuarios comparten recursos, y así resulta sencillo que se puedan incorporar más usuarios a la red (se necesitarán más recursos pero serán ellos mismos quienes se los “prestan” unos a otros). En una red con millones de usuarios como Skype, usar esta estrategia parece lógico.

¿Qué problemas tiene Skype con P2P?
Aunque Skype funciona bien, las arquitecturas P2P tienen varios problemas, aunque nos centraremos en uno concreto que es el que ha sufrido Skype: los usuarios están contínuamente entrando y saliendo de la red, problema conocido como

churn (no encuentro traducción en castellano). Es una propiedad intrínsica de todas las redes P2P, no se puede evitar sólo minimizar. Es este dinamismo de las redes P2P (los usuarios pueden entran y salen contínuamente) uno de los mayores problemas a los que se enfrenta, y en el caso de Skype este problema se agravó debido a las miles de personas que utilizan simultáneamente su servicio.Seguramente el sistema no estaba preparado para una desconexión y reconexión masiva de usuarios.

Otro problema es la

dificultad de hacer pruebas en el sistema. Cuando se desarrolla un programa se prueba haciéndolo soportar el número de usuarios que aproximadamente se espera que lo usen, pero Skype puede tener más de 1.000.000 de usuarios conectados a la vez, ¿cómo se hace una prueba tan grande? Es prácticamente imposible. La solución es hacer simulaciones, pero no sabrán cómo responde el sistema hasta que no estén realmente conectado el millón de usuarios.

¿Tenemos que desconfiar de Skype por esta caida?
En absoluto. Skype es uno de los mejores

protocolos P2P que existen y soluciona muchos problemas de conexión que otros sistemas P2P no han logrado (no es la finalidad de este artículo entrar en detalles demasiado técnicos).

Skype lleva muchos años funcionando y apenas ha dado problemas. El sistema es capaz de tener online más de un millón de usuarios al mismo tiempo y eso es digno de admiración. Skype es estable, da buenos resultados y no hay por qué temer.

¿Podríamos mejorar Skype?
Ahora surge otra pregunta: Skype usa un protocolo propietario cerrado. ¿Se habría podido detectar antes el fallo (y evitarlo) si se basara en estándares abiertos (como

Gizmo)?