Spolsky alerta sobre la creciente tendencia de muchas universidades a sobre-simplificar la currícula de las carreras de Ciencias de la Computación (con Java como “lenguaje insignia”), con el único objetivo de producir mayor cantidad de egresados y en menos tiempo. La consecuencia es directa: cada vez más abundan programadores que poco entienden de conceptos de programación (corrección, recursión, complejidad, paralelismo, entre tantos otros) y para los cuales los mecanismos “internos” de los sistemas informáticos (gestión de memoria, interacción con el sistema operativo, comunicación entre procesos, etc.) son completamente esotéricos.

El principal impulsor de este embrutecimiento es cierto sector de la llamada “Industria del Software” que requiere de mano de obra barata y de pobre formación, y empuja a las instituciones educativas a proveerles “recursos” tan rápido y en tanta cantidad como sea posible (ni qué decir de las instituciones educativas que ceden a esta presión).

Nadie está en contra de hacer la tarea del programador más simple, ni mucho menos de la evolución de los lenguajes y las metodologías de desarrollo de software. Lo que se reprocha aquí es la negación de la realidad como forma de evasión. Esto es: la necesidad de dotar a los programadores de ciertos conceptos, aún cuando esto provoque la deserción de quienes no puedan llegar a dominarlos (y mal que le pese al referido sector de la “Industria”).

Los Riesgos de las Universidades-Java

por Joel Spolsky
Jueves 29 de diciembre de 2005

Chicos perezosos.

¿Qué pasó con el trabajo duro?

Un seguro indicio de mi decadencia hacia la senilidad son mis continuas quejas y lamentos sobre “los chicos de hoy”, y cómo ya no quieren o no pueden hacer cosas difíciles.

Cuando yo era un muchacho, aprendí a programar con tarjetas perforadas. En esos tiempos si cometías un error, no tenías ninguna de esas modernas funciones como la tecla “backspace” para corregirlo. Tenias que tirar la tarjeta y empezar todo de nuevo.

Cuando empecé a entrevistar programadores en 1991, les dejaba usar generalmente cualquier lenguaje que quisieran para resolver los problemas de programación que les planteaba. El 99% de las veces, ellos elegían C.

Ahora ellos tienden a elegir Java.

No me malinterpreten: no hay nada malo con Java como lenguaje de implementación.

Un momento, quiero rectificar eso último. No digo, en este artículo en particular, que haya algo de malo con Java como lenguaje de implementación. Hay un montón de cosas mal con Java, pero tendrán que esperar hasta otro artículo.

En cambio, lo que quiero decir es que Java no es, generalmente, un lenguaje de programación lo suficientemente difícil para que pueda ser usado para distinguir entre excelentes programadores y programadores mediocres. Puede ser un buen lenguaje para trabajar, pero ese no es el tema de hoy. Puedo ir incluso mas allá y decir que el hecho de que Java no sea lo suficientemente difícil es una característica, no un bug, pero que tiene ese problema.

Si puedo ser atrevido, diría que en mi humilde experiencia han sido dos las cosas tradicionalmente enseñadas en las universidades como parte de la carrera de Ciencias de la Computación (CS) las que mucha gente nunca llega realmente a comprender: punteros y recursión.

En aquellos tiempos lo normal era empezar la universidad con un curso de estructuras de datos, con listas enlazadas, tablas hash y, por qué no, con un uso intensivo de punteros. Esos cursos eran frecuentemente usados como filtros: eran tan difíciles que cualquiera que no pudiera soportar el desafío mental de un grado en CS se daría por vencido, lo que era bueno, porque si piensas que los punteros son difíciles, espera hasta intentar probar cosas en teoría de punto fijo.

Todos esos chicos que lo habían hecho muy bien en la secundaria escribiendo juegos de “pong” en BASIC para su Apple II, iban a la universidad, tomaban el curso CompSci 101, sobre estructuras de datos, y cuando llegaban al asunto de los punteros, sus cerebros estallaban completamente; y lo próximo de lo que tenías noticias es que estaban especializándose en Ciencias Políticas, porque la escuela de leyes parecía ser una mejor idea. He visto todo tipo de de índices de deserción en CS y usualmente están entre el 40% y el 70%. Las universidades tienden a ver esto como un derroche; yo creo que es sólo la poda necesaria de gente que no va a ser feliz o exitosa en una carrera de programación.

El otro curso difícil para muchos jóvenes estudiantes de CS era el curso donde aprendías programación funcional, incluyendo programación recursiva. MIT puso una barrera muy alta en esos cursos, creando un curso obligatorio (6.001) y un libro de texto (Estructura e Interpretación de Programas de Computadora de Abelson y Sussman, el cual era usado en docenas o quizás cientos de carreras de CS prestigiosas como el estándar de facto para la introducción a las Ciencias de la Computación. (Puedes, y deberías echarle una ojeada a la antigua versión de las clases en línea).

La dificultad de esos cursos es asombrosa. En la primera clase has aprendido casi todo Scheme, y ya has sido introducido a la función de punto fijo que toma otra función como parámetro. Cuando me esforzaba en pasar un curso similar, CSE121 en Penn, observaba cómo muchos sino la mayoría de los estudiantes simplemente no lo lograba. La materia era muy difícil. Inclusive escribí un largo email de lloriqueando a mi profesor diciendo que “simplemente no era justo”. Alguien en Penn debe haberme escuchado (o a alguno de los otros llorones), porque ese curso se dicta ahora con Java.

Desearía que no hubiesen escuchado.

Aquí radica el quid del debate. Años de lloriqueo de estudiantes perezosos como yo, combinados con quejas de la industria acerca de cuan pocos graduados en CS salen de las universidades americanas, han pagado su precio, y en la ultima década un gran numero de otrora perfectamente buenas universidades se han vuelto 100% Java. Esta de moda, a los reclutadores que usan “grep” parece gustarles, y, lo mejor de todo, no hay nada lo suficientemente difícil en Java como para filtrar aquellos programadores sin la parte del cerebro que entiende punteros y recursión. Así es que la deserción es menor, y los departamentos de ciencias de la computación tienen mas alumnos y mayores presupuestos y todo está bien.

Los afortunados chicos de esas Universidades-Java nunca van a toparse con raros fallos de segmentación tratando de implementar tablas hash basadas en punteros. Nunca se van a volver locos tratando de empaquetar cosas en bits. Nunca tendrán que ocupar sus cabezas en cómo en un lenguaje puramente funcional, el valor de una variable nunca cambia, y aun así, ¡cambia todo el tiempo! ¡Una paradoja!

Ellos no necesitan esa parte del cerebro para obtener un 4 en la materia.

¿Soy sólo uno de esos viejos cascarrabias anticuados, vanagloriándose acerca de cuán duro era sobrevivir a todas esas dificultades?

Rayos, en 1900, el Latín y el Griego eran asignaturas requeridas en la universidad, no porque sirvieran de algún propósito, sino porque de alguna manera eran considerados un requisito obvio de la gente educada. De cierta manera mi argumento no es diferente del argumento expuesto por la gente pro-Latín: “[El Latín] entrena tu mente. Entrena tu memoria. Desembrollar una sentencia en Latín es un excelente ejercicio del pensamiento, un verdadero acertijo intelectual y una buena introducción al pensamiento lógico”, escribe Scout Barrer. Pero ya no puedo encontrar una sola universidad que requiera Latín. ¿Son los punteros y la recursión el Latín y el Griego de las ciencias de la computación?

Ahora, admito que programar con punteros no es necesario en el 90% del código escrito en la actualidad, y de hecho es totalmente peligroso en el código de producción. OK. Está bien. Y que la programación funcional no es muy empleada en la práctica. De acuerdo.

Pero todavía sigue siendo importante para algunos de las tareas más excitantes en programación. Sin punteros, por ejemplo, nunca serías capaz de trabajar en el Kernel de Linux. No puedes entender una sola línea del código de Linux, o de hecho, de cualquier sistema operativo, sin realmente entender punteros.

Sin entender programación funcional, no podrás inventar MapReduce, el algoritmo que hace Google tan masivamente escalable. Los términos Map y Reduce vienen de Lisp y la programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera que recuerde de su clase equivalente a 6.001 que los programas puramente funcionales no tienen efectos colaterales y por ende son trivialmente paralelizables. El simple hecho que Google inventara MapReduce, y no Microsoft, dice algo del por qué Microsoft está aun jugando a lograr que funcionen algunas características básicas de búsqueda, mientras Google se ha movido ya al siguiente problema: construir Skynet^H^H^H^H^H^H, la mayor supercomputadora masivamente paralela del mundo. Simplemente no creo que Microsoft entienda completamente cuan retrasados están en ese campo.

Pero mas allá de la importancia a simple vista de los punteros y la recursión, su valor real radica en que construir grandes sistemas requiere del tipo de flexibilidad mental que adquieres aprendiéndolos, y de la actitud mental que necesitas para no huir de los cursos en donde son enseñados. Punteros y recursión requieren cierta habilidad para razonar, para pensar en abstracciones, y más importante, para ver un problema en diversos niveles de abstracción simultáneamente. Por lo tanto, la habilidad para entender punteros y recursión esta directamente correlacionada con la habilidad de ser un gran programador.

No hay nada en grado académico 100% Java que realmente descarte a los estudiantes que carecen de la agilidad mental para tratar con esos conceptos. Como empleador, he visto que las Universidades 100% Java han empezado a producir en serie una buena cantidad de graduados quienes simplemente no son lo suficientemente listos para trabajar como programadores en nada mas sofisticado que “Sólo Otra Aplicación Contable en Java”, aunque se las han arreglado para colarse a través de la (ahora simplificada) carrera. Esos estudiantes nunca sobrevivirían al 6.001 del MIT o al CS 323 en Yale y, francamente, esa es una razón por la cual, como empleador, un título en CS del MIT o Yale tiene más peso que uno de Duke, que recientemente se hizo 100%-Java, o de Penn, donde remplazaron Scheme y ML por Java tratando de enseñar la materia que casi nos mata a mis compañeros y a mi, CSE121. No es que no quiera contratar chicos listos de Duke o Penn, lo hago, es sólo que es mucho más difícil para mí darme cuenta de cuáles son. Yo estaba acostumbrado a decir que los chicos listos eran aquellos que podían desmenuzar un algoritmo recursivo en segundos, o implementar funciones de manipulación de listas enlazadas usando punteros tan rápido como podían escribir en la pizarra. Pero con graduado sde Universidades-Java, no puedo saber si padecen esos problemas a causa de haber sido mal educados o si los padecen porque realmente carecen de esa parte del cerebro que van a necesitar para ser buenos programadores en el trabajo. Paul Graham los llama “Blub Programmers“.

Ya es bastante malo que las Universidades-Java fallen en filtrar los chicos que nunca van a ser buenos programadores, algo que las universidades podrían justificablemente decir que no es su problema. Después de todo es la industria, o al menos los reclutadores-que-usan-grep, quien está pidiendo a gritos que se enseñe Java.

Pero las Universidades-Java fallan también en entrenar las mente de los chicos para ser hábiles, ágiles y lo suficientemente flexibles para lograr buen diseño de software (y no me refiero al “diseño” OO, donde gastas incontables horas acomodando tu jerarquía de objetos, o preocupándote de “problemas” superfluos como “tiene-un” vs. “es-un”). Necesitas entrenamiento para pensar en las cosas a varios niveles de abstracción simultáneamente, y ese tipo de pensamiento es exactamente lo que necesitas para diseñar excelentes arquitecturas de software.

Puedes estar preguntándote si la enseñanza de programación orientada a objetos (OOP) es un buen sustituto de los punteros y la recursión para el filtrado. La respuesta rápida: no. Sin debatir acerca de los meritos de la OOP, simplemente no es lo suficientemente difícil para filtrar a los programadores mediocres. OOP en las universidades consiste básicamente en memorizar un puñado de términos de vocabulario como “encapsulacion” y “herencia” y tomar exámenes del tipo “multiple-choice” acerca de las diferencias entre polimorfismo y sobrecarga. No más difícil que memorizar fechas destacadas y nombres en una clase de historia, la OOP tiene desafíos mentales inadecuados para espantar a los estudiantes de primer año. Cuando te enfrentas con un problema de OOP, tu programa aun funciona, sólo que es algo difícil de mantener. Supuestamente. Pero cuando te enfrentas a un problema con punteros, tu programa produce línea Fallo de segmentación y no tienes ni la menor idea de lo que está pasando, hasta que te paras, tomas una fuerte bocanada de aire y tratas de forzar tu mente a trabajar en dos diferentes niveles de abstracción simultáneamente.

Los reclutadores-que-usan-grep, de hecho, son ridiculizados aquí, y por un buen motivo. Nunca he conocido alguien que pueda usar Scheme, Haskell y punteros en C, que no pueda entender Java en dos días, y crear mejor código en Java que gente con cinco años de experiencia en Java. Pero trata de explicar eso al zombie de Recursos Humanos.

¿Pero que hay de la misión del compromiso con las CS de las facultades de CS? ¡Ellas no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso queda para los terciarios y los programas de capacitación del gobierno para trabajadores desplazados, dirán. Ellas se suponen que están para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿No es cierto?

Aun así, las CS son demostraciones (recursión), algoritmos (recursión), lenguajes (cálculo lambda), sistemas operativos (punteros), compiladores (cálculo lambda), y entonces la conclusión es que la Universidad-Java que no enseña C y no enseña Scheme, tampoco está enseñando realmente ciencias de la computación. Tan inútil como el concepto de currificación de funciones puede serle al mundo real, es un obvio prerrequisito para un graduado en CS. No puedo entender por qué los profesores en las comisiones curriculares de las facultades de CS han permitido que sus programas sean embrutecidos a tal punto que no sólo no pueden producir programadores operativos, sino que ya ni siquiera pueden producir graduados en CS que puedan obtener PhDs y puedan competir por sus puestos de trabajo. Oh, esperen. No importa. Quizás entienda.

Si volvemos en el tiempo y analizamos las discusiones que tomaron lugar en el mundo académico durante el “Gran Levantamiento Java”, encontraremos que la mayor preocupación fue que Java no era lo suficientemente simple para ser usado como un lenguaje de enseñanza.

Mi Dios, pensé, ¡están tratando de embrutecer la curricula aun mas! ¿Por que mejor no le llevamos la comida a la boca a los estudiantes? Dejemos que los ayudantes de cátedra den los exámenes por ellos también, entonces nadie se cambiara a Estudios Americanos. ¿Cómo se supone que alguien aprenderá algo si la curricula ha sido cuidadosamente diseñada para hacer todo más fácil de lo que ya es? Parece haber una comisión de trabajo (PDF) intentando idear un subconjunto simple de Java que pueda ser enseñado a estudiantes, produciendo documentación simplificada que esconde cuidadosamente toda esa basura EJB/J2EE de sus tiernas mentes, de manera tal que no tengan que preocupar sus cabecitas con otras clases que no necesiten para resolver sus aun más fáciles problemas de CS.

La interpretación mas compasiva de por qué las facultades CS son tan entusiastas en embrutecer sus clases es porque ello les dará más tiempo para enseñar verdaderos conceptos de CS, así no necesitaran dos clases enteras para esclarecer a los alumnos las diferencias entre, digamos, un int y un Integer en Java. Bueno pero si ese fuera el caso, 6.001 tiene la respuesta perfecta: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede enseñarse a estudiantes brillantes en unos 10 minutos; entonces puedes gastar el resto del semestre enseñando puntos fijos.

Fiu…

Voy a regresar a los unos y ceros.

(¿Te tocaron unos? ¡Bastardo suertudo! A nosotros nos tocaron todos ceros.)

Esta traducción está basada en la versión disponible en el Wiki de Joel Spolsky, corregida y adaptada por mí.

Dijkstra es reconocido como uno de los pioneros de las Ciencias de la Computación por sus abundantes aportes, tanto en el área teórica como en la práctica. Resulta ser que, además de un notable científico, también fue un gran visionario. Una muestra de ello es el artículo aquí reproducido, publicado originalmente en el año 1975.

Realmente es penoso ver que, aún 35 años después, muchos siguen sin caer en la cuenta de cuestiones que ya en aquella época resultaban evidentes.

¿Cómo decimos verdades que pueden lastimar?

A veces descubrimos verdades desagradables. Cada vez que lo hacemos, estamos en dificultades: suprimirlas es científicamente deshonesto, por lo que tenemos que decirlas; pero diciéndolas, sin embargo, se volverán en nuestra contra. Si las verdades son lo suficientemente desagradables, nuestro público será psíquicamente incapaz de aceptarlas y seremos tachados de irrealistas, idealistas sin remedio, peligrosamente revolucionarios, tontamente crédulos o lo que sea. (Además de eso, decir tales verdades es una forma segura de volverse impopular en muchos círculos, y como tal, es un hecho que en general no está exento de riesgos personales. Recordemos a Galileo Galilei…)

Las Ciencias de la Computación parecen sufrir gravemente este conflicto. En general, se mantienen silenciosas y tratan de escapar del mismo desviando la atención. (Por ejemplo: con respecto a COBOL se puede hacer sólo una de dos cosas: luchar contra la enfermedad o pretender que no existe. La mayoría de los departamentos de Ciencias de la Computación han optado por la última como una salida más fácil). Pero, hermanos, os pregunto: ¿es honesto? ¿No está nuestro prolongado silencio corrompiendo la integridad intelectual de las Ciencias de la Computación? ¿Es decente premanecer en silencio? Si no, ¿cómo podemos hablar?

Para que se haga una idea de la magnitud del problema, he enumerado una serie de tales verdades. (Casi todos los científicos de computación que conozco bien estarán de acuerdo sin dudarlo con casi todas ellas. Sin embargo, permitimos que el mundo se comporte como si no las conociéramos…)

• La programación es una de las ramas más difíciles de las matemáticas aplicadas, los pobres matemáticos mejor hubieran seguido siendo matemáticos puros.
• Las aplicaciones de computadora más fáciles son los cálculos técnicos/científicos.
• Las herramientas que usamos tienen una profunda (¡y retorcida!) influencia en nuestros hábitos de pensamiento y, por lo tanto, en nuestra habilidad de pensar.
• FORTRAN -”la enfermedad infantil”-, actualmente con casi 20 años de edad, es completamente inadecuado para cualquier aplicación informática que tenga en mente hoy: es demasiado torpe, demasiado arriesgado y demasiado costoso.
• PL / I -”la enfermedad fatal”- pertenece más al conjunto de los problemas que al de las soluciones.
• Es prácticamente imposible enseñar buena programación a estudiantes que han tenido exposición previa al BASIC: como programadores potenciales están mentalmente mutilados sin esperanza de regeneración.
• El uso de COBOL incapacita la mente, y su enseñanza debe, por tanto, ser considerada como un delito penal.
• APL es un error, llevado a cabo a la perfección. Es el lenguaje del futuro para técnicas de programación del pasado: crea una nueva generación de inútiles de la programación.
• Los problemas de administración de empresas en general y de gestión de bases de datos, en particular, resultan mucho más complicados para las personas que piensan en IBMés, compuesto con un Inglés desalineado.
• Sobre el uso del lenguaje: es imposible para afilar un lápiz con una cuchilla desafilada. Es igualmente inútil tratar de hacerlo con diez cuchillas desafiladas.
• Además de una inclinación matemática, un dominio excepcional de la lengua nativa es el activo más vital de un programador competente.
• Muchas compañías que se han vuelto dependientes de equipamiento IBM (y al hacerlo, han vendido su alma al diablo) se derrumbará bajo el peso de la complejidad incontrolada de sus sistemas de procesamiento de datos.
• No podemos encontrar ninguna disciplina científica, ni una profesión robusta, basada en los errores técnicos del Departamento de Defensa y, principalmente, un fabricante de computadoras.
• El uso de la terminología antropomórfica cuando se trabaja con sistemas de computación es un síntoma de inmadurez profesional.
• Afirmando que pueden contribuir a la ingeniería de software, los científicos blandos se vuelven aún más ridículos. (No menos peligrosos, ¡ay!). A pesar de su nombre, la ingeniería de software requiere (cruelmente) el soporte de la ciencia dura.
• En los buenos viejos tiempos los físicos repetían los experimentos de los demás, simplemente para estar seguros. Hoy se apegan a FORTRAN, de modo que puedan compartir los programas de cada uno, errores incluidos.
• Los proyectos que promueven la progamación en “lenguaje natural” están intrínsecamente condenados al fracaso.

¿No es esta lista suficiente para hacernos sentir incómodos? ¿Qué vamos a hacer? Volver a la orden del día, presumiblemente…

18 de junio 1975
Plataanstraat 5
Nuenen – 4565
Holanda

Prof. Dr. Edsger W. Dijkstra
Burroughs Research Fellow

PD: Si la conjetura “Usted hubiera preferido que no lo molestara enviándole esto” es correcta, puede añadirla a la lista de verdades incómodas.

Esta visión, lentamente, está cambiando. Por un lado, las historias de aquellos que hicieron una fortuna (o establecieron una posición económica) mediante la venta de licencias de un programa son, a la vez, cada vez más lejanas y menos frecuentes. Pero, si empezamos a vernos a nosotros mismos también como consumidores de software, el razonamiento cambia radicalmente.

Comparemos

Tomemos como ejemplo el desarrollo de un programa que le demande 5 años de trabajo a un programador altamente calificado y que requiera de las siguientes herramientas:

• Sistema Operativo.
• Compilador.
• Entorno de desarrollo: Depurador, editor de textos, etc.
• Herramientas de modelado: Herramientas para hacer diagramas de diseño, documentación, etc.
• Motor de base de datos.

El lapso de 5 años no es arbitrario: es una buena cota superior del tiempo pasado el cual un desarrollador debe renovar las herramientas que utiliza, si es que desea mantenerse actualizado. (Si lo prefiere, puede suponer la suma de varios desarrollos de menor envergadura, hasta llegar a cubrir dicho tiempo).

Comparemos entonces la cantidad de líneas de código “producidas” respecto de las “consumidas”. El cociente será seguramente bastante cercano a cero. Desde este punto de vista, aún cuando un programador sigue produciendo software, su rol de consumidor es, por mucho, más relevante.

Alguien dirá que al vender muchas licencias del programa producido, su valor se multiplicará. Esto no es así, teniendo en cuenta que, para poder ejecutarse el programa requerirá, nuevamente, de un sistema operativo y del motor de base de datos. No es poco común ver a un programador cobrar determinada suma de dinero por un desarrollo y a su cliente desembolsar bastante más por licencias del software requerido para que funcione.

Un mal negocio

Entre los programadores independientes (o pequeñas empresas de desarrollo) es práctica común usar software sin pagar por sus licencias, con lo cual parte del análisis anterior no los afecta demasiado. Pero sus clientes (y cada vez más) no tienen opción.

Por ejemplo, un sistema que requiera de un servidor con el sistema operativo Windows 2008 y el motor de bases de datos Microsoft SQL Server 2008 para su utilización en 25 puestos de trabajo, requerirá el pago de más de u$s 10.000 en concepto de licencia de uso de dichos productos (en la Argentina, marzo de 2010). ¿Cuánto deberá trabajar el programador para cobrar una suma de dinero similar?

Claramente, esta forma de ver el negocio no tiene mucho sentido (a no ser para aquellas empresas de desarrollo que además son agente de ventas de quienes proveen el software de base y se llevan una jugosa comisión).

Quizá sea por este motivo que las empresas proveedoras de herramientas de desarrollo y software de base invierten tanto dinero para que los programadores se pongan “su camiseta”, recurriendo para esto a discursos motivadores, aportes a instituciones educativas, descuentos, tazas de café, etc.

Asumir que esta es una situación natural es resignarse a ser, ya no un productor, sino un mero promotor de la venta de productos de otro (con un esfuerzo y un riesgo bastante altos).

Una buena alternativa

Debemos reconocernos a nosotros mismos, antes que como productores, como consumidores de software. De esta manera, la salida es clara: debemos reducir los costos de la “materia prima”. Debemos, en la medida de lo posible, utilizar software que no requiera el pago de licencias de uso. De esta manera disminuyen sensiblemente los costos para el desarrollador, como así también los costos extra del cliente. (Y cliente que gasta menos en licencias, tiene más dinero para pagarle al programador).

Si el sistema del ejemplo anterior pudiera correr en un servidor con GNU/Linux y el motor de bases de datos PostgreSQL tendría más de u$s 10.000 de “ventaja” en condiciones similares.

Otro punto importante es el ahorro en hardware, al utilizar productos que reduzcan los requerimientos en este aspecto (característica que distingue a muchos programas libres, respecto de sus contrapartes privativas), aunque dicho análisis escapa al objetivo del presente artículo.

¿Por qué no?

Existe una marcada reticencia en ciertos programadores a analizar seriamente esta alternativa. Dejaremos de lado, por supuesto, el caso de aquellos que actúan, además, como agentes de venta de los proveedores de software de base (su caso es más que claro: ellos se benefician por ambos lados). Analizaremos algunas de las objeciones más comunes:

El sistema operativo libre “X” es difícil de usar. No lo entiendo

En casi todos los casos, “X” se refiere al sistema operativo GNU/Linux (el sistema operativo libre más difundido). Quizás el programador en cuestión haya tenido una mala experiencia tratando de usar alguna versión mal configurada u obsoleta. Seguramente tampoco haya dedicado demasiado tiempo ni esfuerzo a aprender los conceptos básicos (que no son, precisamente, como usar los botones del mouse), y se alejó cual la zorra de Esopo murmurando “están verdes”.

De esto no se desprende que GNU/Linux sea tán fácil, cómodo o agradable de usar que Windows 7 (o más), pero tratándose de un profesional y habiendo tanto dinero de por medio, bien merece algún pequeño sacrificio.

En la empresa en donde se implanta mi sistema usan Windows

Aquí hay una amplia variedad de casos. ¿Usan Windows en los equipos de escritorio? Asumiendo que ya han pagado las licencias (por el tiempo que reste hasta la actualización de los equipos), de todas maneras podría significar un ahorro importante a nivel de los servidores. ¿Usan Windows en los servidores? Proveer una aplicación que no lo requiera, puede significar un valor agregado interesante.

En la mayoría de los casos en que la empresa “usa Windows” es porque las aplicaciones existentes lo requieren. No es, por lo tanto, una excusa para no proveer una alternativa que posibilite un ahorro importante (si no en lo inmediato, en el mediano plazo).

Estoy acostumbrado a desarrollar en (y para) Windows

Todos sabemos que los programadores disponemos de poco tiempo para mantenernos actualizados y lo costoso que resulta abordar el aprendizaje de una nueva tecnología. Cada quién sabrá si realmente se justifica el esfuerzo, poniendo en la balanza costos y beneficios (o, según el planteo de este artículo, costos y ahorros).

No hay un equivalente libre de la herramienta “Y”

Es cierto que en algunos casos (no tantos como se alegan) no hay equivalentes libres a ciertas herramientas privativas. ¿Y aquí termina el análisis? ¿No merece la pena indagar sobre alguna alternativa? ¿Tan útil es la herramienta “Y” que se hace imprescindible e indiscutible?

Si alguien depende exclusivamente de una determinada herramienta para desarrollar software, entonces se encuentra ante un problema bastante más grave que el gastar dinero en licencias de uso. (Preguntar a desarrolladores en Delphi, Visual Fox, Clarion, entre otros. Pero este tema también excede el alcance del presente artículo.).

No hay un equivalente libre del motor de bases de datos “Z”

Aquí “Z” suele tomar la forma de MS SQL Server, Oracle o DB/2. La afirmación suele hacerse seguida de alguna frase que parece extraída de una publicidad del proveedor correspondiente. La realidad es que existen numerosos motores de bases de datos libres, como por ejemplo MySQL para pequeños volúmenes de información, o PostgreSQL que no tiene ninguna característica importante que envidiarle a ningún otro producto.

En el caso de programas libres, nadie me ofrece el soporte que me da la empresa “W”

¿Enserio? Prácticamente todos los programas libres importantes, cuentan con ofertas de soporte incluso mejores que las que puedan conseguirse respecto de programas privativos. Por un lado, el soporte ofrecido es de mejor nivel, ya que se ofrece a nivel de reparación de errores en el código fuente y, por otro, muchas veces existen múltiples proveedores de soporte, que compiten entre si (en el mundo del software privativo el soporte es un monopolio del fabricante).

Porque no

Es cierto que hay algunos casos en donde no hay alternativa (la utilización de determinada tecnología puede ser impuesta como un requerimiento), pero en la mayoría de los casos la situación es que el programador se encuentra “atado” a sus herramientas.

En algunos casos, porque las han utilizado durante mucho tiempo (y tienen una gran cantidad de código desarrollado ligado a ellas) y en otros porque han “comprado” el discurso de su productor, muchos programadores se resisten a realizar cualquier análisis que tenga que ver con cambiar sus herramientas. El caso más grave (y lamentablemente no poco común) es cuando el programador simplemente no puede usar otra tecnología más que la que domina: es la única que conoce.

De más está decir, las inversiones en marketing dan resultado. Hoy nos encontramos a muchos programadores que han sido formados en un ambiente académico muy similar a un “monocultivo” (que, a pesar de ellos, ni siquiera ofrece los amplios márgenes de ganancia de la soja) o que se han entregado más tarde a determinada combinación de herramientas/tecnología y la han abrazado como dispuestos a envejecer (y quedar obsoletos) junto con ella.

Y así es que el negocio seguirá funcionando muy bien para los “grandes productores de software”, en tanto que los pequeños no reconozcan su rol de consumidores. Afortunadamente, la situación ya está cambiando: abundan los ejemplos de quienes, siendo conscientes de esto, están haciendo una diferencia económica significativa.

Adenda

Nótese que en este artículo no se hace alusión a la licencia bajo la cual el programador entrega su programa al cliente final. El término “libre” sólo se aplica a las herramientas utilizadas para el desarrollo y a las requeridas para su posterior ejecución.

El uso de herramientas de desarrollo libre no impone ninguna condición sobre la licencia que acompañará al programa resultante. (Distinta situación puede darse si se incorpora código de un programa libre en uno de producción propia).

The situation

I have a table “mytable” (1,000,000 rows) with a column named “mycolumn” of type “datetime” and an index created on it named “idx_mycolumn“. When I issue the following query:

SELECT * FROM mytable ORDER BY mycolumn

it tooks more than 1 minute to give the results (the 1,000,000 rows ordered by mycolumn.)

Using the command “EXPLAIN” I can see that the MySQL optimizer don’t use the index at all: it generates a filesort (on disk) in order to sort the resultset. The only way to solve this issue (as far as I know) is providing a “hint” to the optimizer, telling what indexes to use:

SELECT * FROM mytable USE INDEX(idx_mycolumn) ORDER BY mycolumn

But the optimizer still chooses to do a full table scan instead of using the “idx_mycolumn” index (and still generates a filesort, taking more than 1 minute.)

There is a way to force the optimizer to use the index:

SELECT * FROM mytable FORCE INDEX(idx_mycolumn) ORDER BY mycolumn

This time, the optimizer uses the index, and the query takes about 3 seconds. (Is the MySQL query optimizer that bad?)

A bigger problem

Then, I came into the real problem for me: Obviously I’ll never need to get all the rows from that table, but is a common task to “paginate” the rows (previously ordered by some column) taking, let’s say, 25 rows at a time and using an offset. The query looks as follows:

SELECT * FROM mytable ORDER BY mycolumn LIMIT 100000,25

It sorts the resultset using the values of “mycolumn” and then returns 25 rows skipping the first 100,000. Surprisingly, this time the query tooks less than 1 second to execute (and “EXPLAIN” says that is using the “idx_mycolumn” index. What a joy!).

But the problem is still there: If the limit reaches (or surpases) the last row, then the optimizer throws away the index and generates a filesort (taking more than 1 minute, making the query totally useless…)

The solution (again) is to force the optimizer to use the index “idx_mycolumn“, getting a response in about 3 seconds.

My conclusion

Far from being a MySQL expert, the only conclusion I can reach is that the optimizer is really screwed up. How can it be possible that changing only the limit of the results, confuses the optimizer in such a way that leads to a simple query (that can’t take more than a few seconds) to take an unacceptable amount of time (not to mention the disk space)?

As I can’t (and don’t want) force indexes in every query involving large tables in my system, the only real solution for me is replacing MySQL with a more robust (and decent) DBMS (I’ve tried PostgreSQL with the same database and the results are far more reasonable.)

Some things to consider

• The problem is the same being the engine used MyISAM or InnoDB.
• The problem doesn’t get solved after doing a “ANALYZE TABLE“.
• I’ve trying with other datatypes for the sorting column, with the same results.
• I’ve tested this issue with versions 5.0.35 and 5.0.51a, with identical results.

Update (2008/12/30)

The observed behavior must be related with the bug 28404 (patched in version 5.1). From the patch description:

When there are many indexes in table, optimizer wrongly does not even consider the one on column used in ORDER BY, when LIMIT N clause is also present.

I’ve oversimplified the example, but in my real scenario I had multiple single-column indexes on the table. I still can’t believe that the optimizer get confused by having multiple indexes to choose from (but only in presence of the LIMIT clause). Can you guess how is the optimizer coded? (That’s why I use the word “toy” in the title.)

A posible solution seems to be moving to the new version, but anyway, MySQL 5.1 also has several issues (and the distribution installation script for GNU/Linux is totally broken), so I’m moving to PostgreSQL.

(Thanks to Abel Chiola for the links.)

Ruby: “Orientación a Objetos” y algo más…

• Presentación en formato PDF
• Presentación en formato ODP (OpenOffice.org)

Bueno, ¡no podía faltar una foto! ;)

Aunque se trata de material un tanto obsoleto, ya que está basado en las primeras versiones de Rails (en las cuales ni siquiera existían, por ejemplo, las “migrations”), decidí publicarlo de todas formas.

Primeros pasos en Rails

• Presentación en formato PDF
• Presentación en formato ODP (OpenOffice.org)

Un pequeño comentario: Todavía recuerdo el gran esfuerzo de la gente del Grupo de usuarios de GNU/Linux de Rosario (LUGRO) y de los integrantes de la Asociación Argentina de Nuevas Tecnologías (ANT) que lograron una organización impecable y, como siempre ocurre en estos eventos, un excelente clima de camaradería.

En la foto aparecemos (de izquierda a derecha) Diego Gomez (gran amigo y colega) , yo, Beatriz Busaniche (excelente periodista, integrante de la Fundación Vía Libre y gran activista en favor del Software Libre), Federico Heinz (amigazo, también integrante de Vía Libre y hacker de aquellos…) y Sebastián Criado (incansable, movedizo y persistente luchador por el software libre, entre otras causas).

Aunque en algún momento estará disponible en el sitio del evento (junto con el video de la charla), no resití la tentación de publicar la presentación que utilicé.

Experiencias en la implementación de un ISP con software libre

• Presentación en formato PDF
• Presentación en formato ODP (OpenOffice.org)

Los fiscales informáticos tuvimos acceso a la interfaz de consulta del proceso de escrutinio y a un volcado de la base de datos, que se realizaba cada 5 minutos. Lamentablemente, no tuvimos acceso al código fuente de la aplicación (aunque espero poder acceder al informe de los peritos contratados por la Junta Electoral).

Una vez finalizado el escrutinio provisorio, surgieron diferencias en los totales de votantes de los dos cargos electivos. A raíz de esto, decidí inspeccionar la base de datos con el objetivo de generar el listado de las mesas en las cuales se originaba dicha diferencia. De dicho análisis resultó el siguiente artículo, en el que me permito realizar algunas críticas.

El diagrama de Entidad-Relación (DER)

El siguiente es el DER que nos envió la gente de MSA:

Como puede verse se trata de una base de datos realmente simple (apenas 11 tablas). Lo que me llamó la atención a primera vista fue la utilización de palabras en castellano (muchos programadores opinamos que los programas deberían estar documentados en inglés). Siguiendo con los nombres, por más que me esforcé no pude imaginar la diferencia entre “ubicaciones” y “lugares“. No encontré palabras como “mesa“, “escuela“, “circuito“. A mi entender, la elección de la nomenclatura no ha sido la mejor.

Las claves primarias

En 9 tablas de la base de datos, las claves primarias son del tipo “varchar“. Si bien esto no es del todo incorrecto, no es muy recomendable. Las claves primarias deberían ser del tipo “integer“, y además auto-incrementadas (PostgreSQL, el RDBMS utilizado, lo soporta). Esto no solamente simplifica la asignación de valores a las claves (no hay que verificar la unicidad), sino que tiene un gran impacto en el desempeño de la base de datos.

Al utilizar el tipo “varchar“, cuya longitud es variable, el tamaño de los índices es mayor que usando “integer“. Esto, al aumentar la cantidad de filas de las tablas, se torna cada vez más importante (es deseable que los índices quepan en la caché del RDBMS). (En Río Cuarto había solamente 352 mesas y menos de 110.000 votantes, por lo cual no debe haberse notado la diferencia, pero en una elección más amplia seguramente lo haría.)

Un factor que agrava la situación es que la comparación de claves, al tratarse de cadenas, debe hacerse caracter a caracter (a diferencia de la comparación de valores enteros, que se realiza mediante una simple resta). Como veremos más adelante, en algunas tablas los valores del atributo clave en varias filas tienen un prefijo en común. Esto ralentiza aún más la comparación, y la situación es empeorada por la utlización de la codificación de caracteres UTF-8, debido a la implementación interna de PostgreSQL.

En mi opinión pudiendo usar valores enteros como clave, debieron haberlo hecho.

¿Relación inexistente?

Primero, una breve explicación del problema: La ciudad se divide en 3 circuitos electorales, en los cuales se encuentran las distintas escuelas, en donde a su vez están las mesas de votación. Como el sistema permite analizar circuitos, escuelas y mesas por separado, el primer diseño que cualquier programador pensaría es disponer de tres tablas: “circuitos”, “escuelas” y “mesas” (en el caso de una elección provincial o nacional se agregarían algunas más). Entre esas tablas habría relaciones 1:N, es decir “1 circuito tiene N escuelas, 1 escuela pertenece a un circuito”, “1 escuela tiene N mesas, 1 mesa pertenece a 1 escuela”.

Aprovechando el hecho de que tanto las escuelas como las mesas tienen los mismos atributos, decidieron usar una única tabla, denominada “ubicaciones”, según muestra el DER:

Es común utilizar este tipo de representación para estructuras de “árbol”. Esto se logra agregando como atributo una clave foránea que referencia a la clave primaria de la misma tabla. En las filas “padre” dicho atributo tiene el valor “NULL“, en tanto que en las filas “hijas”, dicho atributo contiene el valor de la clave primaria del padre.

Sin embargo, el código SQL de la estructura de la tabla “ubicaciones” es el siguiente:

CREATE TABLE ubicaciones (
    id_ubicacion character varying(12) NOT NULL,
    clase character varying(30) NOT NULL,
    descripcion character varying(100),
    sexo character(1),
    CONSTRAINT ubicaciones_sexo_check CHECK
          (((sexo = 'F'::bpchar) OR (sexo = 'M'::bpchar)))
);

No existe ningún atributo que oficie de clave foránea para representar la relación en cuestión. ¿Cómo es esto posible?

Para comprender cómo está representada esta relación, fue necesario analizar los datos de la tabla (algo que, después de discutirlo con varios amigos, no pudimos llegar a la conclusión de qué principios de la teoría de bases de datos violenta, quizás algún lector pueda echar algo de luz al respecto). Encontre lo siguiente:

El “truco” consiste en utilizar parte de la clave primaria de una fila, para referenciar a la fila “padre”. Por ejemplo, las claves de todas las mesas pertenecientes a la escuela “Adolfo Alsina” (cuya clave es “RC0101“) comienzan con el prefijo “RC0101“. De la misma manera, las claves de todas las escuelas del circuito “165″ (cuya clave es “RC01“) comienzan con el prefijo “RC01“.

Ingenioso, pero totalmente innecesario y contrario a la teoría de bases de datos relacionales. De hecho, la relación está presente en el DER, pero no se ve reflejada en la base de datos. (Este tipo de representación de relaciones basadas en códigos era una práctica común de los programadores Cobol de otras épocas.)

Tipos de datos

Siguiendo con la tabla “ubicaciones“, podemos apreciar la siguiente restricción de integridad:

CONSTRAINT ubicaciones_sexo_check CHECK
         (((sexo = 'F'::bpchar) OR (sexo = 'M'::bpchar)))

El objetivo de esta restricción es verificar que el valor del atributo “sexo” (de tipo “character(1)” sea “F” o “M“. Una forma más simple y eficiente, es definir un tipo de datos enumerado:

CREATE TYPE sexos AS ENUM ('F', 'M')

Esta misma situación se produce en otras tablas, incluyendo la reiteración de casos como el que sigue:

CONSTRAINT usuarios_carga_check CHECK
          (carga = 'SI'::bpchar OR carga = 'NO'::bpchar)

Aquí, evidentemente, hubiera bastado definir al atributo “carga” de tipo “boolean“. (Esta restricción se encuentra en la tabla “usuarios“, en donde es reiterada tres veces.)

La tabla “estados” contiene los distintos estados en que puede encontrarse una planilla a lo largo del proceso:

CREATE TABLE estados (
    id_estado character varying(16) NOT NULL,
    descripcion character varying(50),
    bg_color1 character varying(7),
    bg_color2 character varying(7),
    prioridad integer,
    orden integer,
    accion character varying(20),
    CONSTRAINT estados_id_estado_check CHECK
         ((((((id_estado)::text = 'Espera'::text)
          OR ((id_estado)::text = 'En Proceso'::text))
          OR ((id_estado)::text = 'Intranet'::text))
          OR ((id_estado)::text = 'Internet'::text)))
);

Aquí la restricción de integridad tiene como objetivo que restringir los valores de la clave “id_estado“, pero esto deja sólo cuatro posibilidades (de hecho, ¡los cuatro estados posibles de una planilla!). Codificar en el esquema de la base de datos los valores (fijos) de las claves de las cuatro entradas que luego tendrá la tabla no parece una buena idea. (Nuevamente, de juzgarse necesario, debería haberse utilizado un tipo enumerado.)

Otro punto cuestionable es la elección de los valores para codificar cada estado: varias palabras, uso de mayúsculas y minúsculas.

Otros errores

En el DER puede verse lo siguiente:

Esto parece indicar que no puede haber más de 2 planillas en el mismo estado, algo que es falso (de hecho, inicialmente todas las planillas están en el estado “Espera” y al finalizar están en el estado “Internet”.

El DER también muestra la siguiente entidad:

La tabla que se corresponde con dicha entidad se llama “configuracion” (en singular).

Estos errores pueden parecer simples detalles (de hecho, en un sistema con solamente 11 tablas posiblemente lo sean), pero en un sistema más complejo pueden dificultar sensiblemente la programación, propendiendo a la comisión de errores.

Conclusión

Sin ser un experto en bases de datos relacionales (las utilizo desde hace más de 10 años como parte de mi trabajo, pero no me considero un especialista en la materia), los errores detectados me dan la pauta de que no se ha puesto el suficiente cuidado en el diseño de la base de datos, fundamentalmente de cara a la escalabilidad del sistema para soportar volumenes de carga mayores a los generados por proceso electoral como el de Río Cuarto (2 cargos electivos, 6 listas y 352 mesas).

De más está decirlo, dejo abierto este espacio a críticas y sugerencias respecto de este tema.

Este mecanismo se denomina “clausura” (“closure“, en inglés), y aunque no es exclusivo de Ruby (es un viejo conocido en Smalltalk y Lisp, encontrándose aún en Perl y Python), la simplicidad de su uso lo transforma en una herramienta muy poderosa y flexible.

Quienes hemos programado en lenguajes funcionales (como ML y Haskell), siempre hemos extrañado en los lenguajes imperativos la posibilidad de pasar funciones como parámetros de forma “natural” (no a la manera en que puede hacerse en Java o Pascal, sino incluyendo las ligaduras al scope actual).

Un ejemplo simple

Supongamos que deseamos escribir una función que tome como parámetro un arreglo de valores enteros y retorne otro arreglo, producto de multiplicar por 2 cada uno de los elementos del parámetro.

En Java podríamos escribir algo así:

public static ArrayList double(ArrayList x)
{
  ArrayList y = new ArrayList();
  for (Iterator i = x.iterator(); i.hasNext(); )
    y.add(i.next() * 2);
  return y;
}

(Obviamente, olvidándonos de algunos casts para simplificar la lectura.)

O, en PHP:

function double($x) {
  $y = array();
  foreach ($x as $e)
    array_push($y, $e*2);
  return $y;
}

En tanto que en un lenguaje funcional, como Haskell podríamos escribir lo siguiente:

double x = map (*2) x

O, simplemente:

double = map (*2)

“map” toma como parámetro una función (en este caso, la función parcial “*2“) y un arreglo, devolviendo el resultado de aplicar dicha función a cada elemento del arreglo.

Veamos un ejemplo de la evaluación de double:

double [1, 2, 3]
[1*2, 2*2, 3*2]
[2, 4, 6]

Como podemos ver, la principal ventaja de los lenguajes funcionales es su expresividad, en el sentido de que el código del programa expresa de forma mucho más clara qué es lo que este hace (multiplicar por 2 cada elemento del arreglo).

En Ruby, aunque no es un lenguaje funcional, la posibilidad de pasar funciones (o, en general, bloques de código) como parámetro se presenta de forma igualmente sencilla:

def double(a)
  a.map {|e| e*2}
end

“map” es un método de la clase “Array” que toma un bloque de código y lo ejecuta para cada elemento del arreglo, devolviendo la colección de los resultados producidos. El fragmento “|e|” establece la ligadura entre el identificador “e” y el elemento actual.

Explotando la potencia de las clausuras

Supongamos ahora que tenemos una clase “Person“, cuyo método “age” calcula la edad de la persona. Si tenemos una colección de personas en el arreglo “people” y deseamos obtener sólo aquellas que son mayores de 18 años, en Ruby podríamos escribir lo siguiente:

people.select{|p| p.age > 18}

(El método “select” aplica una función lógica (booleana) a cada elemento y devuelve sólo aquellos para los cuales resultó verdadera.)

En tanto que si, además, quisiéramos mostrar el nombre de cada una de ellas, podríamos escribir:

people.select{|p| p.age > 18}.each{|p| puts p.name}

(El método “each” aplica el bloque a cada elemento del arreglo.)

O bien, de forma más compacta (sin generar un segundo arreglo):

people.each{|p| puts p.name if p.age > 18}

Comparación con otros lenguajes

Problema 1

Convertir las cadenas de un arreglo a mayúsculas.

En PHP:

for ($i = 0; $i < count($a); $i++)
  $a[$i] = strtoupper($a[$i]);

En Ruby:

a.map!{|e| e.upcase}

(El método “map!“, a diferencia de “map“, modifica el arreglo, en vez de retornar uno nuevo.)

Problema 2

Dado un arreglo de la forma [["nombre", "apellido"]], obtener un arreglo de la forma ["apellido, nombre"]. Por ejemplo, dado:

[["Javier","Smaldone"],["Santiago","Lobos"],["Bon","Scott"]]

obtener:

["Smaldone, Javier", "Lobos, Santiago", "Scott, Bon"]

En PHP:

$b = array();
foreach ($a as $e)
  array_push($b, $e[1] . ', ' . $e[0]);

En Ruby:

b = a.map{|e| e.reverse.join(', ')}

Problema 3

Calcular la edad promedio de las personas mayores de edad (según el ejemplo planteado anteriormente).

En PHP:

$sum = 0;
$count = 0;
foreach ($people as $p) {
  if ($p->age > 18) {
    $sum += $p->age;
    $count++;
  }
}
if ($count) print $sum/$count;

Una solución posible en Ruby sería:

adults = people.select{|p| p.age > 18}
sum = 0
adults.each {|p| sum += p.age }
puts sum.to_f/adults.size if adults.size > 0

Pero usando todo el poder de las clausuras y las funciones “map” e “inject“, podríamos escribir:

adults = people.select{|p| p.age > 18}
sum = adults.map{|p| p.age}.inject{|ac,e| ac+e}
puts sum.to_f/adults.size if sum

( “inject” ejecuta el bloque, asignando la segunda variable a cada elemento del arreglo y asignando el resultado de la ejecución a la primera, manteniendo su valor a través de cada iteración.)

Problema 4

Dado un arreglo de cadenas, obtener la de mayor longitud.

En PHP:

$max = '';
foreach ($a as $e)
  if (strlen($e) > strlen($max))
    $max = $e;

En Ruby:

max = a.inject {|m, e| e.length > m.length ? e : m }

(Adicionalmente, hemos usado el operador de asignación condicional “cond ? val1 : val2“, que retorna “val1” si “cond” es verdadero y “val2” en caso contrario.)

Conclusión

La posibilidad de utilizar clausuras nos acerca a la simplicidad y la expresividad de la programación funcional. Este es uno de los puntos fuertes del lenguaje Ruby (y la envidia de otros lenguajes, como Java, cuya comunidad está debatiendo sobre la posibilidad de incorporarlo en la versión 7).

(Y sí, se lo que pensará mi amigo Ricardo cuando lea este artículo. Es cierto, los lenguajes tienden a Lisp.)

Algunas referencias:

• Clausuras en Wikipedia (en inglés).
• Más sobre clausuras en Ruby.
• Clausuras en Python.
• Clausuras en Perl.
• Historia de las clausuras.

Y como no puedo conmigo mismo, decidí escribir este pequeño post para mostrar algo de lo que estoy haciendo. Se trata de una herramienta para generar diagramas de clases de aplicaciones Ruby on Rails.

Comencé a escribirla por necesidad (para los desarrollos en los que estoy trabajando), pero luego decidí extenderla un poco más (para, además, extender mis conocimientos de Ruby).

Por ahora, nada más (en los próximos días escribiré con mayor detalle sobre él). Les presento a mi nuevo juguete: RailRoad.

(En InfoQ han publicado una revisión sobre RailRoad.)

Pocos saben, sin embargo, quién fue este gran hombre y su verdadero aporte a través de más de 40 años de actividad académica, científica e industrial. A continuación he traducido el discurso pronunciado por David Gries, otro notable científico de la computación, en oportunidad de un homenaje a poco tiempo de su fallecimiento.

¿Cómo podemos describir a Esdger W. Dijkstra a quienes no lo conocieron?

por David Gries

En el Acto en Honor a la Memoria de E. W. Dijkstra
21 de noviembre de 2002

Edsger Wybe Dijkstra nos dio mucho más que sólo material y terminología técnicos. Su profunda integridad, sabiduría y compasión nos llegaron de varias influentes y, a menudo, frescas y sorprendentes formas -algunas veces para la perplejidad de sus amigos y colegas. Encontraremos gran dificultad en explicar a otros cómo fue conocer a Edsger y trabajar con él. Aquellos que no tuvieron la fortuna de conocerlo nunca entenderán de lo que se perdieron.

¿Cómo explicas cómo era tomar un curso sobre metodología matemática de Edsger, verlo demostrar día tras día su destacable habilidad para resolver problemas que nosotros no podemos resolver, aún luego de que él hiciera explícitos los principios y las técnicas involucradas?

No puedes.

¿Cómo describes una reunión de su Club del Martes por la Tarde, donde los participantes resolvían un problema juntos, o leían un artículo en voz alta, frase por frase, comentando sobre la estructura de las frases, el estilo, la organización general, las pruebas, el contenido técnico; sobre cualquier cosa que pudiera mejorarse?

No puedes. El Club del Martes por la Tarde continúa, pero nunca será lo mismo sin su fundador, Edsger W. Dijkstra.

¿Cómo puedes explicar la experiencia, que cientos tuvieron pero ya no tendrán, de recibir una carta manuscrita de Edsger, llena de comentarios técnicos interesantes, opiniones sobre gente y su trabajo; siempre junto con al menos un juego de palabras, como así también con información sobre él y su familia?

No puedes. Al leer una carta así, uno sabía que Edsger te había brindado su atención de una manera en que pocos estaban dispuestos a hacerlo.

¿Cómo ilustras el estar teniendo una conversación con Edsger, experimentar un minuto o dos de silencio luego de una pregunta, preguntándote qué le pasa, pero luego verlo salir con una respuesta brillante y darte cuenta de era una de las pocas personas que pensaban antes de hablar?

No puedes.

¿Cómo puedes eplicar el enigma de que a muchos les pareciera distante y frío, cuando era realmente una persona amable y sociable, que era compasivo y servicial en el momento en que lo necesitabas y que caería a lo de sus amigos por la tarde con su esposa, sin previo aviso, para conversar durante una hora?

Imposible hacerlo. Sólo aquellos lo suficientemente afortunados en conocer a Edsger conocieron al verdadero Edsger.

¿Cómo explicas no sólo su absoluta integridad y habilidad en discriminar entre preocupaciones políticas e industriales, en oposición a las metas científicas; sino también su valor para expresar esas diferencias en público?

No puedes. Un científico de la computación menos valiente una vez dijo sobre un informe suyo, “Edsger tiene razón, ¡pero no puedes decir esas cosas!”. Bien, Edsger las dijo porque sentía que debían ser dichas.

¿Cómo es que Edsger se escribía con tantos pero compartió la autoría de artículos con tan pocos? ¿Y por qué uno de ellos -uno de sus estudiantes de doctorado y más cercano colega- Netty van Gasteren, nos dejó en la flor de su vida justo un mes antes de que falleciera Edsger? Ah, Netty, te extrañaremos tanto como a Edsger.

Si, cualquiera puede leer sus 1300 ensayos, reportes, informes técnicos y revisiones. Pero no es lo mismo que conocerlo, hablar con él, escribirse con él, socializar con él y trabajar con él; y quienes hemos tenido esas experiencias no podemos transportar la sensación a otros.

Rutger, Marcus y Femke, fueron muy sabios en elegir a Ria y Edsger como sus padres. A la vez que estoy seguro de que hubieron dificultades en crecer a la sombra de semejante hombre, así como hay dificultades en cualquier familia, esa experiencia los ha hecho mejores. Esperamos que nuestros caminos se crucen a menudo, porque además de apreciarlos por quienes son, vemos a Edsger en ustedes.

Querida Ria, tu y Edsger fueron uno. Estuviste con él en sus emprendimientos en la ciencia de la computación más que cualquier esposa de la ciencia de la computación. Viajaste con él y asististe a las conferencias, tomaste a sus colegas como tus amigos y les diste la bienvenida en tu hogar. Ahora, enfrentas la vida con sólo recuerdos de Edsger, esperamos que continúes siendo nuestra amiga y parte de nuestras vidas.

Edsger, tuviste tus debilidades físicas y mentales, tus fragilidades humanas, como todos las tenemos. Pero en muchos aspectos, fuiste un gigante entre nosotros. Tu memoria -la de tu integridad, sabiduría, amistad y compasión- nos inspirará por el resto de nuestras vidas.

Para facilitar su difusión (y para tenerlo siempre a mano), decidí traducirlo. ¡Que lo disfrute!

Respuestas a preguntas de estudiantes de Ingeniería de Software

[La reconstrucción aproximada de las preguntas se deja como ejercicio al lector.]

• Los aparatos no son necesariamente una mejora. Véase la sucesión
  
  Pizarrón -> Proyector de transparencias -> Power Point
• Y no necesito perder mi tiempo con una computadora sólo porque soy un científico de la computación. [A los investigadores en medicina no se les exige sufrir las enfermedades que investigan.]
• No es el negocio de la ciencia de la computación el promover la “computerización”, digamos, desarrollando aplicaciones exigentes para crear un mercado para la próxima generación de hardware. [A los investigadores en medicina no se les pide desarrollar nuevas enfermedades para crear un mercado para nuevos productos farmacéuticos.]
• No es la tarea de la Universidad el ofrecer lo que la sociedad pide, sino lo que la sociedad necesita.
  [Las cosas que la sociedad pide son por lo general comprendidas, y no se necesita una universidad para eso. La universidad debe ofrecer lo que nadie más puede proveer.]
• Estamos delineados por las herramientas que utilizamos, en particular: los formalismos que usamos definen nuestros hábitos de razonamiento, para mejor o peor, y esto significa que debemos ser muy cuidadosos en la elección de qué aprendemos y enseñamos, ya que desaprender no es posible.
  [Hace varios años, si pudiera usar un nuevo asistente, un prerrequisito sería "Sin exposición previa a FORTRAN". En las escuelas de Siberia, la enseñanza del BASIC no estaba permitida.]
• Un programador debe ser capaz de demostrar que su programa tiene las propiedades requeridas. Si esto se deja para más adelante, es seguro que no será capaz de cumplir con su obligación: sólo si permite que esta obligación influencie su diseño, existe la esperanza de que pueda cumplirla. Solamente verificar a posteriori le deniega esa sana influencia y por lo tanto es poner el carro delante del caballo, pero es exactamente lo que ocurre en las casas de software donde “programación” y “aseguramiento de la calidad” (“quality assurance”) son hechos por grupos distintos. [No hace falta decirlo, esas casas entregan productos sin garantía.]
• Las técnicas requeridas para el razonamiento efectivo son bastante formales, pero mientras la programación sea hecha por gente que no las domina, la crisis del software permanecerá entre nosotros y será considerada una enfermedad incurable. Y ya sabe lo que provocan las enfermedades incurables: abren las puertas a curanderos y charlatanes, quienes en este caso toman la forma de gurús de la Ingeniería de Software.
• Algunos de ustedes dudan que las ya mencionadas “técnicas del razonamiento efectivo”, agradables como lo son para programas pequeños, sean escalables -cito- “dado el desalentador tamaño y la escarpada complejidad de muchos programas”. Bien, serán inútiles si se usan para desenmarañar el lío horrendo producido por un grupo de programadores incompetentes y desorganizados. Su poder se manifiesta en la etapa de construcción, donde (i) tienden a producir textos mucho más cortos de los que se producirían de otra forma y (ii) la longitud de las derivaciones de programas tienden a crecer no mucho más que linealmente con la longitud de los programas derivados. Finalmente, los programas así producidos son infinitamente mejores que la basura usual.
• No debemos olvidar que los programadores viven en un mundo de artefactos, un hecho que los distingue de la mayoría de los demás científicos. El programador no debe preguntar qué tan aplicables son las técnicas de buena programación, debe crear un mundo en el cual son aplicables; esta es la única manera de producir un diseño de alta calidad. A esto debo agregar una cita de EWD898 (1984):
  “Las capacidades de las máquinas nos dan lugar en abundancia para hacer un lío. ¡Oportunidades ilimitadas para ensuciar las cosas! Desarrollar la disciplina intelectual austera de mantener las cosas lo suficientemente simple es, en este entorno, un desafío formidable, tanto técnica como educativamente.”
• En respuesta a las preguntas de por qué enseñamos cosas inútiles que la industria ignora, los refiero a EWD920 (1985). Permítanme citar un párrafo:
  
  “Volviendo a la pregunta original: ¿puede la ciencia de la computación salvar a la industria de la computación? Mi respuesta es “Si la industria de la computación puede ser salvada, sólo la ciencia de la computación puede hacerlo”. Pero puede tomar mucho tiempo antes de que la industria de la computación -en particular, las compañías bien establecidas- compartan esta visión. Casi con seguridad tomará más que el periodo limitado por el cual planifican sus futuros. Mientras tanto, el mundo académico -que tradicionalmente planifica mirando mucho más adelante- no tiene elección. Tiene que refinar y enseñar al máximo de sus habilidades cómo debe ser hecha la computación; si cediera a la presión de propagar las malas prácticas actuales, sería mejor que quebrara.“

  Pero para destacar cuánta paciencia necesitamos, déjenme darles otra cita antigua (de 1988)

  “Muy poca gente reconoce que la alta tecnología tan celebrada actualmente es esencialmente una tecnología matemática.“

  (del reporte “2nd David”, llamado así en honor al director del comité, Dr. E. E. David Jr.)

• No, me temo que la ciencia de la computación ha sufrido la popularidad de Internet. Ha atraído a una cantidad creciente -¡por no decir abrumadora!- de estudiantes con muy poca inclinación científica, y en la investigación sólo ha consolidado la prevaleciente (y algo vulgar) obsesión con la velocidad y la capacitdad.
• Si, comparto su preocupación: cómo programar bien -aunque un tema enseñable apenas se enseña. La situación es similar en las matemáticas, donde el plan de estudios explícito está confinado a los resultados matemáticos; cómo hacer matemáticas es algo que el estudiante debe absorber por ósmosis, como el hablar. Una razón para preferir argumentos de cálculo mediante la manipulación de símbolos, es que su diseño puede enseñarse mucho mejor el diseño de argumentos verbales/pictóricos. La introducción a gran escala de cursos de tal metodología de cálculo, sin embargo, encontría problemas políticos insalvables.
• En el negocio del software hay empresas para las cuales no está claro que la ciencia pueda ayudarlas. Que la ciencia debería intentarlo tampoco está claro.

Austin, 28 de noviembre de 2000

prof. dr. Edsger W. Dijkstra
Departamento de Ciencias de Computación
Universidad de Texas
Austin, TX 78712 – 1188
USA

Niño: No trates de doblar la cuchara, eso es imposible. En cambio, sólo trata de darte cuenta de la verdad.

Neo: ¿Qué verdad?

Niño: La cuchara no existe.

AJAX es simplemente una técnica, o mejor dicho, la combinación de varias técnicas. Si bien su nombre significa “JavaScript y XML asincrónicos“, no tiene necesariamente que ver con Javascript ni con XML. De ahí el título de este artículo.

Un ejemplo simple

Supongamos que tenemos el siguiente script escrito en PHP, para realizar la búsqueda de personas por apellido:

buscar.php


<?
$personas = array (
              array ( "Javier", "Smaldone"),
              array ( "John", "Smith"),
              array ( "Santiago", "Lobos"),
              array ( "Jorge", "Lobatto")
            );
$apellido = $_POST['apellido'];
if ($apellido) {
  $respuesta = '';
  foreach ($personas as $indice => $persona) {
    if (preg_match("/^$apellido/i", $persona[1]))
      $respuesta .= "$persona[0] $persona[1]<br>";
  }
  if (!$respuesta)
    $respuesta = "<i>No hay coincidencias con '$apellido'</i>";
  print $respuesta;
}
?>


Como podemos apreciar, este script produce como salida la lista de personas cuyo apellido comienza con el valor de la variable apellido recibida desde el requerimiento HTTP. Dicha salida no es un documento HTML completo, sino solamente un fragmento (formateado con <br> y <i>). (Por simplicidad los datos de personas están almacenados en un arreglo, pero podrían también estar en una base de datos.)

Por otra parte, tenemos el siguiente archivo HTML:

buscar.html


<html>
<head>
  <title>Personas</title>
  <script type="text/javascript" src="buscar.js"></script>
</head>
<body>
  <form name="formulario" onsubmit="return false">
  <input type="text" name="apellido" autocomplete="off">
  <input type="button" value="Buscar" onclick="JavaScript:buscar()">
  </form>
  <div id="resultado"></div>
</body>
</html>


Podemos ver que este el documento HTML incluye el archivo buscar.js que contiene código JavaScript. Además, el formulario no tiene una acción asociada (el evento onsubmit siempre devolverá falso, por lo cual nunca se “enviará“). En cambio, el botón “Buscar” tiene asociado al evento onclick una llamada a la función JavaScript buscar(). Debemos notar, además, que el documento contiene un div vacío cuyo identificador es resultado.

A continuación, el contenido de buscar.js:

buscar.js


function buscar() {
  var form = document.forms['formulario'];
  var resultado = document.getElementById("resultado");
  var contenttype = 'application/x-www-form-urlencoded';

  var req;
  if (window.XMLHttpRequest) {
    req = new XMLHttpRequest();
  } else {
    req = new ActiveXObject("Microsoft.XMLHTTP");
  }
  req.open('POST', 'buscar.php', true);
  req.setRequestHeader('Content-Type', contenttype);
  req.onreadystatechange =
    function() {
      if (req.readyState == 4)
        resultado.innerHTML = req.responseText;
    }
  req.send('apellido=' + escape(form.apellido.value));
}


La función buscar() recupera los objetos formulario (el formulario) y resultado (el div inicialmente vacío). Luego crea el objeto req, de clase HMLHttpRequest (o un controlador ActiveX del tipo Microsoft.XMLHTTP en caso del siempre incompatible Internet Explorer).

Los objetos de clase XMLHttpRequest permiten realizar requerimientos al servidor sin necesidad de tener que “recargar” toda la página. Una vez creado, se configura a req para llamar a buscar.php usando el método POST, con el Content-Type correspondiente al envío de un formulario (application/x-www-form-urlencoded). El valor “true” significa que se trata de un requerimiento asincrónico, permitiendo que continúe la ejecución del script aunque el mismo no haya finalizado (este es el “truco” que logra la sensación de interactividad).

Luego, se configura el objeto req mediante el método “onreadystatechange” para que al finalizar la ejecución del requerimiento se modifique el contenido del div resultado, asignándole el texto obtenido como respuesta del servidor (responseText). Esto se logra asociándole una función sin nombre, lo que usualmente se denomina “callback“.

Finalmente, se envía el requerimiento, asignando a la variable CGI apellido el valor del campo apellido del formulario.

Probemos a continuación la ejecución de este ejemplo:

El resultado es claro: la función JavaScript asociada al evento onclick del botón Buscar realiza la llamada a buscar.php, enviándole el valor de la variable apellido, y escribiendo en el div resultado la salida producida.

Podemos ir un poco más allá, asociando la función buscar() al evento onkeyup del campo de texto apellido. Este evento ocurre cada vez que se “levanta” una tecla (o sea, cuando se ha ingresado un nuevo caracter). De esta manera obtendremos un comportamiento más “interactivo“.

El código de buscar.html quedaría cómo sigue:

buscar2.html


<html>
<head>
  <title>Personas</title>
  <script type="text/javascript" src="buscar.js"></script>
</head>
<body>
  <form name="formulario" onsubmit="return false">
  <input type="text" name="apellido" onkeyup="JavaScript:buscar()" autocomplete="off">
  </form>
  <div id="resultado"></div>
</body>
</html>


Y el resultado sería el siguiente:

Si lo desea, puede descargar el ejemplo completo (también en formato ZIP).

Conclusión

Esto que hemos visto es AJAX. Si bien hemos utilizado JavaScript para realizar el requerimiento “asincrónico”, podríamos haber usado cualquier tecnología “client-side” (VBScript, JScript, etc.). Tampoco hemos usado XML para recibir el resultado desde el servidor (nuestro script buscar.php produce fragmentos de código HTML).

Un elemento muy importante (y que no forma parte de la sigla AJAX) es el DOM (“Document Object Model“). Se trata de una API que nos permite modificar dinámicamente un documento HTML. Hemos usado esto en nuestro ejemplo, para modificar el contenido del div resultado.

AJAX abre todo un mundo de posibilidades a la hora de construir aplicaciones web altamente interactivas pero, a pesar de toda la palabrería que se construye a su alrededor no es mucho más de lo que hemos podido apreciar en el simple ejemplo analizado.

Una aclaración importante: como podrá apreciarse, realizar una aplicación compleja que maneje una gran cantidad de elementos (botones, divs, opciones, etc.) y una gran cantidad de eventos, sería extremadamente complejo si lo hiciéramos como en nuestro ejemplo. Es por esto que para la utilización de todo el potencial de AJAX en una aplicación, deberá utilizarse alguna biblioteca destinada a tal fin, que genere las funciones JavaScript necesarias para el control de los eventos y la realización de los requerimientos asincrónicos. Existe una gran cantidad de herramientas de este tipo, disponibles para distintos lenguajes de programación.

Lecturas recomendadas en Wikipedia:

• AJAX
• XMLHttpRequest
• Document Object Model (DOM)

Finalmente, un listado de 10 bibliotecas para desarrollar aplicaciones usando AJAX.

A continuación, la transcripción de la grabación (he quitado varias interjecciones y muletillas):

Alumno: ¿Qué es EJB?

Docente: ¿EJB? Enterprise Java Beans, Enterprise Java Beans es el… la Enterprise Java Beans son… dijéramos, los Beans, los Beans Java de las Empresas (risas). Pero… ¿qué es un Bean? Bean es un poroto (risas). No sirven para nada. Nos vuelven locos con estas porquerías (risas).

En realidad una Java Bean es una clase, que tiene métodos automatizados que lo definen. Hay métodos que… hay métodos… hay una clase que, que hace una clase, entonces hace de todo, van y le meten un método, un, un, un Java Bean Method. Entonces ¿un Java Bean Method qué es? Es un método, ustedes le ponen el nombre, les arma una serie de ventanas y les va a terminar agregando un método que ustedes podrían crear un método. Pero, dijéramos que toda la infraestructura les va a crear un método. Ese método, en realidad, es, podría ser un método para recuperar, o podría ser un método para escribir, o podría ser un método para grabar. O podría ser cualquiera de los otros métodos que los construirían ustedes. En general los que están construidos son los Enterprise Java Beans Service, que son métodos que uno directamente apretando botón derecho pin, pun, pun, pun, se van generando.

Beans es, es, es, es, dijéramos… y ustedes ven que hay… que hay Beans en todos lados, ¿no? Porque hay Beans en la parte de presentación, hay Beans en la parte de negocio y… y puede haber Beans en la parte de bases de datos también. Porque en realidad lo que son Beans son conceptos de clases, clases para ellos son Beans.

Alumno: ¿Clases específicas, Profesor?

Docente: Si, pero… es como que son objetos. Son específicas porque son clases que, te vuelvo a decir, que leen, o que graban, o que recuperan, o que… y entonces, en realidad, están propuestas con una serie de accesos rápidos. Fíjense que ustedes están todo dentro de un server, y ese server, o sea, eso se pone… se arman paquetes… tecnológicos… tecnológicos portes de… en donde están… interrelacionados con las otras capas, y las interrelaciones siempre las hacen a través de esos componentes J2EE. Los componentes, o sea, los software de las clases implementadas son componentes, o sea, por eso, a ver: componente, componente, componente, siempre componentes de las tres capas. Entonces ¿los componentes qué son? Software. Pero el software ese ¿dónde fue pensado? Fue pensado en las clases. Pero ahora son componentes, o sea que son software. Yo voy armando software y cuando, digo, se genera hay una serie de métodos que se generan automaticamente, no necesariamente en el J2EE, sino también en Java, pero por ejemplo que son los métodos setter and getter. Los métodos setter and getter es como que son métodos que ya están definidos, que uno directamente lo único que hace es cambiarle la variable que usa.

También pueden hacer el proyecto con Enterprise Java Beans, con elementos de J2EE. Algunas partes del sistema pueden hacer. Si estás e una relación cliente/servidor. O sea, miren toda la tengología que podríamos llegar a tener y aplicar en un ejercicio. En líneas generales si quieren aplicar todo, está a disposición de ustedes, el software lo permite, pero van a tener que sentar el culo y trabajar mucho, lo cual dudo que estén predispuestos a hacerlo. Aunque eso les reditúe mucho.

Como puede apreciarse, el Lic. Rubén Fernandez Iriart no tiene la más remota sospecha sobre tema que está tratando (y ni hablar de su uso del idioma castellano). Peor que eso, en vez de disculparse y comprometerse a responder en una clase posterior (como haría cualquier persona con un poco de vergüenza), encara hilvanando un sinfin de frases sin sentido, encadenando las palabras “clase“, “objeto“, “componente“, “mensaje“, “capa“, “servicio“, “paquete“, “software“, etc. Para terminar, quizás tratando de justificar su propia ignorancia y no quedar tan en evidencia, finaliza la explicación desmereciendo y rebajando a sus alumnos, dando a entender que si no logran comprender, es por su falta de disposición (y no por la ignorancia de quien habla).

No clasifico este artículo en la categoría “humor” porque yo también me encontré con este tipo de docentes (casualmente en la UTN Fac. Córdoba) y a punto estuve de dejar la informática por ello. Quizás el daño más grande fue que, al ver la ignorancia de este tipo de “profesores“, sobrevalué mis conocimientos. Me llevó años darme cuenta de que, aunque sabía mucho más que varios de ellos, en realidad sabía poco y nada. Claro que este tipo de “docente” no es patrimonio exclusivo, ni mucho menos, de la UTN (me los he encontrado en varias universidades, con el atenuante de que al menos en algunas de ellas no son mayoría).

Pero la cosa no termina ahí. El Lic. Fernandez Iriart, que parece haberse ganado la antipatía de muchos de sus alumnos (y escuchando su clase se entiende el por qué), es el Presidente del Consejo Profesional de Ciencias Informáticas de la ciudad de Buenos Aires (¡con el “honor” de tener la primera matrícula, número 0001!).

Desde ese Consejo Profesional, que supuestamente “avala la idoneidad de los profesionales de las ciencias informáticas“, este señor se dedica a dictar cursos sobre análisis y diseño orientados a objetos, UML, arquitecturas basadas en “componentes“, etc.

Si este es el tipo de personas que se encarga de representar ante la comunidad a los profesionales de la computación, creo que sumo un punto más en contra de la matriculación obligatoria.

Ver a personas así, arruinando la educación (y quizás la cabeza) de sus alumnos, cobrando un sueldo del estado y, a la vez, representando a los profesionales informáticos, da mucha pena, bronca y, sobre todo, mucha vergüenza…

A través de este sencillo experimento, podremos recorrer los conceptos fundamentales de las redes TCP/IP, para reafirmar la idea de que este protocolo es muy simple. El objetivo es lograr, sin demasiados conocimientos previos, una comprensión profunda de sus mecanismos.

También puede descargar este tutorial en otros formatos (HTML sin decoraciones y PDF).

Requisitos previos

No se requieren conocimientos de programación, aunque sí una base de conocimientos informáticos en general. Para continuar experimentando más allá de los expuesto aquí, se recomienda la utilización del programa Wireshark (antes conocido como Ethereal), disponible para GNU/Linux, Microsoft Windows, Mac OS/X y Solaris .

Quizás el requisito más importante sean las ganas de aprender, investigar, jugar y divertirse con redes TCP/IP.

Referencias

Cada vez que se introduzca un término relevante, el mismo contendrá un enlace a una página con mayor información, por lo general de la Wikipedia y, de ser posible, en español (aunque se recomienda ampliamente visitar su equivalente en inglés).

Un libro muy recomendable y claro (en inglés) es “TCP/IP Illustrated Volume 1” de W. Richard Stevens. Finalmente, la fuente de consulta definitiva, para conocer tanto los aspectos técnicos como la evolución historica de cada uno de los protocolos y normas, son los Request for Comments (RFC), algunos de los cuales han sido traducidos al español.

Nuestro experimento

Estableceremos una conexión TCP/IP entre un cliente y un servidor que intercambiarán información. Para ello, utilizaremos el servidor desarrollado en el tutorial sobre programación en redes (no es necesario que lo lea completamente, si no le interesa la programación, pero sería conveniente que revise los conceptos introductorios y el protocolo definido).

Ejecutamos entonces el servidor en el host 100.0.0.1, utilizando el puerto 2222 (cualquiera de las versiones desarrolladas en el tutorial anterior sirve, ya que el protocolo es idéntico) y usamos el comando telnet para actuar como cliente desde el host 200.0.0.1 (el texto en cursiva es introducido por nosotros y el texto en negrita es la respuesta del servidor):

javier@200.0.0.1:~$ telnet 100.0.0.1 2222
Trying 100.0.0.1...
Connected to 100.0.0.1.
Escape character is '^]'.
Bienvenido.
salir
Adios.
Connection closed by foreign host.
javier@200.0.0.1:~$

Esto es todo. Ahora procederemos a analizar cómo se ha llevado a cabo esta comunicación a distintos niveles de abstracción.

Nivel de aplicación

A “nivel de aplicación” (lo que “ven” los programas), la comunicación se ha desarrollado de la siguiente manera:

1. El cliente se conecta al servidor.
2. El servidor envía el mensaje “Bienvenido.“.
3. El cliente envía el comando “salir“.
4. El servidor responde con el mensaje “Adios.“.
5. El servidor cierra la conexión.
6. El cliente cierra la conexión.

Esto es prácticamente lo mismo que podemos observar de la salida del comando telnet utilizado, lo cual no es casual; intencionalmente a este nivel se ocultan todos los detalles de implementación, que aparecerán cuando analicemos los niveles inferiores.

Nivel de transporte

El protocolo utilizado a “nivel de transporte” es TCP. Este protocolo es el encargado de establecer la conexión y dividir la información en paquetes, garantizando que los mismos son entregados correctamente (sin pérdidas y en el orden apropiado).

Cabe resaltar aquí que el otro protocolo de transporte de TCP/IP, UDP no garantiza ni el arribo de todos los paquetes enviados, ni el orden en que estos llegan a destino. Por esto es mucho más simple, no incluyendo algunas de las características de TCP como números de secuencia y asentimientos.

A continuación analizaremos algunos aspectos del protocolo TCP.

Puertos y direcciones

El protocolo TCP se basa en direcciones IP para identificar los equipos (hosts) desde donde provienen y hacia donde se envían los paquetes.

Los puertos (ports) son valores numéricos (entre 0 y 65535) que se utilizan para identificar a los procesos que se están comunicando. En cada extremo, cada proceso interviniente en la comunicación utiliza un puerto único para enviar y recibir datos.

En conjunción, dos pares de puertos y direcciones IP identifican univocamente a dos procesos en una red TCP/IP.

Números de secuencia

TCP garantiza que la información es recibida en orden. Para ello, cada paquete enviado tiene un número de secuencia. Cada uno de los dos procesos involucrados mantiene su propia secuencia, que se inicia con un valor aleatorio y luego va incrementándose según la cantidad de bytes enviados.

Por ejemplo, si un paquete tiene número de secuencia x y contiene k bytes de datos, el número de secuencia del siguiente paquete emitido será x + k. (Sí, el número de secuencia va contando la cantidad de bytes enviados por cada host.)

Paquetes y acuses de recibo

TCP también asegura que toda la información emitida es recibida. Para ello, por cada paquete emitido, debe recibirse un asentimiento (en inglés “acknowledgement“, abreviado ACK). Si pasado determinado tiempo no se recibe el ACK correspondiente, la información será retransmitida.

El ACK hace referencia al número de secuencia (que ha su vez involucra la cantidad de bytes enviados). Por ejemplo, para comunicar que se ha recibido correctamente el paquete cuyo número de secuencia es x, que contiene k bytes, se enviará un ACK con el valor x + k (que coincide con el próximo número de secuencia a utilizar por parte del emisor del paquete en cuestión). Si el número de secuencia inicial es x, un valor de ACK t significa que el receptor ha recibido correctamente los primeros t-x bytes (en este sentido, el ACK es acumulativo).

El ACK no es un paquete especial, sino un campo dentro de un paquete TCP normal. Por esto, puede ocurrir que se envíe un paquete a solo efecto de asentir una determinada cantidad de bytes, o como parte de un paquete de otro tipo (por ejemplo, aprovechando el envío de nuevos datos, para comunicar la recepción de datos anteriores). De hecho, aunque ya se haya enviado un paquete exclusivamente de ACK con un valor t, si luego se envía un paquete de datos, puede repetirse en él el ACK con el mismo valor t, sin que esto confunda al emisor de los datos que se están asintiendo. (Por simplicidad, en nuestro ejemplo hemos eliminado esta información redundante).

Otros campos de un paquete TCP

El protocolo TCP incorpora mecanismos tales como control de integridad de los datos (checksum), prevención de congestiones, entre otros, que no serán mencionados aquí por la simplicidad de este tutorial.

Inicio y fin de la conexión

Para dar comienzo a la conexión, el cliente envía un paquete SYN al puerto e IP en donde “escucha” el servidor, con un número de secuencia inicial aleatorio. Este último, responde con otro paquete SYN, con un número de secuencia inicial aleatorio y un ACK con el número de secuencia del paquete SYN recibido, más uno. El cliente envía un paquete con el ACK del SYN recibido, y una vez hecho esto la conexión se encuentra establecida y puede darse comienzo a la transmisión de datos (iniciada por cualquiera de las partes, según el protocolo de aplicación que utilicen).

La razón por la cual se intercambian números de secuencia aleatorios es para evitar que se confunda el inicio de dos conexiones diferentes y algunos ataques que se basan en falsear el comienzo de una conexión (spoofing).

La siguiente figura ilustra el establecimiento de una conexión TCP, llamada “negociación de tres pasos” o “3-way handshake“:

Para finalizar la conexión, uno de los dos procesos envía un paquete FIN, a lo que el otro responderá con un ACK. A su vez, el otro proceso puede enviar un paquete FIN (recibiendo también un ACK) y la conexión quedará cerrada definitivamente.

Nótese que el segundo proceso puede no enviar el paquete FIN. Esto significa que ese extremo de la conexión no se cerrará, pudiendo aún enviar datos a través de la misma. De lo contrario, en caso de desear terminar la conexión, puede combinar el ACK y el FIN en un solo paquete (esta es la situación más común).

La siguiente figura ilustra la forma general de terminación de una conexión TCP:

Análisis a nivel de transporte

Habiendo revisado los conceptos más relevantes, analizaremos ahora la conexión realizada desde el punto de vista del protocolo TCP. Supondremos que el puerto utilizado por el cliente es 4683 (el del servidor, recordemos, es 2222).

La siguiente figura muestra una visión simplificada de esta conexión:

(Ver imagen ampliada)

Veamos qué función cumple cada paquete:

1. El cliente envía un SYN al servidor, con número de secuencia x₀.
2. El servidor responde con un paquete SYN, con número de secuencia y₀ y un ACK con x₀+1 (en adelante, x₁).
3. El cliente envía un paquete ACK del SYN que acaba de recibir, con valor y₀+1 (en adelante, y₁). (A partir de este momento la conexión se encuentra establecida y puede comenzar el intercambio de datos entre las aplicaciones.)
4. El servidor envía un paquete PSH (“push“) conteniendo la cadena “Bienvenido.\n” (12 bytes), con número se secuencia y₁. (El caracter “\n“, newline, representa el fin de línea.)
5. El cliente envía un ACK por la correcta recepción del paquete anterior. El número de ACK es y₁+12 (que llamaremos y₂ y será el próximo número de secuencia utilizado por el servidor).
6. El cliente envía la cadena “salir\r\n“, con número de secuencia x₁. (Los caracteres “\r\n” representan el fin de línea. Ver nota al final de la sección.)
7. El servidor envía el ACK correspondiente, con el valor x₁ más la longitud de “salir\r\n” (7), que llamaremos x₃.
8. El servidor envía la cadena “Adios.\n” (7 bytes), con número de secuencia y₂.
9. El cliente envía el ACK con el valor y₂+7 (en adelante, y₃).
10. El servidor cierra su lado de la conexión enviando un paquete FIN, con secuencia y₃.
11. El cliente, que también cierra su conexión, envía un paquete FIN con secuencia x₃, con el ACK del paquete anterior (y₃+1).
12. El servidor envía el ACK del anterior paquete FIN (con valor x₃+1), con lo cual la conexión finaliza.

Nota: En este ejemplo podemos ver un error en el diseño del protocolo de aplicación, ya que el servidor representa los fines de línea con el caracter “\n” (“newline”, código ASCII 10), en tanto que el cliente está usando los caracteres “\r\n” (“newline” y “carriage return”, códigos ASCII 10 y 13, respectivamente). Esta última es la forma de representación más utilizada en aplicaciones TCP/IP.

Nivel de red

Antes de realizar el análisis a “nivel de red” (protocolo IP) vamos a suponer que tenemos la siguiente topología:

El cliente se ejecuta en el host cuya dirección IP es 200.0.0.1. El mismo está conectado a la red local 200.0.0.0/24 y su gateway (“router“, “enrutador” o “puerta de enlace“) es el host 200.0.0.21.

La dirección de red local está compuesta por la dirección de red propiamente dicha, 200.0.0.0, y la máscara de red, 24 (que también puede ser representada como 255.255.255.0). Esto significa que los primeros 24 bits de cualquier dirección serán interpretados como identificador de la red, en tanto que los últimos 8 identificarán a cada host (recordemos que, aunque la notación usual es escribir las direcciones IP como cuatro números decimales separados por puntos, en realidad se componen de 32 bits).

Por ejemplo, en el contexto de esta red, la dirección 200.0.0.45 será considerada una dirección local (por coincidir los primeros 24 bits con los de la dirección de red). Esto significa que cualquier paquete destinado a dicha dirección IP, será entregado “localmente” (o sea, directamente a través del protocolo de enlace, como veremos más adelante).

En el caso de una dirección de destino “no-local”, los paquetes serán entregados al gateway 200.0.0.21 (usando el protocolo de enlace), quien será luego el encargado de entregar el paquete al host de destino (si este perteneciera a alguna red local a la que dicho gateway esté conectado), o reenviarlo a través de otro gateway (en caso contrario).

De la misma manera el servidor, cuya dirección IP es 100.0.0.1, pertenece a la red 100.0.0.0/24, cuyo gateway es 100.0.0.35.

Análisis a nivel de red

A nivel IP no hay demasiado que agregar. Aquí se realiza el “ruteo” (o “encaminamiento“) de los paquetes provenientes de la capa de transporte (que en este nivel se denominan “datagramas“) desde la dirección IP de origen hasta la de destino (alternando estos roles 100.0.0.1 y 200.0.0.1 según sea el emisor el servidor o el cliente, respectivamente).

Un campo interesante que se añade es el TTL (“tiempo de vida” o “time to live“), que tiene un valor inicial en el host que produce el paquete (generalmente 64) y luego es decrementado por cada gateway por el que pasa. Si un gateway recibe un paquete con el campo TTL en cero, el mismo es descartado y se genera un paquete del protocolo ICMP (usado para control y mensajes de error) dirigido a su emisor, indicando que dicho paquete ha excedido la cantidad máxima de saltos. Esta medida es implementada para evitar que, quizás por un error de ruteo, un paquete quede indefinidamente “dando vueltas” por la red.

En este ejemplo supondremos que el enrutamiento de paquetes es simple (estático), para facilitar las explicaciones. Existen casos complejos en donde se utiliza enrutamiento dinámico, en los cuales paquetes pertenecientes a la misma comunicación pueden enviarse por caminos distintos, alterando inclusive el orden en que llegan al destino (y hasta pudiendo producirse pérdidas).

Debemos tener en cuenta que estamos usando el llamado IPv4 (IP versión 4), ya que también existe el IPv6 (IP versión 6), cuya aplicación se está difundiendo rápidamente en Internet y que soluciona muchos inconvenientes que presenta el anterior.

Nivel de enlace

El “nivel de enlace” es el nivel más cercano al “nivel físico” y es totalmente independiente del protocolo TCP/IP. Existen gran variedad de tecnologías de este tipo; siendo las más comunes Ethernet, WiFi, PPP, Frame Relay, ATM, entre otras.

Supondremos el caso más común: una red Ethernet. Este protocolo se basa en el uso de direcciones de 6 bytes (48 bits), que no son “ruteables” (aquí no existen gateways), por lo cual se utiliza en redes de área local (LANs). Cada dispositivo Ethernet tiene asociada una dirección única (asignada por el fabricante del mismo), la que usualmente se denomina MAC Address.

Resolución de direcciones

Supongamos que el host 200.0.0.1 quiere enviar un paquete IP al host 200.0.0.33. Como ambos están en la misma red local (los primeros 24 bits de sus direcciones coinciden), lo único que debe hacer es averiguar cuál es la dirección Ethernet de este último. Para ello, se utiliza el protocolo ARP (“Address Resolution Protocol“).

El funcionamiento es muy simple. El host 200.0.0.1 envía un paquete (en terminología de Ethernet se denomina “frame“) a la dirección ff:ff:ff:ff:ff:ff (las direcciones Ethernet se denotan con seis bytes en hexadecimal separados por dos puntos), que es la dirección de broadcast (que llega a todos los hosts de la red) preguntando quién tiene la dirección IP 200.0.0.33. Dicha solicitud ARP tiene como origen la dirección Ethernet del emisor (supongamos, 00:30:b8:80:dd:11).

El poseedor de esa dirección IP le responderá con otro frame con su dirección Ethernet como origen (supongamos, 01:4e:bb:a1:01:8b). De ahora en más, cada vez que el host 200.0.0.1 quiera enviar un paquete IP al host 200.0.0.33, enviará un frame Ethernet proveniente de la dirección 00:30:b8:80:dd:11 a la dirección 01:4e:bb:a1:01:8b, conteniendo el paquete original. (La información sobre las direcciones ARP se almacenan en cada host en una tabla que tiene una duración de algunos minutos.)

Fragmentación

Puede ocurrir que el tamaño de los paquetes producidos por la capa de red (IP, en nuestro caso) sean de un tamaño mayor al máximo que puede transmitir el medio físico utilizado (MTU o “unidad máxima de transferencia“. Por esto, puede ocurrir que los paquetes se fragmenten, para acomodarse a esta limitación.

Esta situación puede volver a presentarse a lo largo del camino “físico” que recorra la información, siendo responsabilidad de cada gateway el fragmentar y reensamblar los paquetes para preservar los datos.

Análisis a nivel de enlace

Volviendo ahora a nuestro experimento, el host donde se ejecuta la aplicación cliente (200.0.0.1) debe enviar paquetes IP al host en donde se ejecuta el servidor (100.0.0.1). Claramente, éste último no pertenece a su red local, por lo cual deberá enviarlo a través del gateway.

Para ello, usando el protocolo ARP averigua la dirección Ethernet del gateway (cuya dirección IP, recordemos, es 200.0.0.21), que supondremos es 00:01:02:ed:41:61. Una vez hecho esto, envía un frame Ethernet (con origen
00:30:b8:80:dd:11 y destino 00:01:02:ed:41:61), conteniendo el paquete IP cuyo origen es 200.0.0.1 y con destino a 100.0.0.1.

El gateway recibirá el frame (puesto que la dirección Ethernet de destino es la suya) y dentro de él encontrará un paquete IP dirigido a 100.0.0.1. Decrementará el campo TTL y, en base a las reglas definidas en su “tabla de enrutamiento” (o “tabla de ruteo“), lo reenviará hacia el gateway correspondiente (usando el protocolo asociado al medio físico mediante el cual esté conectado con éste).

Una situación similar se presenta considerando los paquetes emitidos por el host 100.0.0.1 hacia 200.0.0.1.

De esta manera, el mismo paquete IP va atravesando distintos gateways a través de distintos medios físicos (que involucran diferentes protocolos de enlace), hasta llegar al host de destino. Por ejemplo, el paquete original puede llegar al primer gateway a través de un frame Ethernet, ser enviado por este al gateway del proveedor de Internet a través de un paquete PPP, atravesar una red ATM en Internet, luego llegar por un enlace Frame Relay al gateway de la red de destino, y ser entregado en otro frame Ethernet al host de destino.

El camino de la información a través de las distintos niveles

La siguiente figura ilustra un ejemplo del camino que sigue la información desde la aplicación que la produce, a través de los distintos niveles o capas de cada protocolo.

(Ver imagen ampliada)

Nota: Este ejemplo es una simplificación de la realidad. Se han omitido muchos otros datos que forman parte de cada protocolo (controles de error, delimitadores, indicadores de longitud, etc.), que no son relevantes en el contexto de este tutorial.

1. Nivel de aplicación: La aplicación (en este caso, el programa cliente), escribe la cadena “salir\n“.
2. Nivel de transporte: En la capa TCP forma un paquete agregando el número de secuencia (20), puerto de origen (4781) y puerto de destino (2222).
3. Nivel de red: En la capa IP se forma un paquete (datagrama) añadiendo la dirección IP origen (200.0.0.1), destino (100.0.0.1), el TTL (64) y un valor que identifica el protocolo del paquete encapsulado (0×06, valor hexadecimal que representa al protocolo TCP).
4. Nivel de enlace: En la capa Ethernet se forma un nuevo paquete (frame) agregando las direcciones Ethernet de origen (00:30:b8:80:dd:11) y destino (00:01:02:ed:41:61, la dirección del gateway, cuya IP es 200.0.0.21). Se añade además el identificador del tipo de protocolo del paquete contenido (el valor 0×800 corresponde al protocolo IP).
5. Nivel físico: El frame formado es enviado a través del medio físico que vincula los hosts de la red local (típicamente, cable de par trenzado).

Como puede apreciarse, tanto el protocolo IP como Ethernet “encapsulan” a otros protocolos. Esto permite realizar distintas combinaciones, creando “túneles” (como en el caso del ampliamente difundido y utilizado PPPoE).

Software, modelo conceptual y hardware

El siguiente diagrama muestra la relación entre cada uno de los componentes lógicos analizados, su implementación y la división entre hardware y software.

Para finalizar

En este tutorial hemos recorrido cada uno de los principales componentes del protocolo TCP/IP y analizado su función a través de un ejemplo concreto (aunque simple).

Deliberadamente, hemos omitido algunos puntos importantes, como el sistema DNS (que posibilita la utilización de nombres en vez de direcciones IP), la asignación automática de direcciones IP (a través del protocolo DHCP), y algunos detalles sobre direccionamiento y enrutamiento IP. (Quizás algunos de ellos sean motivo de próximos tutoriales.)

Es el deseo del autor que a través de la lectura del presente tutorial se haya podido lograr un panorama general acerca del funcionamiento de las redes TCP/IP, posibilitando al lector su avance hacia temas (y, por qué no, experimentos) más complejos e interesantes.

Las críticas, sugerencias y comentarios son bienvenidos y agradecidos.

(Recuerde que puede descargar este tutorial en otros formatos (HTML sin decoraciones y PDF).)

Actualización del 5 de diciembre de 2006: He publicado un artículo sobre el funcionamiento del DNS, uno de los temas no cubiertos por el presente tutorial.

Ya desde el comienzo (al leer el manual de referencia de este lenguaje visual y el libro que describe la metodología), me resultó bastante incómodo, poco expresivo y hasta inconsistente en algunos aspectos. Con el correr del tiempo (al conocer otras metodologías de diseño de sistemas y al adquirir mayor experiencia en el campo), fui afianzando mi opinión sobre UML: es totalmente inútil y contraproducente.

Se que quizás estas afirmaciones suenen un poco fuertes, pero realmente no puedo utilizar términos más suaves para describir a este “lenguaje visual” y su metodología asociada. Reconozco que algunos de sus diagramas pueden ser útiles para modelar algunos aspectos de algunos tipos de sistemas, pero en general, es una pésima idea utilizar UML para documentar el proceso de desarrollo de software y el Proceso Unificado para conducirlo.

Para empeorar la situación, es tal la campaña publicitaria que se ha montado alrededor de UML desde su aparición, que en la actualidad es la notación preferida por muchos que dicen utilizar metodologías orientadas a objetos (entre ellos el Object Management Group). El por qué del éxito y la inutilidad de UML parecen estar explicados en un sólo párrafo (extraído del artículo “A Comparison of the Business Object Notation and the Unified Modeling Language” de Richard Paige y Jonathan Ostroff, cuya lectura recomiendo ampliamente):

En 1995, existían entre 20 y 50 notaciones y lenguajes de este tipo. A menudo, los usuarios tenían que elegir entre varios lenguajes de modelado similares con diferencias menores en poder expresivo global. Pero en un encuentro decisivo en Silicon Valley en 1995, metodistas y productores de herramientas acordaron que los usuarios necesitaban un estándar mundial para el metamodelado y la notación. En ese momento nació UML, y ha sido adoptado por desarrolladores de software principales.

Está claro entonces que UML nació de la necesidad de unificar un gran número de notaciones diferentes, y más como un acuerdo comercial que como el producto de una investigación profunda. Esto también queda en evidencia por el hecho que sus tres principales autores (Grady Booch, Ivar Jacobson y James Rumbaugh) se asociaron para crear una empresa (Rational Software, luego adquirida por IBM). Nada demasiado bueno puede surgir de la unión apresurada de un montón de cosas incompletas guiada por objetivos comerciales. UML y el Proceso Unificado nunca fueron más que eso.

Afirmo esto sin importarme que UML sea quizás la notación más utilizada en la industria actualmente. Como bien dijo Dijkstra, “los errores industriales no son sacrosantos sólo porque se cometan a gran escala“. (Si lo que usted busca es trabajo, probablemente necesite conocer UML, pero eso no lo transforma en una mejor herramienta.)

En 1997 Bertrand Meyer (creador del lenguaje Eiffel que se apega al método BON) escribío un artículo de tono gracioso (en el que un supuesto estudiante escribe a su profesor) llamado “UML: The positive spin” en el que desnuda las principales falencias de UML (en un tono para nada respetuoso, debo decir).

Después de años de tenerlo en mi lista de artículos a traducir, finalmente me he decidido a hacerlo. Ojalá sirva de utilidad a quienes hayan sido víctimas de la campaña publicitaria en favor de UML.

(También puede descargar la versión en PDF de este artículo.)

UML: El giro positivo

Por Bertrand Meyer

De: Cándido Smith, alumno de OO-101
A: Profesor Severa Stern
Asunto: Mi solicitud para el cambio de calificación

Estimado Profesor Stern:

El auxiliar de cátedra de su clase OO-101 me ha indicado que le escriba directamente sobre la calificación D-menos que obtuve en mi artículo “Una evaluación sobre el Lenguaje de Modelado Unificado (UML) propuesto“. Espero que usted considere cambiarla por una mejor (¿quizás una D?), ya que sería un alivio para mi promedio de calificaciones, ya debilitado luego del “Reprobado” que me puso en su última clase. (Quizás recuerde que en el examen final escribí “debe haber otras cosas entre las rebanadas de pan y Java“. Ahora me doy cuenta de lo poco aconsejable que fue ese comentario, y sinceramente pido disculpas si herí los sentimientos de alguien.)

Por supuesto, me doy cuenta del motivo de mi D-menos y aprecio su generosidad en no ser haber sido más duro. Como el auxiliar de cátedra me indicó, ¡no hay nada positivo sobre UML en mi artículo! Seguramente no puede ser correcto. Todo el mundo sabe que UML abre una brecha en la ingeniería de software, ¿y quién soy yo para cuestionar esto? Este es el por qué no le pido que cambie mi nota sólo por el efecto en mi promedio, aunque espero entenderá que no es agradable perder mi seguro de Buen Estudiante, por no mencionar novias y cosas por el estilo. No, admito que estaba equivocado y quiero enmendar mi error. Debe haber algo bueno que decir sobre UML.

Y puedo asegurarle que aprenderé la lección: ser positivo. Cualquiera sea el tema, siempre es posible darle un giro positivo. ¡El diario de esta mañana hasta imprimió un adjetivo que puede ser interpretado como no poco favorecedor en un artículo sobre Newt Ginrich! ¿Por qué entonces no sobre UML?

¡Se positivo!

Por lo tanto he seguido el consejo del auxiliar de cátedra. Por ejemplo, podría haber cosas buenas que decir sobre la notación misma. Podría ser simple, usable, convincente, fácil de aprender. Y hay de hecho tal notación para el análisis y el diseño orientados a objetos, cuyo conjunto completo de símbolos gráficos cabe en una página y cubre todas las técnicas básicas de descripción de sistemas Orientadas a Objetos, y el cual es particularmente bueno al escalar hasta la descripción de sistemas de gran envergadura: la Notación de Objetos de Negocios (BON) de Waldén y Nerson, como está descripta en su libro [3]. Por supuesto UML no tiene ninguna de esas propiedades. En su intento de mostrar que ha incluido las ideas de todos, es un desborde de símbolo tras símbolo bizarros. Solo el “Resumen de la notación” ocupa 60 páginas y ¡tiene su propio índice! UML es, de hecho, tan complejo como un lenguaje de programación grande y críptico, con un uso generoso de “$” y “#” y “-” y “*” y “triángulos sólidos sin cola” y rectángulos y diamantes y líneas sólidas y líneas punteadas y elipses sólidas y elipses punteadas y flechas de todo tipo y palabras reservadas tomo “const” y “sorted” (no confundir con “ordered“) y semánticas distintas para una clase dependiendo si su nombre aparece en letra “romana” o “itálica”. ¡Pero al menos un lenguaje de programación, incluso el peor de ellos, es ejecutable! Aquí hay que aprender toda esa complejidad monstruosa para construir diagramas de un posible sistema futuro.

Lo cual nos lleva a la pregunta del desarrollo continuo (“seamless”). Una vez que usted tiene su hermoso (o no tan hermoso) diagrama, querrá construir un sistema, salvo que el presupuesto ya se haya gastado en herramientas CASE (algo común para empresas que toman demasiado enserio la publicidad exagerada de la “metodología” y terminan sin dinero para el desarrollo real). Pero entonces debe recomenzar con un lenguaje de programación para hacer el trabajo real. ¿Y cómo mantiene la consistencia entre el programa y los diagramas? Waldén y Nerson convincentemente discuten el objetivo de continuidad (proveer un proceso único y continuo) y reversibilidad (ser capaces de moverse hacia atrás y hacia adelante entre el análisis, el diseño y la implementación). Herramientas como EiffelBench y EiffelCase soportan esta inquietud, pero no parece ser para nada una inquietud con UML. Pero por supuesto cualquiera que use UML debe ser listo -no solamente para aprender todos los símbolos- y por lo tanto hará un análisis correcto desde la primera vez, luego un diseño correcto desde la primera vez y luego nunca tendrá que cambiar nada en los próximos diez años de la vida del proyecto. O quizás UML es para proyectos cuyas especificaciones nunca cambian. Mi abuela me contó que una vez escuchó sobre un proyecto así en su juventud. Creo que dijo que tenía algo que ver con calcular el 6to. número de Fibonacci.

¿Orientado a Objetos?

Así es que tengo que buscar en otra parte para encontrar algo positivo que decir sobre UML. Estoy tratando con esfuerzo, y espero que lo tome en cuenta antes de enviar las notas finales a la administración. (Recuerde, sólo estoy pidiendo una D, aunque por supuesto una C-menos sería más que apreciada.) Por ejemplo, he intentado ver si podría caracterizar a UML como “orientado a objetos”; todos sabemos que este es un gran logro. Gran oportunidad. Por supuesto los autores hacen uso de los requeridos “objeto“, “herencia“, etc. Pero una simple mirada a los diagramas muestra a UML como lo que es: una extensión del modelado de entidad-relación. Los ejemplos básicos muestran asociaciones binarias y ternarias, tales como (página 16 de [1]) asociaciones entre “vuelo“, “asiento” y “persona“; esto es diametralmente opuesto al diseño orientado a objetos, donde, como todos sabemos, el mundo está estructurado en clases, construido sobre tipos de objetos y cada operación o propiedad pertenece a una clase. Seguramente en diseño orientado a objetos, ¡no podrá tener un enlace “pasajero” que trate simétricamente a “asiento“, “vuelo” y “persona“! En un sistema orientado a objetos, pertenecerá a una de las clases; así es como se obtiene la consistencia, simplicidad, modularidad y reusabilidad de la arquitectura OO. Fíjese en BON o Eiffel y disfrute los resultados. Los autores de UML saben esto, por supuesto; para entender por qué llaman a UML orientado a objetos debemos apreciar su famoso sentido del humor. Obviamente lo dicen en broma. (¿Es esto lo suficientemente positivo?)

La evidencia posterior de la broma es provista por la referencia frecuente a los “casos de uso” como un elemento central del método. Cuando “caso de uso” era la consigna de la Web, traté de entender de qué se trataba, y me fue difícil hasta que le pregunté a mi abuelo, quien me lo explicó todo: es el nuevo nombre para el análisis funcional descendente (top-down) de su adolescencia. Uno se fija en qué debe hacer el sistema (“casos de uso”) y deduce su arquitectura de ese análisis. Esto es diametralmente opuesto al diseño orientado a objetos, el cual conscientemente rechaza prestar demasiada atención, durante las primeras etapas, a las funciones principales del sistema, porque están muy sujetas a cambios, porque reproducen el comportamiento de sistemas previos (aquellos que estamos tratando de reemplazar con el nuevo sistema), porque llevan a un compromiso temprano con el orden de operación (¿el aspecto más volátil del software?) y porque se enfocan en las cualidades superficiales del sistema -su interfaz con el resto del mundo- en vez de en sus propiedades fundamentales. En cambio, el diseño OO se concentra en el tipo de los objetos manipulados por el sistema, y define cada uno de esos tipos a través de la lista de todas las operaciones aplicables y sus propiedades abstractas -contratos- sin importar el orden de aplicación. Mi abuelo agregó que estaba agradecido de que los casos de uso estuvieran presentes en UML, porque le traían recuerdos de los buenos viejos tiempos y que nunca le gustaron los objetos. (Creo que este es un comentario positivo.)

Encontrando un uso para UML

Obviamente UML no será útil a ningún desarrollador de software. ¿Podría quizás ser útil a alguien más? ¿Líderes de proyectos, quizás? ¿Ejecutivos de empresas? ¿Las empresas mismas? Por supuesto, no. De hecho, la documentación no hace ninguna pretensión de tal utilidad, y por buenas razones. Es difícil de imaginar qué benericio podría obtener un negocio de páginas de diagramas crípticos sobre propiedades confusas de un sistema pobremente comprendido.

Por lo tanto, busco más allá. A veces una propuesta ofrece una solución fallida, pero tiene el mérito de plantear el problema correcto. ¿Podemos decir esto de UML? Espero que sí. Aunque sea podría ayudar a mi promedio y, haciendo esto, me ayudaría a levantar mi autoestima, por no mencionar las novias y cosas por el estilo, pero me estoy desviando. Dicho sea de paso, ¿a qué problema apunta UML? He tratado con empeño, en los interminables documentos del sitio web de Rational, de encontrar una descripción del problema (lo cual se nos enseñó en nuestros cursos de ingeniería, debería aparecer en la introducción de cualquier documento técnico). Me temo que no he encontrado nada útil que reportar.

Amanda al rescate

Para ver qué metas debería haber perseguido, revisé el artículo de mi amiga Amanda Suertuda, la única que obtuvo un A-mas:
“Los desafíos de la industria del software“. (De paso, profesor, no logro comprender por qué Amanda siempre consigue los temas interesantes.) Su reporte, muy agradable debo confesar, hace un buen trabajo al describir los obstáculos técnicos que los desarrolladores deben superar. El buen software debe ser correcto; olvidemos una aserción en una rutina, y tendremos un desastre de u$s500 millones como la reciente explosión del Ariane 5, resultado de un intento equivocado de reutilizar una rutina de Ada sin un mecanismo de aserciones como el de Eiffel (ver la edición de enero de 1997 de IEEE Computer). No veo nada en UML que ayude a la corrección; sólo algo de palabrería dedicada a la noción de contrato, pero los autores muestran que no entienden nada de la idea del Diseño por Contratos (por ejemplo, ¡mezclan requerimientos semánticos con simples declaraciones de tipos!). El buen software debe ser robusto. ¿Cómo ayuda UML? El buen software debe ser fácil de modificar (Amanda llama a esto “extensibilidad“); pero el aparato pesado de UML garantiza cualquier cosa menos que los desarrolladores serán capaces de producir alguna descripción del sistema en la cual no será horroroso cambiar algo. El buen software debe ser reutilizable; nada en UML apunta a los desafíos de la reutilización, tales como las convenciones de estandarización de interfaces, separación de comandos y opciones, separación de comandos y consultas, etcétera. El buen software debe ser eficiente -oh, lo lamento, esto está relacionado a la implementación, y no hablamos sobre implementación en compañía educada. (Si UML se ocupara de la implementación, debería ocuparse de cuestiones relacionadas con el software; lo bueno de las burbujas y flechas, en oposición a los programas, es que nunca se cuelgan.)

En cambio, los documentos de UML parecen tener un único objetivo: una y otra vez convencer al lector de que no ha omitido ninguna consigna, como en este extracto, página 31 de [2], que intenta explicar que los patrones (patterns) son interesantes pero están cubiertos por el concepto de los autores de “diagrama de interacción“, cualquier cosa que esto sea (no puedo imaginarlo):

El aspecto interesante de muchos patrones es su comportamiento dinámico. Ciertamente podemos mostrar esto con diagramas de interacción, pero sólo en el contexto de un modelo específico. Es difícil mantener la “patronidad” de los patrones abierta. A fin de cuentas, los patrones son plantillas (en algún sentido), en los cuales las clases, asociaciones, atributos y operaciones pueden estar asignadas a distintos nombres, manteniendo la esencia del patrón. Necesitamos una forma de parametrizar claramente los patrones. Sin embargo, creemos que tenemos suficientes formas de capturar patrones en UML expresándolos en términos de interacciones.

Francamente, ¿quién está interesado en esta farsa? ¿Cómo puede alguien creer que tiene algo que ver (en algún sentido) con la industria del software? Y ni siquiera he citado cosas sobre el “metamodelo“. Quizás usted podría pedirle a Amanda que dedique su próximo artículo a la “patronidad“. Hablando de desafíos.

Un amigo que asistió recientemente a una conferencia sobre orientación a objetos me contó sobre las bromas sobre UML que los expertos en OO -algunas de las personas más respetadas en el área- intercambiaron durante los intervalos y en el fondo de las salas. Él no podía creer el contraste entre el bombo público y el menosprecio privado. Pero los CEOs y otros tomadores de decisiones sólo escuchan el bombo publicitario; se les dice que UML es orientado a objetos o, más a menudo, que orientación a objetos significa UML. Cuando no pueda ayudar al desarrollo de software, UML le dará un mal nombre a todo el campo de la OO. Dado los bombardeos de mercadotecnia a su alrededor, UML, al no cumplir con sus promesas, tiene el potencial de retrasar el progreso de la tecnología de objetos por diez años.

¿La respuesta al final?

Así pues, profesor, ¿qué puedo decir, qué puedo decir? Fui con el auxiliar de cátedra y le pregunté si decir “La página principal de Rational tiene lindos colores” ayudaría. Pero me dijo que no, que tendría que encontrar algo más sustancioso. Intenté con “al menos en su última revisión han dejado de llamar a sus cosas “método”, lo que muestra que tienen algún sentido del ridículo“. Tampoco le bastó. Así que busqué y busqué y, finalmente -estoy tan excitado- ¡lo encontré! ¡Sí, UML tiene un propósito después de todo!

La razón por la cual no lo descubrí antes es que sólo aparece en la conclusión. Un lugar extraño para describir sobre qué uno estuvo escribiendo, pero mejor que no hacerlo en ninguna parte. Por supuesto que lo que encontré no es un objetivo técnico (UML, como ya dije, no sirve a ningún propósito relacionado con el software, lo cual está bien para mí -algunas personas tienen mejores cosas que hacer con sus vidas que tratar de mejorar la tecnología del software). No es un objetivo gerencial, al menos no para personas que administren proyectos de software. No es un objetivo de negocios, al menos no para negocios que usen UML. Pero es un objetivo.

Cuando finalmente descubrí el objetivo, casi rompo en llanto por el espíritu generoso y noble de los autores. Sería injusto decir que las parvas de documentación de UML están vacías de toda substancia, cuando de hecho contienen una idea genuina. La encontré en el último párrafo del último reporte que describe la revisión 0.91 [2]. Allí estaba, con toda franqueza, explicando todo lo que había malinterpretado en mi joven inocencia. ¿Cómo podría criticar el método por no ayudar a los desarrolladores de software o gerentes, cuando no se ocupa en absoluto del desarrollo de software, sino sólo de desarrollar un mercado para consultores y capacitadores? Todo comenzó a tener sentido: la complejidad y rareza de la notación, lo que tontamente tomé como una deficiencia, son de hecho unas de sus cualidades más atractivas, dado que crean infinitas oportunidades de negocios, para Rational y quizás también para otros; así como también su tibia adopción de las ideas de la orientación a objetos, lo que significa que un consultor no tiene que conocer ni apreciar la tecnología de objetos para sacar provecho de UML.

Mi larga búsqueda no ha sido en vano. Me ha llevado a una total comprensión de UML, su admirable máquina auto-alimentada, dedicada de la A a la Z a la creación de un nuevo mercado, libre de todas las dificultades asociadas al desagradable negocio del desarrollo de software: ¡Libros de UML! ¡Cursos de UML! ¡Cursos sobre los libros! ¡Libros sobre los cursos! ¡Revisiones! ¡Journals de UML! ¡Conferencias! ¡Workshops! ¡Tutoriales! ¡Estándares! ¡Comités! ¡Remeras! Mientras más se piensa en las posibilidades, más deslumbrante aparece. Y para cualquier lector valiente o lo suficientemente aburrido como para leer la documentación hasta el final, el esquema global está allí, presentado en el párrafo final.

Todo empezaba a encajar. Con el aire de inevitabilidad que revela una auténtica obra maestra, en toda la gloria del estilo inimitable del documento, las últimas seis líneas repentinamente dieron sentido a los centenares de páginas anteriores:

Hay varios cursos públicos, y tenemos conocimiento de que están siendo escritos varios otros libros, que se ocupan de distintos aspectos de UML, todos basados en nuestras publicaciones preliminares previas. Esperamos una amplia difusión de herramientas de soporte, cursos de capacitación y uso de consultores en el futuro. Alentamos fuertemente este tipo de soporte [¡Bien por ustedes al alentar el soporte de sus propios productos! ¡Qué desinteresado!] y trabajaremos conjuntamente con autores, capacitadores y consultores para asegurar que sus consultas sean atendidas, de manera de lograr una difusión y soporte consistentes para UML.

A la espera de una respuesta favorable a mi pedido,

Respetuosamente suyo,

Cándido Smith

Referencias

[1] Rational Software Corporation: 0.8 version of the Unified Method: Notation Summary, en http://www.rational.com.

[2] Rational Software Corporation: 0.91 Addendum to the Unified Modeling Language, en http://www.rational.com.

[3] Kim Waldén and Jean-Marc Nerson: Seamless Object-Oriented Software Architecture: Analysis and Design of Reliable Systems, Prentice Hall, 1995.

Mi conclusión

Más allá de la excelente ironía de Meyer, a modo de resumen me gustaría destacar los siguientes puntos sobre UML:

• Es por demás complejo.
• No es orientado a objetos.
• Carece totalmente de una semántica formal.
• Dificulta extremadamente la reversibilidad.

Para finalizar, una famosa frase de C.A.R. Hoare:

. . . Hay dos maneras de construir un diseño de software: una es hacerlo tan
simple que obviamente no tenga deficiencias, y la otra es hacerlo tan complicado
que no tenga deficiencias obvias.

La programación concurrente (implementada a través de procesos separados o de threads) plantea una serie de inconvenientes respecto del uso de recursos o datos compartidos, que abren un campo de investigación interesantísimo y con muchos puntos aún no resueltos. Presentaremos aquí solamente una introducción a esta problemática, ejemplificando cada situación con nuestro servidor concurrente.

Nota del 19/11/2006: Ahora puede descargar el tutorial completo.

Entregas anteriores

Esta es la última parte de una serie de cuatro artículos.

• Primera parte: Planteo del problema, implementación de un servidor secuencial y de un cliente simple.
• Segunda parte: Implementación de un servidor concurrente mediante procesos y mediante threads.
• Tercera parte: Un cliente en PHP para el acceso a múltiples servidores.

Condiciones de carrera

Supongamos que tenemos un trozo de código como el siguiente:


$x = 10;

sub decrementar {
    if ($x>0) {
        $x--
    }
}


En un entorno de ejecución secuencial, la variable $x nunca tomaría valores negativos, independientemente de cuántas veces sea ejecutada la función decrementar.

La situación cambia sensiblemente si la función decrementar se ejecuta en varios threads distintos y $x es una variable compartida. Supongamos que tenemos dos threads llamados t1 y t2. el valor actual de $x es “1” y se presenta la siguiente situación:

• El thread t1 evalúa la condición del if. Esta resulta verdadera, por lo tanto procederá a la ejecución del cuerpo.
• En ese momento se interrumpe t1 y comienza la ejecución de t2.
• t2 también evalúa la condición del if como verdadera y procede a la ejecución del cuerpo.
• Se interrumpe la ejecución de t2, continuando la de t1.
• t1 decrementa el valor de $x, quedando este en “0“.
• Se interrumpe la ejecución de t1, continuando la de t2.
• t2 decrementa el valor de $x, quedando este en “-1“.

El resultado de esta secuencia de ejecución es que $x queda con el valor “-1“. Como podemos ver, el valor final es dependiente de la forma en que se van ejecutando las sentencias de los distintos threads.

Cuando el resultado de la ejecución concurrente de varios procesos o threads depende de la secuencia que se siga, se dice que existe una “condición de carrera” (“race condition“, en inglés).

La solución, como veremos más adelante, es garantizar la exclusión mutua, impidiendo que un proceso sea interrumpido en medio de un bloque que deba ser considerado “atómico“. En el ejemplo anterior, la sentencia if completa (su condición y su cuerpo) debería ser ejecutada completamente para garantizar la corrección del resultado.

Bloqueo mutuo (deadlock)

Esta es una situación (también llamada “abrazo mortal“) en la cual un conjunto de procesos se encuentran bloqueados (ninguno puede avanzar en su ejecución) debido a que todos esperan recursos que están tomados por otro proceso del conjunto. Este problema es planteado de forma genérica de varias maneras (la variante más conocida es la de los “filósofos comensales” o “cena de los filósofos“).

La siguiente representación gráfica (aunque lejana a la programación) ilustra de forma muy clara este tipo de situaciones:

Supongamos, por ejemplo, que al abrir un archivo para escritura este queda bloqueado, impidiendo a cualquier otro proceso su apertura. Si tenemos dos programas como los siguientes:

Programa p1


open(ARCH1, ">archivo1");
open(ARCH2, ">archivo2");
# Hacer algo con ARCH1 y ARCH2
close(ARCH2);
close(ARCH1);


Programa p2


open(ARCH2, ">archivo2");
open(ARCH1, ">archivo1");
# Hacer algo con ARCH1 y ARCH2
close(ARCH1);
close(ARCH2);


Puede ocurrir que la ejecución de p1 se detenga inmediatamente después de abrir el archivo1 y comience la ejecución de p2. Este último podrá abrir el archivo2, pero al intentar abrir el archivo1, como este está bloqueado por p1, quedará suspendido hasta que este se libera (pero permanecerá bloqueando a archivo1).

La ejecución de p1 no podrá continuar, porque necesita abrir un archivo que está siendo bloqueado por p2, y viceversa).

(Una nota curiosa: aunque parezca muy poco probable la ocurrencia de este tipo de situaciones, suelen darse en la realidad, generalmente ante la incredulidad del desprevenido programador que ve cómo todas las estaciones de trabajo que acceden a su sistema se quedan congeladas hasta que se reinicia una de ellas…)

Aunque en este ejemplo la forma de evitar el bloqueo mutuo es que ambos programas abran los archivos archivo1 y archivo2 en el mismo orden, en general este tipo de situaciones es bastante difícil de evitar. Para ello existen diversas técnicas, tales como el algoritmo del banquero, propuesto por Edsger W. Dijkstra.

Complicando nuestro problema: añadiendo un recurso compartido

Volviendo a nuestro problema original, vamos a añadir un recurso compartido para ver cómo resolvemos el problema de su acceso por parte de los distintos procesos o threads, según el caso.

Añadiremos un archivo en el cuál se irán contando las conexiones atendidas por el servidor. Supondremos que el conteo debe hacerse al finalizar la conexión, por lo cual deberá ser realizado por el proceso o thread encargado del tratamiento de la misma.

Podríamos definir una función llamada registrar como sigue:


sub registrar {
    open (REG, "+<accesos.log");
    $accesos = <REG>;
    $accesos++;
    seek(REG, 0, 0);
    print REG $accesos;
    close REG;
}


Esta función abre el archivo “accesos.log“, lee su contenido (inicialmente debería ser 0) asignándoselo a la variable $accesos. Luego incrementa el valor de esta última, posiciona el archivo al comienzo y escribe en él el nuevo valor.

Si añadiéramos a nuestra función atender invocación a registrar, podría darse el caso de que dos o más procesos (o threads) accedieran al contenido del archivo leyendo el mismo valor. Esto causaría un error en el valor posteriormente escrito (vulgarmente se dice que los procesos lo “pisarían“). Esto es, evidentemente una condición de carrera.

A continuación analizaremos las dos versiones de nuestro servidor concurrente, ejemplificando dos soluciones diferentes para nuestro problema.

Solución en el servidor con fork

La solución más simple aplicable a nuestro servidor concurrente basado en procesos independientes, es la utilización de la función de bloqueo de archivos que nos provee el sistema operativo. A través de ella, podemos lograr que cuando un proceso requiera la apertura del archivo “accesos.log“,lo bloquee impidiendo su apertura por parte de otro proceso (el que será suspendido hasta que el primero lo libere).

De esta forma, el servidor quedaría como puede verse a continuación:

servidor_fork_lock


#!/usr/bin/perl -w

use IO::Socket;
use Fcntl ':flock';
require "procesar_lock.pl";
inic_reg();
require "procesar.pl";
# Ignora la señal de terminación de los hijos
$SIG{CHLD} = 'IGNORE';
$puerto = 2222;
$servidor = IO::Socket::INET->new(Proto    =>'tcp',
                                  LocalPort=>$puerto,
                                  Listen   =>SOMAXCONN,
                                  Reuse    =>1)
            or die "Error al iniciar el servidor";

print "[Aceptando conexiones en puerto $puerto]\n";

while ($conexion = $servidor->accept()) {
    if (fork() == 0) {
        # Proceso hijo
        close $servidor;
        atender($conexion);
        exit;
    } else {
        # Proceso padre
        close $conexion;
    }
}


Descargar el código fuente

procesar_lock.pl


sub inic_reg {
    open (REG, ">accesos.log");
    print REG "0";
    close REG;
}

sub registrar {
    open (REG, "+<accesos.log");
    flock(REG, LOCK_EX);
    $accesos = <REG>;
    $accesos++;
    seek(REG, 0, 0);
    print REG $accesos;
    flock(REG, LOCK_UN);
    close REG;
}

sub ejecutar($$) {
    ($comando, $conexion) = @_;
    $resultado = '';
    if ($comando eq 'fecha') {
        $resultado = localtime() . "\n";
    } elsif ($comando eq 'usuarios') {
        $resultado = `who`;
    }
    if ($resultado) {
        print $conexion "OK\n";
        print $conexion $resultado;
        print $conexion "FIN\n";
    } elsif ($comando eq 'salir') {
        print $conexion "Adios.\n";
    } else {
        print $conexion "ERR\n";
    }
}

sub atender($) {
    $conexion = shift;
    $ip = $conexion->peerhost;
    print "[Conexión establecida desde $ip]\n";
    print $conexion "Bienvenido.\n";
    do {
        if ($comando = <$conexion>) {
            $comando =~ s/\r\n|\n//g;
            ejecutar($comando, $conexion);
        } else {
            $comando = 'salir';
        }
    } until ($comando eq 'salir');
    $conexion->shutdown(2);
    registrar;
    print "[Conexión finalizada desde $ip]\n";
}

1;


Descargar el código fuente

La sentencia “flock(REG, LOCK_EX)” solicita un bloqueo exclusivo (LOCK_EX). De ejecutarse exitosamente, el sistema operativo denegará a cualquier otro proceso un bloqueo sobre este archivo. En caso contrario, el proceso será suspendido hasta que pueda realizarse el bloqueo exitosamente. Por contraparte, la sentencia “flock(REG, LOCK_UN)” libera el bloqueo del archivo (LOCK_UN), permitiendo su obtención por parte de otro proceso.

De esta manera nos aseguramos que, una vez que un proceso ha abierto el archivo y obtiene un bloqueo sobre él, ningún otro pueda leerlo hasta que el primero haya escrito el nuevo valor y lo libere.

Uso de semáforos para la sincronización

Si bien el bloqueo de archivos es una buena solución, hay otros casos (como el de variables compartidas u operaciones complejas) para los que no es aplicable. Una alternativa muy utilizada es el uso de semáforos.

Un semáforo es una variable especial protegida que se utiliza para permitir o denegar el acceso a recursos compartidos. Esta técnica fue inventada por Edsger Dijkstra.

En su forma más simple (semáforo binario) el semáforo puede estar en dos estados: alto o bajo. Incialmente el semáforo se encuentra en estado alto. Un proceso que desee acceder al recurso compartido, debe bajarlo (si ya se encuentra bajo el proceso será suspendido hasta que vuelva a estar alto). Cuando ha terminado de utilizar el recurso compartido, el proceso deberá levantar nuevamente el semáforo.

(Si pensamos en el ejemplo del cruce de 2 calles, la idea resulta evidente.)

Solución en el servidor con threads

Aunque aquí también podríamos utilizar el bloqueo de archivos, vamos a ejemplificar la solución utilizando un semáforo. El código del servidor con threads quedaría como sigue:

servidor_threads_sem


#!/usr/bin/perl -w

use threads;
use Thread::Semaphore;
use IO::Socket;
require "procesar_sem.pl";

$puerto = 2222;
$servidor = IO::Socket::INET->new(Proto    =>'tcp',
                                  LocalPort=>$puerto,
                                  Listen   =>SOMAXCONN,
                                  Reuse    =>1)
            or die "Error al iniciar el servidor";

print "[Aceptando conexiones en puerto $puerto]\n";
inic_reg();
$semaforo = new Thread::Semaphore;

while ($conexion = $servidor->accept()) {
     threads->create(\&atender, $conexion, $semaforo)
}


Descargar el código fuente

procesar_sem.pl


sub inic_reg {
    open (REG, ">accesos.log");
    print REG "0";
    close REG;
}

sub registrar($) {
    $semaforo = shift
    $semaforo->down;
    open (REG, "+<accesos.log");
    flock(REG, LOCK_EX);
    $accesos = <REG>;
    $accesos++;
    seek(REG, 0, 0);
    print REG $accesos;
    flock(REG, LOCK_UN);
    close REG;
    $semaforo->up;
}

sub ejecutar($$) {
    ($comando, $conexion) = @_;
    $resultado = '';
    if ($comando eq 'fecha') {
        $resultado = localtime() . "\n";
    } elsif ($comando eq 'usuarios') {
        $resultado = `who`;
    }
    if ($resultado) {
        print $conexion "OK\n";
        print $conexion $resultado;
        print $conexion "FIN\n";
    } elsif ($comando eq 'salir') {
        print $conexion "Adios.\n";
    } else {
        print $conexion "ERR\n";
    }
}

sub atender($$) {
    ($conexion, $semaforo) = @_;
    $ip = $conexion->peerhost;
    print "[Conexión establecida desde $ip]\n";
    print $conexion "Bienvenido.\n";
    do {
        if ($comando = <$conexion>) {
            $comando =~ s/\r\n|\n//g;
            ejecutar($comando, $conexion);
        } else {
            $comando = 'salir';
        }
    } until ($comando eq 'salir');
    $conexion->shutdown(2);
    registrar($semaforo);
    print "[Conexión finalizada desde $ip]\n";
}

1;


Descargar el código fuente

El módulo de Perl “Thread::Semaphore” nos permite utilizar semáforos. El programa principal inicializa el semáforo “$semaforo“, que luego es pasado como parámetro a la función “atender” en cada uno de los threads disparado por este. Como todos los threads comparten el mismo semáforo, cada vez que uno de ellos proceda a actualizar el contenido del archivo “accesos.log“, impedirá a los otros la ejecución de esta tarea, hasta haberla finalizado.

Concluyendo

En esta última entrega, hemos realizado una breve introducción a algunos de los problemas que se presentan a la hora de construir programas concurrentes o paralelos.

Hemos añadido un recurso compartido a nuestro sistema y explorado dos técnicas que nos permiten sincronizar los procesos o threads para evitar condiciones de carrera.

Nota final del autor

Es mi deseo que esta serie de artículos haya contribuido a iniciar a lector en dos áreas muy útiles e interesantes de la programación como lo son el desarrollo de programas utilizando sockets como mecanismo de comunicación y la construcción de aplicaciones concurrentes.

Todos los comentarios (sobre todo críticas y sugerencias) son más que bienvenidos. Espero, en un futuro no muy lejano, seguir ampliando algunos temas específicos de estas áreas.

Desde ya, mi más sincero agradecimiento por el tiempo dedicado a la lectura de este artículo.

Es por eso que dejaremos por un rato el camino planificado para jugar un poco explorando las posibilidades con un cliente en PHP (en una especie de “recreo“).

Entregas anteriores

• Primera parte: Planteo del problema, implementación de un servidor secuencial y de un cliente simple.
• Segunda parte: Implementación de un servidor concurrente mediante procesos y mediante threads.

Nota del 19/11/2006: Ahora puede descargar el tutorial completo.

Monitoreo remoto de servidores

Si bien el servicio que hemos diseñado en las entregas anteriores (I y II) es muy limitado (después de todo, es sólo un ejemplo para desarrollar los temas), podemos utilizarlo para realizar un pequeño sistema de monitoreo remoto.

Supongamos que tenemos el servidor corriendo en varios servidores físicos distintos. Vamos a construir un programa PHP (para satisfacer los deseos de quienes querían ver algo en este lenguaje) que nos permita conectarnos a cualquiera de los servidores y ver la hora del sistema y los usuarios activos.

Recordemos que esto es sólo un ejemplo simple, por lo cual no tendremos en cuenta la seguridad del sistema. (Además, ¡estamos de recreo!).

El uso de sockets en PHP es un poco más complejo que en Perl, por lo cual nos conviene definir funciones auxiliares para establecer la conexión, leer y escribir:

Los sockets en PHP son genéricos. Por esto debemos indicar que usaremos direccionamiento IP (AF_INET), que realizaremos una comunicación bidireccional (SOCK_STREAM) y que usaremos el protocolo TCP (SOL_TCP). Al leer de un socket debemos indicar cuál es la longitud máxima (asumimos 1024). PHP_NORMAL_READ significa que lo leído deberá interpretarse como texto. Al escribir, debemos proporcionar la longitud de la salida.

El programa se conectará al servidor especificado por el usuario y ejecutará los comandos fecha y usuarios, obteniendo las respuestas correspondientes del servidor. Debemos recordar en todo momento cómo funciona el protocolo que hemos definido (ver la primera entrega). En definitiva, no estamos haciendo más que implementar un nuevo cliente.

Por simplicidad, hemos utilizado un puerto fijo para todos los servidores (el 2222), aunque este podría variar, y la lista de servidores solo incluye al localhost (127.0.0.1).

Si comparamos el código PHP con el del cliente original desarrollado en Perl notaremos que hay grandes similitudes entre ambos.

Finalmente, la parte del script que produce la salida HTML con la lista de servidores que pueden ser monitoreados y los datos obtenidos desde el servidor actual.

(Por comodidad y facilidad de visualización he puesto imágenes con el código PHP, pero si lo desea puede descargar el código fuente completo.)

A continuación, una muestra de cómo se vería la interfaz una vez consultado el servidor corriendo en 127.0.0.1:

Concluyendo

Hemos tomado un pequeño desvío para ver la implementación de un cliente en PHP, acercándonos a un ejemplo un poco más real del posible uso del servicio que hemos diseñado.

Más allá de los detalles propios de cada lenguaje, hemos podido apreciar las grandes similitudes a la hora de implementar un cliente.

En la próxima entrega retomaremos el tratamiento de los problemas relacionados con la ejecución de procesos concurrentes y threads. (¡Fin del recreo!)

Próxima entrega

• Cuarta parte: El uso de recursos compartidos y los problemas
  de la concurrencia.

En esta segunda parte, desarrollaremos un servidor capaz de recibir conexiones de varios clientes de manera concurrente (en paralelo). Para ello utilizaremos dos técnicas distintas: procesos múltiples e hilos de ejecución (threads).

Nota del 19/11/2006: Ahora puede descargar el tutorial completo.

Entrega anterior

• Primera parte: Planteo del problema, implementación de un servidor secuencial y de un cliente simple.

Procesos y concurrencia

Como vimos anteriormente, un proceso es una instancia en ejecución de un programa. Cada proceso es identificado por un valor numérico único asignado por el sistema operativo en el momento de su creación, llamado PID (por “process identifier“). En los sistemas operativos derivados de UNIX, la creación de un nuevo proceso se realiza a través de la llamada al sistema fork.

Cuando un proceso invoca la llamada al sistema fork el sistema operativo crea un nuevo proceso, idéntico al anterior (tanto en su código ejecutable como en el valor de sus datos). Luego, fork devolverá como resultado el valor 0 en el nuevo proceso creado (que comenzará su ejecución en la instrucción inmediata a la invocación de fork) y el valor del PID del nuevo proceso en el proceso invocante.

Veamos un ejemplo muy sencillo:


#!/usr/bin/perl
$pid = fork();
if ($pid == 0) {
    print "Soy el proceso hijo\n";
} else {
    print "Soy el proceso padre\n";
}
print "Fork devolvió: $pid\n";


La salida de la ejecución de este programa sería similar a la siguiente:


Soy el proceso hijo
Fork devolvió: 0
Soy el proceso padre
Fork devolvió: 3839


Como podemos ver, la primera línea ejecuta fork. A partir de allí se crea un nuevo proceso (hijo) idéntico al anterior (padre). Cuando comenza la ejecución del proceso hijo, se asigna a $pid el valor devuelto por fork (0). Al retomarse la ejecución del padre, se asigna a $pid el valor del PID del proceso hijo. (Nótese cómo cada proceso ejecuta la rama correspondiente de la sentencia if y ambos ejecutan el último print.)

En rigor este ejemplo es incorrecto. Al finalizar el proceso hijo, enviará una señal a través del sistema operativo, notificando al padre de este evento para posibilitar que este último pueda examinar su estado final. Por esto el proceso padre debería esperar la finalización del hijo, ya que en caso contrario este último quedaría en un estado llamado “zombie” (se denomina así a un proceso que ha finalizado su ejecución, pero todavía ocupa lugar en la tabla de procesos del sistema operativo). Esto no afecta demasiado en este ejemplo (el proceso padre finaliza enseguida), pero puede impactar seriamente en sistemas de gran envergadura.

Segunda solución: un servidor concurrente

Modificaremos ahora el servidor desarrollado inicialmente (ver el artículo anterior), para que al recibir una conexión cree un nuevo proceso que se encargue de atender los requerimientos del cliente conectado.

Las funciones agrupadas en el archivo procesar.pl (que realizan el tratamiento y la ejecución de los comandos del cliente) no cambian, ya que no hemos alterado el protocolo. El programa principal del servidor sería el siguiente:

servidor_fork


#!/usr/bin/perl -w

use IO::Socket;
require "procesar.pl";
# Ignora la señal de terminación de los hijos
$SIG{CHLD} = 'IGNORE';
$puerto = 2222;
$servidor = IO::Socket::INET->new(Proto    =>'tcp',
                                  LocalPort=>$puerto,
                                  Listen   =>SOMAXCONN,
                                  Reuse    =>1)
            or die "Error al iniciar el servidor";

print "[Aceptando conexiones en puerto $puerto]\n";

while ($conexion = $servidor->accept()) {
    if (fork() == 0) {
        # Proceso hijo
        close $servidor;
        atender($conexion);
        exit;
    } else {
        # Proceso padre
        close $conexion;
    }
}


Descargar el código fuente

La sentencia “$SIG{CHLD} = ‘IGNORE’” permite que el proceso padre ignore las señales de finalización enviadas por los hijos, para no generar procesos “zombies“.

Al recibir una conexión, se invoca a fork. El proceso hijo cierra su copia de $servidor (ya que no permanecerá esperando conexiones), atiende la conexión del cliente (como en la versión anterior, a través de la función atender) y luego finaliza su ejecución. El proceso padre cierra su copia del socket $conexion (la conexión será atendida por el hijo) y vuelve al comienzo del ciclo, esperando nuevas conexiones.

De esta forma, tan pronto es creado el proceso hijo, el servidor vuelve a estar disponible para aceptar y procesar nuevas conexiones.

Una forma de observar el nuevo comportamiento es intentar dos o más conexiones simultaneas usando un cliente telnet, tal como lo hicimos en la primera parte.

Algunas consideraciones sobre la concurrencia

El uso de fork puede resultar muy costoso. La creación de un nuevo proceso, idéntico al anterior, involucra la copia de los segmentos de código y datos de este. Si el proceso a clonar es demasiado grande, esto puede suponer una gran carga para el sistema (en nuestro ejemplo, además, un retraso en la recepción de la próxima conexión).

Una alternativa al uso de fork para lograr la ejecución concurrente es el uso de los llamados “hilos de ejecución” o “threads“. Los threads son secuencias de ejecución de un mismo proceso y, como tales, comparten sus datos (variables, archivos abiertos, sockets, etc.). Esto significa que, por ejemplo, si en un thread se modifica el valor de una variable, los demás threads accederán al valor modificado.

Esta alternativa representa un ahorro considerable de recursos e incrementa sensiblemente la eficiencia en muchos casos, pero puede requerir de grandes cuidados para evitar los problemas del acceso a recursos compartidos. (En la próxima entrega de este artículo entraremos en mayor detalle respecto de esto.)

Por citar un caso real, el servidor web Apache utiliza, en su versión 1.x, un esquema basado en el uso de fork (es decir, para cada nueva conexión, dispara un nuevo proceso). Esto es inaceptable en sistemas de gran escala, por lo cual en la versión 2.x existe la posibilidad de atender cada requerimiento usando threads.

Tercera solución: un servidor concurrente usando threads

Implementaremos ahora una tercera versión de nuestro servidor, esta vez usando threads para lograr el procesamiento concurrente de las conexiones. Nuevamente, el archivo procesar.pl no se verá alterado. A continuación, el código del servidor:

servidor_threads


#!/usr/bin/perl -w

use threads;
use IO::Socket;
require "procesar.pl";

$puerto = 2222;
$servidor = IO::Socket::INET->new(Proto    =>'tcp',
                                  LocalPort=>$puerto,
                                  Listen   =>SOMAXCONN,
                                  Reuse    =>1)
            or die "Error al iniciar el servidor";

print "[Aceptando conexiones en puerto $puerto]\n";

while ($conexion = $servidor->accept()) {
     threads->create(\&atender, $conexion)
}


Descargar el código fuente

Lo primero que podemos apreciar es que esta versión es muy similar al servidor secuencial desarrollado inicialmente. Las diferencias radican en que se ha incluido el módulo threads de Perl y que al recibir una nueva conexión, en vez de ejecutar la función atender se crea un nuevo thread mediante el método threads->create. Este recibe como parámetros una referencia a la función a ejecutar (\&atender) y el parámetro con que se invocará a esta última ($conexion).

La ejecución de la función atender como un nuevo thread continua paralelamente a la ejecución del resto del proceso (que vuelve a esperar una nueva conexión), hasta la finalización de la misma.

Concluyendo

Hemos reimplementado nuestro servidor para aceptar conexiones de forma simultánea usando procesos concurrentes. Haciendo esto, hemos analizado los conceptos principales asociados a la creación y ejecución de procesos mediante la llamada al sistema fork.

Luego hemos reimplementado el servidor concurrente, esta vez usando threads, para obtener un programa más eficiente.

En ningún momento ha sido necesaria la modificación de las funciones desarrolladas para procesar los requerimientos de los clientes, ni el pequeño cliente construido anteriormente, ya que no hemos modificado el protocolo ni añadido nuevas funciones al servidor.

Aunque hemos comenzado a explorar el mundo de la programación concurrente, aún no nos hemos topado con niguno de sus problemas. Esto abre las puertas a la próxima entrega del presente tutorial…

Próximas entregas

• Tercera parte: Un cliente en PHP para el acceso a múltiples servidores.
• Cuarta parte: El uso de recursos compartidos y los problemas
  de la concurrencia.

• Programación cliente/servidor usando sockets: Cómo desarrollar programas que se comuniquen a través de la red para realizar distintas tareas.
• Protocolos de comunicación: Explorar los principios básicos de los protocolos de aplicación (alto nivel) utilizados para intercambiar información.
• Concurrencia: Cómo construir programas que se ejecuten paralelamente y resolver algunos de los problemas que nos plantea la concurrencia.

Nota del 19/11/2006: Ahora puede descargar el tutorial completo.

En los ejemplos utilizaremos el lenguaje Perl, por su simplicidad para este tipo de tareas, pero el objetivo es que estos artículos sean de utilidad aún para quienes no conozcan dicho lenguaje. Por esto no nos limitaremos a exponer ejemplos, sino que desarrollaremos cada concepto independientemente del lenguaje de programación.

El problema

Implementaremos un servidor que reciba conexiones de clientes a través de la red y permita ejecutar comandos para realizar distintas tareas.

Por simplicidad, definiremos solamente los siguientes comandos:

• fecha: Muestra la fecha y hora actual del servidor.
• usuarios: Muestra los usuarios activos del sistema (asumiremos que el servidor se ejecuta en un sistema compatible con UNIX y que posee el comando who).

El protocolo

Como primera medida, deberemos diseñar el protocolo que seguirán el cliente y el servidor para comunicarse e interactuar. Un protocolo puede verse como una secuencia de pasos y convenciones, de acuerdo a las cuales se llevará a cabo la comunicación.

En este caso, estamos diseñando un protocolo de aplicación (de alto nivel, distinto a los protocolos de enlace o transporte de información), que permita que ambas aplicaciones (el cliente y el servidor) intercambien información, ejecuten comandos, etc. En esta situación, siempre es recomendable que el protocolo sea lo más cercano a la comunicación humana: usando mensajes de texto y sin codificaciones extrañas.

La comunicación se llevará a cabo de la siguiente manera (cada envío, del servidor o del cliente, finalizará con un salto de línea):

1. Al recibir la conexión del cliente, el servidor enviará el mensaje “Bienvenido.“.
2. El cliente enviará el comando deseado (“fecha” o “usuarios“).
3. En caso de tratarse de un comando válido, el servidor responderá con “OK” seguido del resultado de la ejecución del mismo (el cual puede constar de varias líneas) y luego el mensaje “FIN“.
4. En caso de recibir un comando erróneo, el servidor responderá con el mensaje “ERR“.
5. En cualquier caso, el servidor volverá a esperar otro comando.
6. Si el cliente envía el comando “salir” el servidor responderá con el mensaje de despedida “Adios.” y cerrará la conexión.
7. La conexión puede ser cerrada por el cliente en cualquier momento, sin que esto afecte el estado del servidor.

Algunos conceptos preliminares

Se llama proceso a una instancia en ejecución de un programa. El concepto de programa es estático: se refiere al archivo ejecutable, en tanto que el de proceso es dinámico. De esta forma, puede haber varias instancias en ejecución (procesos) del mismo programa.

Un socket es un mecanismo utilizado para comunicar dos procesos a través de la red, usando algún protocolo de transporte. Para la comunicación entre el servidor y el cliente, utilizaremos el protocolo TCP, por ser el más adecuado para este tipo de sistema (a diferencia de UDP, es orientado a conexiones).

La comunicación a través de sockets con TCP se realiza de la siguiente forma:

• El proceso servidor abre un socket asociado a determinado puerto TCP.
• El servidor permanece “escuchando” en dicho puerto, a la espera de la apertura de una conexión.
• Un cliente abre un socket conectándose al servidor haciendo referencia a su dirección IP y al número de puerto.
• Una vez establecida la conexión entre ambos procesos, ya no existe más diferencia entre cliente y servidor.
• El socket puede ser visto, por ambos procesos, como un archivo de lectura/escritura abierto.
• Ambos procesos intercambian información de acuerdo al protocolo de aplicación establecido.
• Para finalizar la conexión, cualquiera de los dos procesos cierra el socket.

Primera solución: un servidor secuencial

Nuestra primera solución al problema será a través de un servidor secuencial. El programa servidor abrirá un socket en un puerto TCP determinado y quedará a la espera de conexiones entrantes. Al recibir una conexión, interactuará con el cliente según el protocolo que hemos definido, hasta la desconexión de este último. Una vez finalizada la conexión, volverá al estado de espera hasta recibir una nueva solicitud.

Si el servidor se encuentra interactuando con un cliente y un segundo cliente intenta realizar otra conexión, esta será demorada hasta finalizada la actual. En casi cualquier situación real esto sería inaceptable, pero momentaneamente vamos a asumir esta limitación. (En la segunda parte de este artículo implementaremos un servidor que pueda recibir varias conexiones concurrentes.)

servidor_secuencial


#!/usr/bin/perl -w

use IO::Socket;
require "procesar.pl";

$puerto = 2222;
$servidor = IO::Socket::INET->new(Proto    =>'tcp',
                                  LocalPort=>$puerto,
                                  Listen   =>SOMAXCONN,
                                  Reuse    =>1)
            or die "Error al iniciar el servidor";

print "[Aceptando conexiones en puerto $puerto]\n";

while ($conexion = $servidor->accept()) {
    atender($conexion);
}


Descargar el código fuente

El programa utiliza el módulo (biblioteca) IO::Socket que provee una implementación de sockets para el lenguaje Perl.

La variable $servidor es un socket TCP abierto en el puerto indicado por $puerto (en este ejemplo, 2222). En los sistemas UNIX para utilizar puertos menores a 1025 se requiere permisos de root. La constante SOMAXCONN representa la máxima cantidad de conexiones aún no atendidas que puede “encolar” el sistema operativo.

El cuerpo del ciclo principal se ejecuta cada vez que se recibe una conexión. Esto se logra mediante la ejecución de $servidor->accept(). La función atender está definida en el script procesar.pl, que podemos ver a continuación.

procesar.pl


sub ejecutar($$) {
    ($comando, $conexion) = @_;
    $resultado = '';
    if ($comando eq 'fecha') {
        $resultado = localtime() . "\n";
    } elsif ($comando eq 'usuarios') {
        $resultado = `who`;
    }
    if ($resultado) {
        print $conexion "OK\n";
        print $conexion $resultado;
        print $conexion "FIN\n";
    } elsif ($comando eq 'salir') {
        print $conexion "Adios.\n";
    } else {
        print $conexion "ERR\n";
    }
}

sub atender($) {
    $conexion = shift;
    $ip = $conexion->peerhost;
    print "[Conexión establecida desde $ip]\n";
    print $conexion "Bienvenido.\n";
    do {
        if ($comando = <$conexion>) {
            $comando =~ s/\r\n|\n//g;
            ejecutar($comando, $conexion);
        } else {
            $comando = 'salir';
        }
    } until ($comando eq 'salir');
    $conexion->shutdown(2);
    print "[Conexión finalizada desde $ip]\n";
}

1;


Descargar el código fuente

La función atender toma como parámetro la conexión recibida. Muestra la dirección IP del cliente conectado, envía a este el mensaje de bienvenida e inicia un ciclo que finaliza al recibir el comando “salir” o al cerrarse la conexión. (Nótese que aunque según el protocolo diseñado el cliente debe enviar el comando “salir” antes de finalizar la conexión, debemos tener en cuenta que esta puede cerrarse subrepticiamente.)

La sentencia “$comando = <$conexion>” lee una línea desde el socket de la conexión y la asigna a la variable $comando, devolviendo verdadero si la lectura fue exitosa y falso si ocurrió algún error (por ejemplo, en caso de haberse cerrado la conexión).

La sentencia “$comando =~ s/\r\n|\n//g” utiliza una expresión regular para eliminar el fin de línea al final de la cadena leída (este puede constar del caracter “\n” o de los caracteres “\r\n“).

Una vez obtenido el comando a ejecutar, se llama a la función ejecutar que implementa los comandos que hemos definido para nuestro servicio. Si desearamos añadir nuevas funciones a nuestro servidor, bastaría con extender esta función para implementarlas.

Finalmente, la sentencia “$conexion->shutdown(2)” cierra el socket, finalizando la conexión del lado del servidor.

Una aclaración importante: Cuando utilizamos la función print seguida de una cadena, esta es enviada a la salida estándar (normalmente, la consola desde donde ejecutamos el programa), en tanto que si anteponemos a la cadena el socket (la variable “$conexion“, en nuestro caso), la cadena es enviada (escrita) a través de él.

Probando nuestro servidor

Si ejecutamos el servidor (para lo cual previamente deberemos darle permisos de ejecución, por ejemplo “755“), veremos el siguiente texto en la consola:

[Aceptando conexiones en puerto 2222]

La forma más simple de conectarnos al servidor para ejecutar algunos comandos es utilizando un cliente de telnet (si bien no usaremos el servicio telnet, un cliente de este tipo sirve para realizar conexiones tcp a cualquier puerto). En una nueva consola ejecutamos:

telnet localhost 2222

En la consola del servidor veremos el mensaje:

[Conexión establecida desde 127.0.0.1]

En tanto que en la consola donde ejecutamos el cliente telnet veremos lo siguiente:

Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Bienvenido.

Las primeras líneas son producidas por el cliente telnet, en tanto que el mensaje “Bienvenido.” es el enviado por el servidor al iniciarse la conexión. Podemos probar la ejecución de comandos, por ejemplo (el texto resaltado en itálica es el ingresado por nosotros):

fecha
OK
Mon Nov 6 05:04:02 2006
FIN
usuarios
OK
javier   tty1        2006-11-05 15:55
javier   pts/0       2006-11-05 16:00 (:0.0)
javier   pts/1       2006-11-05 16:41 (:0.0)
FIN
noexiste
ERR
salir
Adios.
Connection closed by foreign host.


Observamos que todo se desarrolla de acuerdo al protocolo de aplicación que hemos diseñado (inclusive la respuesta de error ante un comando inexistente). Si en medio de la sesión intentamos el acceso con otro cliente de telnet, veremos que el servidor no responde hasta que se haya finalizado la conexión actual, tal como lo habíamos previsto.

Un cliente simple para nuestro protocolo

Desarrollaremos ahora un cliente que implemente el protocolo definido y que haga uso del servidor.


#!/usr/bin/perl

use IO::Socket;

if (! defined $ARGV[2]) {
    print STDERR "Uso: cliente <servidor> <puerto> <comando>\n";
    exit 1;
}

($servidor, $puerto, $comando) = @ARGV;

$conexion = new IO::Socket::INET(PeerAddr => $servidor,
                                 PeerPort => $puerto,
                                 Proto => 'tcp')
            or die "Error al conectar con $servidor";

$mensaje = <$conexion>;
print $conexion "$comando\n";
$estado = <$conexion>;
if ($estado eq "OK\n") {
    $salida = <$conexion>;
    while ($salida ne "FIN\n") {
        print $salida;
        $salida = <$conexion>;
    }
} elsif ($estado eq "ERR\n") {
    print "Comando no válido\n";
} else {
    print "Error en el servidor\n";
}
print $conexion "salir\n";
$mensaje = <$conexion>;
$conexion->shutdown(2);


Descargar el código fuente

Nuestro cliente toma como parámetros la dirección IP del servidor, el puerto a utilizar y el comando a ejecutar. Primero controla que se le hayan proporcionado los parámetros correctos y luego abre un socket TCP (como cliente) hacia la IP y el puerto especificados.

De aquí en más, el cliente debe seguir la especificación del protocolo. De otra manera no podrá sincronizarse con el servidor para llevar adelante la secuencia de pasos apropiada. Por ejemplo, antes de enviar el comando a ejecutar, deberá recibir el mensaje de bienvenida (aunque luego no haga nada con él). De la misma forma, luego de enviar el comando, deberá leer el estado que informa el servidor (“OK” o “ERR“), para saber si luego deberá leer la salida de su ejecución.

Si el comando produjo el mensaje “OK“, luego seguirá el resultado del mismo, hasta la recepción del texto “FIN“. En cualquier caso, el cliente deberá cerrar la conexión enviando el comando “salir” y recibiendo el mensaje de despedida (aunque, como ya hemos visto al implementar el servidor, el no cumplimiento de esto no debería significar ningún inconveniente).

A continuación, un ejemplo de la ejecución del cliente con el comando “usuarios“:

javier@obelix:~$ ./cliente localhost 2222 usuarios
javier   tty1      2006-11-05 15:55
javier   pts/0     2006-11-05 16:00 (:0.0)
javier   pts/1     2006-11-05 16:41 (:0.0)
javier@obelix:~$

Concluyendo

Hasta aquí hemos avanzado sobre los conceptos básicos de la programación de aplicaciones cliente/servidor usando sockets usando el protocolo TCP.

Hemos diseñado un pequeño protocolo de aplicación que se ajusta a los requerimientos de nuestro problema, y construido un servidor secuencial y un cliente muy simples que lo implementan.

Una lección adicional que debemos rescatar: el servidor debe implementar el protocolo a seguir, previendo que el cliente puede no respetarlo (en nuestro caso, por ejemplo, este último podría cerrar la conexión en cualquier momento). A la hora de construir un cliente, debemos apegarnos al protocolo tanto como nos sea posible.

En el próximo artículo de esta serie, implementaremos un servidor capaz de atender a varios clientes de forma simultanea. Con esto nos introduciremos en el mundo de las aplicaciones concurrentes o paralelas.

Próximas entregas

• Segunda parte: Implementación de un servidor concurrente mediante procesos y mediante threads.
• Tercera parte: Un cliente en PHP para el acceso a múltiples servidores.
• Cuarta parte: El uso de recursos compartidos y los problemas
  de la concurrencia.