El trabajo de un desarrollador no siempre es escribir código, sino que la mayor parte del tiempo se trata de leer el código, tratar de entenderlo y descubrir por qué lo que estás intentando hacer no funciona, muchas veces podemos tardar horas, días o incluso semanas tratando de depurar algún error, y a veces ni siquiera nosotros nos damos cuenta de que existe un error, podría ser que algún usuario, otro colega o un gerente nos reporte el error que está ocurriendo. Por supuesto que esto puede ser vergonzoso, pero el caso del correo de las 500 millas es más curioso que cualquier otra cosa.
Antes de continuar, puedes leer este post o ver y escuchar esta información en formato de video en nuestro canal de Youtube, te dejamos el link por si prefieres este formato. 😃 👍
Hola mundo, y bienvenidos a este post.
Este es un caso que puede parecer imposible, pero como cuenta Trey Harris, yo al menos creo que pudo haber pasado, quizás los datos pueden ser un poco inexactos para hacer la historia más interesante, pero seguro que, si al menos esta historia no es cierta, al menos te va a entretener.
Hace algunos años, Trey se encontraba trabajando en una universidad, él era el encargado de gestionar el servidor de correos cuando el director del Departamento de Estadísticas lo llamó.
-«Estamos teniendo problemas para enviar correos desde nuestro departamento»
-«¿Cuál es el problema?»
-«No podemos enviar correos electrónicos a más de 500 millas de distancia.»
-Trey se quedó en blanco y le preguntó nuevamente.
-«No podemos enviar correos a más de 500 millas, de hecho un poco más, digamos que 520 millas pero no más que eso.»
-Trey trató de decirle que así no es cómo funcionan los correos electrónicos, que lo que hacía pensar que podría fallar por eso.
-El director insistía, no es lo que él pensaba que sucedía, sino que lograron demostrarlo, y se dieron cuenta hace unos días.
-Trey saltaba de su silla y decía: «¿Se dieron cuenta hace unos días y no podían enviar correos?»
Y el director le reafirma: «sí podemos enviar correos, pero no a más de 500 millas. No te lo comunicamos antes, ya que necesitábamos tener la suficiente cantidad de datos para poder afirmar nuestra hipótesis, donde incluso geo estadísticos tuvieron que participar.
La geo estadística es una rama de la geografía matemática y, por tanto, también de las ciencias de la tierra, que se centra en los conjuntos de datos de la superficie terrestre. Esta ciencia se desarrolló para operaciones mineras, pero en la actualidad se utiliza en ciencias como oceanografía, geoquímica, climatología entre otras cosas.
Las pruebas
Los geo estadísticos recolectaron estos datos y trazaron un mapa donde se percataron que solo podían enviar correos hasta un poco más de 500 millas a la redonda, había un número de localidades que no podemos contactar o podemos, pero solo esporádicamente dentro de este radio, pero no podemos contactar a nadie más a una distancia mayor a este radio.
Esto, ya se empieza a volver sumamente sospechoso, y quizás también sumamente difícil de depurar, a menos que sepas exactamente qué está ocurriendo, es muy probable que esto tome mucho tiempo de depurar, pero Trey, oooh no, a él no le tomó tanto tiempo.
-«¿Cuándo empezó a ocurrir esto?»
-«Cuando vino el consultor a parchar el servidor y lo reinició, pero lo llamamos y nos dijo que el no tocó la el sistema de correos.»
Acá Trey lo primero que hizo fue revisar que no fuese el April fool’s day para descartar que no le estuviesen haciendo una broma, pero para su desgracia este caso estaba ocurriendo.
Trey inició sesión en el servidor del Departamento de Estadísticas y empezó a enviar correos de prueba. Empezó a enviar correos, todos a localidades que se encontraban a menos de 500 millas y todos estos correos se enviaron con éxito, así que después de eso hizo la prueba, envió un correo o Memphis, que se encontraba a 600 millas de donde él se encontraba.
Y el correo falló.
Probó con Boston, otra localidad a más de las 500 millas
Y falló también
Nueva York, a 420 millas, funcionó perfectamente, y luego lo envió a Providence que se encontraba a 580 millas.
Y… este fallo también.
Lo siguiente que hizo fue preguntarse si había perdido su sanidad mental, empezó a enviar correos a amigos que se encontraban en carolina del norte pero que sus ISP se encontraba en Seattle, y afortunadamente este falló. Si el problema hubiese tenido que ver con la localidad física de la persona y no del servidor de correos Trey hubiese estallado en llanto, afortunadamente este no era el caso.
Habiendo establecido esto, se confirmo que el error era cierto y reproducible, cosas que son necesarias por nosotros los desarrolladores para poder solucionar. Pero en este caso, ¿se te habría ocurrido a ti como solucionar este error?
Encontrando la solución
Trey empezó a revisar el archivo de configuración de sendmail, el, cual es un agente de transporte de correo en internet y se encarga de encaminar los mensajes o correos de forma que estos lleguen a su destino, y lo comparó con uno que tenía de respaldo.
Y estos eran iguales, hasta que se dio cuenta de algo importante, SunOS, el cual era el sistema operativo que se estaba utilizando, en esa epoca tenía algo particular, este venía con lo versión 5 de sendmail, incluso cuando ya se habia liberado hace bastante tiempo la versión 8, el archivo de configuración de sendmail que Trey tenía se encontraba escrito para la versión 8 y muchos de estos parametros no funcionaban en la versión 5, además, la versión 5 cuando no lograba identificar una configuración dentro de este archivo en lugar de fallar lo que hacía era ignorarlo, haciendo más dificil la depuración.
Aparentemente, el consultor que parcho el servidor actualizó la versión del sistema operativo y, de esta manera, instalando también el agente de transporte de correos que este tenía, haciendo un downgrade de la versión 8, que se encontraba instalada con anterioridad a la versión 5. Esta actualización no tocó el archivo de configuración, pero sí instaló una versión incorrecta de sendmail.
La versión 5 de sendmail no tenía valores por defecto para muchas de sus configuraciones, las cuales cambiaron de nombre para la versión 8, por lo que si no encontraba un valor en el archivo, tomaría el valor de cero.
La configuración que tomaba el timeout para conectarse al servidor remoto de SMTP también tomaba el valor de cero. Luego de un par de pruebas, se dio cuenta de que en promedio el servidor tomaba 3 milisegundos en realizar este timeout por la carga que este tenia. Una característica bastante peculiar del campus de la universidad es que se encontraba comunicada 100% por switches, por lo que un paquete de salida no se tomaría como un retraso en la señal hasta que alcanzara el servidor en el otro lado, por lo que con una baja carga en el servidor haría que el viaje del paquete fuese prácticamente a la velocidad de la luz, y un timeout de cero haría que la conexión se abortara solo un poco por sobre estos 3 milisegundos.
Así que Trey ingresó a su terminal y escribió en su terminal gunits:
Y también te dejamos un comentario hecho por Miguel Angel en el canal de YouTube explicando esto: usa «GNU Units» o gunits para convertir distintas medidas. «3 millilightseconds» es la distancia que recorre la velocidad de la luz en 3 milisegundos, en este caso 558 millas. Como ese era el time out del servidor, el mensaje fallaba porque la distancia estaba por encima de ese valor.
Y esto ha sido todo de este post, si te ha encantado, ¡golpea al botón de me gusta!, dejanos un comentario, y visita nuestra Academia Hola Mundo, donde encontrarás todos los cursos para formarte como un desarrollador o desarrolladora.
Y para no perderte nada, no olvides suscribirte a este blog, seguirnos en todas las redes como Youtube, Twitter e Instagram, y por último, te invitamos a escuchar nuestra música «Hola Beats«, diseñada para ayudarte a concentrarte y acompañarte en tu aprendizaje o trabajo, la puedes encontrar en Spotify, Apple Music, Amazon Music, Youtube Music y Deezer.
¡Hasta la próxima!, y chao mundo
Deja un comentario