Sergio arranco con el tema, y me genero «lembrancas» de cuando tuve la «suerte» de visitar por temas laborales los laboratorios de la NASA. Digo «suerte» porque en realidad fui con bastante estres a arreglar algunos bugs en equipos que les habiamos vendido, pero termino siendo una experiencia alucinante.
Fue por fines de los 80 o principios de los 90, la NASA habia comprado equipos de FDDI nuestros para su red interna de datos, los equipos a mi entender funcionaban perfecto, y ya teniamos muchos clientes contentos, la NASA compro, y su departamento de testing los testeo por un par de meses y nos mando su reporte, habian encontrado mas de 40 bugs!
Cuando quise reproducrilos para arreglarlos en nuestros laboratorios me encontre con que simplemente era imposible reproducir la mayoria de las situaciones, por lo que tuve que tomar el avion y pasar un par de semanas en sus laboratorios de Langley Virginia.
Ahi me encontre con una cultura totalmente diferente:
– Segun ellos nuestro equipo era el primer equipo de datacom que compraban en la historia, todo lo demas era desarrollado inhouse (routers, switches, etc), y recientemente habian llegado a la conclusion de que no era viable
– Para poder testear nuestros equipos habian desarrollado ellos mismos hardware para testear escenarios extremos, que practicamente era mas dificil de disenar que nuestros equipos mismos
– Para dar un ejemplo, habia un escenario en que el equipo de ellos generaba paquetes que terminaba dejando a nuestro equipo totalmente sordo, yo les argumentaba que me resultaba muy dificil de creer ya que habiamos testeado todos los escenarios imaginables. Pero (obviamente) en su lab me mostraron que si pasaba, despues de cierto debugging juntos (la verdad es que los tipos eran super buena onda, y muy dispuestos a colaborar) encontramos que el bug se generaba cuando mandaban un paquete de ethernet de 4096 bytes (segun la especificacion de Ethernet el paquete maximo era de 1518 bytes, y la verdad es que no habia en ese momento chips de Ethernet que supieran enviar paquetes de ese tamano, y ni nosotros ni el fabricante del chip habiamos nunca imaginado que alguien mande un «monster packet», como le decian ellos).
Me acuerdo de ese ejemplo, pero como ese hubo muchos, como quien dice, «me llenaron la cara de dedos», pero con la ayuda de ellos, testeamos escenarios inimaginables y armamos un producto recontra robusto, y reforzo lo que despues seria parte de mi filosofia de diseno de productos de redes: «al momento de transmitir hay que ser mas papista que el papa, ya que el minimo error puede hacer caer algun equipo de la red, y al momento de recibir hay que ser super tolerante y aceptar que puede llegar cualquier porqueria y bancarsela», en cualquiera de los dos casos, si la red cae, la culpa es tuya, al cliente le importa poco y nada que el producto taiwanes que tiene del otro lado no cumple con las especificaciones, o en otras palabras, «la policia de protocolos no existe, y a quejarse al cuartito» (hoy es obvio, pero 30 anios atras, en un mundo dominado por IBM y DEC, donde las redes eran en su mayoria muy homogeneas, no era tan obvio)
Una ultima anecdota de mi visita a la NASA, para entrar tuve que mandar mis datos 1 mes antes, y pasar un Security Due Diligence, cuando llegue y mostre mi pasaporte Uruguayo, me dicen: » con este pasaporte no precisabas todos ese due diligence» (????!!!!!), una de dos o Uruguay tenia un acuerdo de cooperacion tecnologico con la NASA o nos consideraban totalmente inofensivos 😉
Read Full Post »
Pablo Brenner & Sergio Fogel Blog 