Creo que no va a ser necesario que comente las dos prácticas desarrolladas a lo largo del curso. Para el que no las conozca, le recomiendo que lea atentamente las páginas indicadas:
Ahora vamos a dar un pasito más: la comunicación entre servidor de contactos (proceso SC) y proceso "peer" (proceso P) se produce mediante sockets UDP; además, se añade una función más al servicio de contactos, la notificación. (consejo: lea todos los requisitos hasta el final)
La comunicación entre el SC y el proceso P, que se describía en la "Tercera práctica" se realizaba mediante sockets TCP. El problema de la conexión TCP es la falta de fluidez de la comunicación. Cuando un proceso P necesitaba conectarse con el SC, el SC ofrece un servidor para atenderle, pero cuando el SC se conecta con el proceso P, éste también necesitaba un servidor.
La cuestión se simplifica, en parte, si operamos con sockets UDP, puesto que no es necesario mantener una conexión, para enviar un par de primitivas y volverla a establecer más adelante para otro par de primitivas. El único inconveniente que tenemos por parte de SC y P es que deben estar a disposición de que les envíen mensajes que habrán de atender en función de quién se los envíe, y en el orden adecuado (sin perder el hilo de cada conversación, si es que hay varias).
Una forma de ver el problema es imaginarse que un proceso es capaz de mantener correspondencia con varios procesos a la vez, para lo cual tendrá que mantener los mensajes en hilos separados de conversación :-)
En si misma, la conexión por datagramas es muy simple, y requiere menos preparación que la conexión basada en streams, y además, es más agil, para mensajes cortos como los que tenemos en el protocolo entre el SC y P.
Para el resto de la comunicación P a P', podemos seguir manteniendo una comunicación basada en streams, como la que se describe en la práctica 2.
¿Recuerdan el epílogo de la práctica 3? Si no es así, habrá que leerlo de nuevo. ....
Uno de los puntos pendientes, indicaba lo siguiente:
Ahora se trata de dar cumplimiento a este punto.
Primitiva QDIR (1)
QDIR:función:IDPrivado_P_SC
Pide una lista de nombres de los procesos P que están actualmente activos en la comunidad, y que son capaces de dar servicio a función.
Como es lógico, esta función responderá con una lista de nombres de procesos que cumplen con este cometido.
RIDQ:(nombre1, nombre2, ...):IDPrivado_P_SC
Proporciona una lista de nombres (nombre1, nombre2, ...) de la comunidad, que saben realizar dicha función.
E_RIDQ:0
No eres un proceso P registrado en el sistema o la clave no es válida, por lo que no puedo responder a tu petición.
E_RIDQ:#:MensajeDeError:IDPrivado_P_SC
Donde # es un valor entero distinto de 0 que significa: (no se me ocurre nada ahora)
RERIDQ:función:(nombre1, nombre2, ...):IDPrivado_P_SC
Esta primitiva es un poco diferente, pues parte del SC hacia un proceso P que ha manifestado interés en cierta función en algún momento. Se supone que en cierto instante le respondió con RIDQ con una lista vacía, pero que en este momento, sí hay procesos que pueden servir esta función. Esta primitiva pertenece al tipo de mensajes de "notificación:
La idea es que un proceso se subscribe a cierto tipo de información (en este caso saber qué procesos sirven cierta función) y en algún momento el servidor de la subscripción, le notifica con la información pertinente. El cliente puede seguir haciendo otras cosas mientras.
Con la primitiva QDIR el proceso P queda subscrito a cierta información cuando no está disponible en este momento. Si en algún momento aparece esta información, el SC se lo notifica. A partir de ahí, no vuelve a comunicarle ninguna modificación más.
En principio estas son las primitivas propuestas. Agradezco sinceramente que detecteis algún error apreciable y me lo comuniqueis para poder corregir las especificaciones.
El resto de la práctica es equivalente a la práctica 3. (FASE 2)
Entre otras sugerencias interesantes que se me ocurren estaría: