• "Cliente/Servidor": Puede resultar confuso el empleo de los términos "cliente" y "servidor" en las prácticas debido a que es el cliente quien envía datos al servidor. Ha de entenderse este envío como la petición de información que hace el cliente, que debería ir seguida por la respuesta del servidor con la información. Por simplificar las prácticas no se ha incluido la parte de respuesta del servidor, aunque se puede desarrollar fácilmente (de hecho hace falta para los ejercicios de clientes y servidores propuestos al final de las prácticas)
• Headers: Se han dejado 2 ficheros con declaraciones: tiposcomm.h y commarq.h. El primero contiene la declaración de todos los nuevos tipos de datos a los que se hace referencia en el guión, así como los valores para los tipos de mensajes que se han tomado en los programas ejemplo entregados. El segundo contiene las declaraciones necesarias para emplear la librería libcommarq.a.
• MSG_DATA... : Para que la comunicación de mensajes con el programa ejemplo nucleog tenga éxito los valores de tipo de mensajes a emplear DEBEN ser los especificados en tiposcomm.h, además el tamaño del mensaje debe ser exactamente el requerido.
• Tests: Un par de semanas antes de la fecha de entrega de prácticas se sugerirán en esta página una serie de pruebas/tests que deben pasar los programas realizados, los cuales serán similares a los que se emplearán para corregir las prácticas
• Creación de colas de mensajes: Tal y como está el programa nucleog él crea la cola de mensajes correspondiente a su entidad. Si encuentra que esa cola ya existe da un error y termina la ejecución. Por ello el programa muxin desarrollado en la segunda práctica no debe crear una cola sino acceder a la ya existente. Si aún no existe dicha cola porque nucleog no ha tenido tiempo para crearla la solución más simple es hacer que muxin espere un tiempo (1 seg) y reintente el msgget.
• Destrucción de las colas de mensajes: Los programas nucleo y muxin están pensados para estar ejecutándose indefinidamente, por lo que no es necesaria la destrucción de las colas de mensajes que han creado cuando éstos terminan. Sin embargo, durante el proceso de desarrollo, en el cual se detendrán y rearrancarán numerosas veces puede ser útil una función de atención a la señal SIGINT que destruya (msgctl con IPC_RMID) las colas. Por favor, comprueben que no dejan colas de mensajes creadas antes de abandonar el puesto de trabajo y pongan atención a los permisos con los que las crean dado que si ni el propietario tiene permiso no podrán verlas con el comando ipcs (aunque por ser su propietario sí podrían borrarlas).
• Entrega de prácticas: Como se especifica en el guión, en cada directorio de prácticas basta con dejar las fuentes necesarias para compilar el objetivo de esa práctica. No hace falta dejar versiones de lanzador, nucleo y muxin en cada uno para que se pueda echar a correr el sistema. Tengan en cuenta que probablemente las pruebas de los programas se realizarán en conjunción con otras versiones de los demás ejecutables.
• Ejecutables empleados por lanzador: Se sugiere emplear la ruta absoluta a los ejecutable que se encuentran en el directorio /opt3/arq/ficheros
• El programa nucleog de ejemplo devuelve un mensaje de tipo MSG_ERROR si el punto de acceso solicitado ya se encuentra en uso, en vez de devolver un mensaje de tipo MSG_FIN tal y como se especifica en el guión. Ambas opciones se considerarán válidas aunque se recomienda seguir el guión (por coherencia).
• Al usuario final, para construir aplicaciones empleando este sistema de comunicación, se le proporcionan los ficheros libcomm.h y libcommarq.a. No se debe hacer ninguna modificación a libcomm.h.

• Práctica 1:
  1. Comprobar que funciona la comunicación entre cualquier pareja de entidades y en cualquier sentido. Para ello se coloca un servidor (servidor_test1) en una entidad y se le mandan paquetes desde clientes (cliente_test1) trabajando sobre todas las demás entidades. Así hasta cubrir todas las posibilidades.
• Páctica 2:
  1. Con lanzadorg, nucleog y vuestro programa muxin (para que funcione con lanzadorg basta con que se llame muxing y se encuentre en el mismo directorio que lanzadorg) repetir las pruebas de la Práctica 1 pero al menos dos veces cada pareja origen-destino (para comprobar que el muxin no funciona solo para un paquete).
• Práctica 3:
  1. Con lanzadorg, muxing y vuestro programa nucleo (para que funcione con lanzadorg basta con que se llame nucleog y se encuentre en el mismo directorio que lanzadorg). Repetir las pruebas de la Práctica 1.
  2. Se recuerda que mientras sea posible el programa nucleo debe crear nuevas zonas de memoria compartida y semáforos y tener cuidado de no estar reutilizando unos tal vez creados por otro usuario (tengan en cuenta que las claves y todas las IPCs de System V - colas, memorias y semáforos - son GLOBALES al sistema). Si escogen una clave para la nueva zona de memoria compartida deben comprobar que no exista ya otra creada con esa misma clave (ver man de shmget y flag IPC_EXCL), lo mismo para los semáforos. En caso de haber escogido una clave en uso se cambia por otra y se vuelve a intentar, así hasta encontrar una libre.
  3. Emplear servidor_test2 y enviarle datos varias veces con cliente_test2 para comprobar que la zona de memoria compartida se emplea circularmente de forma correcta.
  4. El programa nucleog debe permitir un gran número de puntos de acceso en uso a la vez. Estos deben poder reutilizarse una vez que se liberan y además deberían reducirse al mínimo los requisitos de memoria del programa nucleo (al menos que no vaya perdiendo memoria por cada punto de acceso que se libera)
  5. Colocar varios servidores sobre la misma entidad para comprobar que se pueden tener reservados varios puntos de acceso simultaneamente y que los datos van al destino que deben.
  6. Modificar las fuentes de servidor_test2 para que la primera vez antes de llamar a la función recibe se quede en una espera larga (por ejemplo con una llamada sleep(60)). A continuación enviarle varios paquetes desde clientes (cliente_test2 por ejemplo) hasta conseguir desbordar la zona de memoria compartida. En ese momento el nucleo debería estar tirando paquetes por no encontrar huecos libres. Al salir el servidor del sleep debería empezar a hacer las llamadas recibe() del bucle e ir sacando los datos de los primeros 10 paquetes (siendo 10 el tamaño de la memoria compartida en paquetes), los siguientes se deberían haber perdido y a continuación debería podérsele mandar más paquetes con normalidad y él sacaría su contenido correctamente.
  7. Modificar muxin para que haga una pausa de varios segundos cada vez que lea un paquete. Enviar paquetes mediante cualquiera de los clientes a un servidor a una velocidad mayor que la de procesado de muxin (controlada por la pausa introducida). Si los descriptores de escritura de nucleo están correctamente configurados como no bloqueantes llegará un momento que se sature la pipe entre nucleo y muxin y los siguientes paquetes se perderán. Comprobar que efectivamente se producen estas pérdidas y que nucleo no se bloquea al encontrar una pipe saturada. Se puede aprovechar para calcular cuál es el número máximo de paquetes (bytes) que puede haber en la pipe esperando ser leídos.
• Práctica 4:
  1. Con lanzadorg, muxing y nucleog poner en funcionamiento las entidades. Recompilar los programas cliente_test1, cliente_test2, servidor_test1 y servidor_test2. Repetir con estos programas las pruebas de la Práctica 1.
  2. El mismo comentario respecto a las claves en la Práctica 3 es aplicable aquí para la clave de la cola de mensajes por la que se recibe la respuesta a un MSG_ACCEPT.

Se van a colocar los programas nucleo y muxin en varios ordenadores interconectados por la Ethernet. De esta forma se podrán realizar comunicaciones entre procesos ejecutándose en máquinas diferentes.

La topología dispuesta será la siguiente:

Los números representan el identificador de la entidad y a su vez el número de puesto (XY = tlmXY). Las líneas indican los enlaces y las flechas salientes de los bloques indican cuál es la ruta por defecto de salida de cada máquina. Finalmente la clave empleada en todas las máquinas es 22374.

Sobre esta disposición pueden ejecutarse sin problemas todos los programas que empleen la librería libcommarq.a. Los programas nucleo y muxin están guardando los mensajes que habitualmente ofrecen por la salida estándar en ficheros localizados en /opt3/arq/ficheros/version_net/logs . Estos ficheros tienen el mismo nombre que el número de la máquina sobre la que se ejecuta la entidad.

Las versiones de nucleo y muxin disponibles en el directorio /opt3/arq/ficheros/version_net/ difieren de nucleog y muxing tan solo en que redirigen automáticamente su salida estándar sin buffer a ficheros con nombre según el identificador de la entidad que se les ha indicado.

El programa lanzadornet que se encuentra en /opt3/arq/ficheros/version_net/ permite lanzar entidades conectándolas mediante conexiones TCP (materia de otras asignaturas). Si se desea probarlo ofrece una breve ayuda al ejecutarlo sin argumentos (tengan en cuenta que los puertos < 1024 se encuentran reservados y por lo tanto solo el usuario root puede emplearlos). Los programas nucleo y muxin que ejecuta son los primeros que encuentre en el PATH, en caso de no encontrar ninguno emplea los que se encuentran en /opt3/arq/ficheros/version_net/.

Si el programa lanzadornet da un error del tipo Error creando el socket sobre el puerto X prueben con un valor distinto de clave.

Se propone encontrar qué parejas de máquinas no pueden comunicarse entre si en alguno o ambos sentidos. A qué se debe? Qué problemas presenta este sistema de comunicación que impide alcanzar algunos destinos anque exista camino físico? Un paquete que vaya de tlm26 a tlm34 cuántos saltos tiene que dar? Se podría reducir esta cantidad sin alterar el "cableado físico".

Una vez completadas todas las etapas del desarrollo: nueva funcionalidad del sistema y librería de nivel de usuario, podeis obervar el sistema como haría un desarrollador de aplicaciones que no necesita conocer nada sobre cómo funciona el enlace físico de comunicación (Coaxial), el protocolo de nivel de enlace (Ethernet), o el resto de protocolos de los enlaces entre máquinas (en este caso conexiones TCP sobre IP). La abstracción proporcionada por la librería debe permitir desarrollar de una forma sencilla y funcional aplicaciones que se comuniquen entre ellas, localizadas posiblemente en máquinas diferentes de la red. En qué medida se ha logrado el objetivo?

Nota: Esta topología en red estará disponible a partir del lunes 23/4/2001 y por tiempo limitado. Si se reinicia una máquina tengo que volver a lanzar el servicio a mano así que antes de reportarme errores comprueben si están corriendo los programas nucleo y muxin.