Ahora que sabemos qué tiene que hacer cada componente y cómo comunicarse, una buena idea sería hacer una lista de todos los mensajes que se enviarán y especificar cómo se verán. Comencemos primero con la comunicación entre el cliente y el servidor de eventos.
El cliente puede enviar {subscribe, Self} al servidor de eventos, que solo puede responder con "ok". Tenga en cuenta que tanto el cliente como el servidor se monitorean entre sí. Aquí elegí usar dos monitores porque no hay una dependencia obvia entre el cliente y el servidor. Es decir, por supuesto, el cliente no funciona sin el servidor, pero el servidor puede vivir sin un cliente. Un enlace podría haber hecho el trabajo aquí, pero como queremos que nuestro sistema sea extensible con muchos clientes, no podemos asumir que todos los demás clientes querrán bloquearse cuando el servidor muera. Y tampoco podemos asumir que el cliente realmente se puede convertir en un proceso del sistema y que se produzcan salidas de trampa en caso de que el servidor muera. Ahora, el siguiente conjunto de mensajes.
El cliente puede enviar el mensaje {add, Name, Description, TimeOut}, al que el servidor puede responder 'ok' o {error, Reason}
Esto agrega un evento al servidor de eventos. Se envía una confirmación en forma de átomo ok, a menos que algo salga mal (tal vez el TimeOut esté en el formato incorrecto). La operación inversa, eliminar eventos, se puede realizar de la siguiente manera.
El cliente puede enviar el mensaje {cancel, Name} y el servidor de eventos debería devolver ok como un átomo
El servidor de eventos puede enviar una notificación cuando se deba realizar el evento.
El servidor de eventos reenvía un mensaje {done, Name, Description} al cliente
Luego, solo necesitamos los dos casos especiales siguientes para cuando queremos apagar el servidor o cuando falla.
Cuando el cliente envía el átomo 'shutdown' al servidor de eventos, este se apaga y devuelve {'DOWN', Ref, process, Pid, shutoff} porque fue monitoreado
No se envía una confirmación directa cuando el servidor se apaga porque el monitor ya nos advertirá de eso. Eso es prácticamente todo lo que sucederá entre el cliente y el servidor de eventos. Ahora, los mensajes entre el servidor de eventos y los procesos de eventos en sí.
Una cosa a tener en cuenta aquí antes de empezar es que sería muy útil tener el servidor de eventos vinculado a los eventos. La razón de esto es que queremos que todos los eventos mueran si el servidor lo hace: no tienen sentido sin él.
Bien, volvamos a los eventos. Cuando el servidor de eventos los inicia, le da a cada uno de ellos un identificador especial (el nombre del evento). Una vez que llega el momento de uno de estos eventos, necesita enviar un mensaje que lo indique:
Un evento puede enviar {done, Id} al servidor de eventos
Por otro lado, el evento tiene que estar atento a las llamadas de cancelación del servidor de eventos.
El servidor envía 'cancel' a un evento, que responde con 'ok'
Y eso debería ser todo. Se necesitará un último mensaje para nuestro protocolo, el que nos permite actualizar el servidor.
el servidor de eventos tiene que aceptar un mensaje 'code_change' del shell
No es necesaria ninguna respuesta. Veremos por qué cuando realmente programemos esa función y verás que tiene sentido.
Una vez definido el protocolo y con la idea general de cómo se verá nuestra jerarquía de procesos, podemos empezar a trabajar en el proyecto.
