Anda di halaman 1dari 6

5.

Pila de protocolos
Este captulo detalla como desarrollar protocolos en JavaGroups y est destinado a programadores que quieran escribir sus propios protocolos o modificar los existentes. Para ello, se describe la arquitectura de la pila de protocolos de JChannel (creacin, disposicin y flujo de eventos) y se explican los diversos protocolos que pueden incluirse. El atractivo de una pila construida apilando capas de protocolos es que son independientes unas de otras, por lo tanto, pueden fcilmente ser reemplazadas o actualizadas por otras versiones. Normalmente suelen contener poco cdigo, enfocndose slo haca una funcionalidad concreta que las hace fciles de entender. Si un protocolo se vuelve demasiado complejo, incorporando multiples funcionalidades, puede ser descompuesto en un nmero ms pequeo de protocolos simples. Las capas de protocolos pueden ser aadidas sin modificacin del resto de cdigo de JavaGroups. Notar, sin embargo, que el cdigo asociado a los protocolos ser incluido y ejecutado con el resto de cdigo de JavaGroups en la mquina virtual de Java (JVM, Java Virtual Machine), por lo tanto, puede afectar al comportamiento final de JChannel. As, las excepciones producidas en la pila de protocolos de JChannel, causadas por un mal funcionamiento del protocolo, son tratadas en el nivel de JChannel, y puede, por tanto, causar estragos en el funcionamiento del canal. El mal funcionamiento de los protocolos pueden afectar a los mensajes (aadiendo cabeceras errneas, modificando los contenidos de los mensajes u omitiendo los mensajes), por lo tanto, la fiabilidad de una pila de protocolos es la suma de la robustez y fiabilidad de todas sus capas. Como cada protocolo tiene el mismo interfaz y es completamente independiente de cualquier otro protocolo, puede ser apilado junto a todos los dems protocolos. Sin embargo, esto podra no ser viable en muchos casos ya que es necesario respetar un cierto orden: aunque el orden para apilar los protocolos sea sintcticamente independiente, no lo es semnticamente. Por ejemplo, el protocolo GMS requiere que el protocolo PING (o alguno con su misma funcionalidad) est presente en alguna capa inferior de manera que pueda averiguarse la membresa inicial del canal. Concretando ms: el protocolo GMS, en algn momento, enviar hacia abajo de la pila el eventoFIND_INITIAL_MBRS (ver seccin 7.6) para ser manipulado por cualquier otro protocolo que lo

reconozca. Este protocolo realizar la tarea de encontrar la membresa inicial y pasar un evento FIND_INITIAL_MBRS_OK hacia arriba en la pila, contenindola. La capa GMS esperar por la respuesta y, de ser nula, crear un grupo con un nico miembro. Por lo tanto, aunque GMS no dependa sintcticamente de PING (no llama a ningn mtodo de PING), tiene dependencia semntica con alguna capa inferior que le responda al evento FIND_INITIAL_MBRS. Este tipo de dependencia es menos vinculante que una llamada a un mtodo ya que puede utilizarse cualquier capa capacitada para responder a la peticin de la membresa inicial y, adems, GMS no conoce de que capa se trata.

5.1 La pila de protocolos de


5.1.1 Eventos (Event) y mensajes (Message)

JChannel

La diferencia entre los eventos y los mensajes es que los eventos son usados para comunicacin dentro de la pila (intra-stack) mientras que los mensajes son usados para comunicacin entre pilas (inter-stack). De este modo, en la pila de protocolos de JChannel, slo los eventos son pasados entre capas mientras que los mensajes son intercambiados entre pilas, es decir, puestos en la red y recibidos desde la red por la capa ms baja de las entidades pares implicadas. Los eventos son usados para pasar informacin relevante entre las capas de la misma pila. Los mensajes son incorporados en eventos por la capa ms baja y pasados hacia arriba de la pila. Cuando JChannel.receive() es llamado por una aplicacin, si el contenido del evento depositado en la cola del canal es un mensaje, es extraido desde el evento y devuelto. Cuando un mensaje viaja hacia abajo en la pila (incorporado en un evento), la capa ms baja lo extraer y lo pondr en la red. Un evento est formado por un entero (int) que indica el tipo y por un argumento (Object) utilizado para incorporar la informacin. Por ejemplo, los eventos que incorporan mensajes tienen el tipo Event.MSG y como argumento el mensaje (Message). El tipo de un evento puede conocerse llamando al mtodo Event.getType(). Los tipos de eventos usados en JavaGroups se encuentran en org.javagroups.Event. Sin embargo, en muchos casos, los desarrolladores de nuevas capas de protocolo pueden encontrar provechoso aadir nuevos tipos de eventos.

Hay dos posibilidades: cada nuevo evento es aadido en org.javagroups.Event (modificando el cdigo original) o usando un evento especfico para tal fin (USER_DEFINED). La primera solucin seguramente dar lugar a numerosas distribuciones incompatibles: los distintos desarrolladores deben elegir los mismos tipos de eventos, evitando la ambigedad en la distribucin original. La ltima opcin permite a los desarrolladores usar sus propios tipos de evento con slo incluirlos en el tipo USER_DEFINED sin que se vea afectado el resto del cdigo original. Los tipos de evento implementados estn listados en la tabla 5.1.

Tabla 5.1: Eventos


Tipo de evento START START_OK STOP STOP_OK MSG CONNECT CONNECT_OK Argumento Descripcin Message String Activa la pila de protocolos. Generada por la capa ms baja en respuesta a START. Viaja hacia arriba de la pila. Detiene el trabajo de la pila. Generada por la capa ms baja en respuesta a STOP. Viaja hacia arriba de la pila. Mensaje viajando hacia arriba o abajo de la pila. Conexin al canal de nombre especificado. Comienza GMS. Evento JOIN en respuesta. Respuesta generada por la capa GMS al finalizar el protocolo JOIN. Viaja hacia arriba de la pila. Desconexin del canal especificado. GMS comienza el protocolo LEAVE y enva hacia arriba LEAVE_OK cuando finalize. Generado por la capa GMS y enviado hacia arriba de la pila. Generado por GMS y enviado hacia arriba/abajo de la pila ante la llegada de una nueva vista. Retorna la direccin local. La respuesta es generada por la capa ms baja. Generada por la capa ms baja en respuesta a GET_LOCAL_ADDRESS o al arrancar la pila (despus de enviar START hacia arriba de la pila). No se usa todava. No se usa todava.

DISCONNECT

Address

DISCONNECT_OK VIEW_CHANGE GET_LOCAL_ADDRESS

View -

SET_LOCAL_ADDRESS FLUSH FLUSH_OK

addr -

SUSPECT

Address

Generada por la capa de deteccin de fallos (por ejemplo, FD). Enviado hacia arriba de la pila y manipulado por la capa GMS. El argumento es el miembro sospechoso. Determina la membresa inicial. Generado por la capa GMS y enviado hacia abajo de la pila. Manipulado por la capa PING que genera la respuesta y la enva hacia arriba de la pila.

FIND_INITIAL_MEMBERS

FIND_INITIAL_MEMBERS_OK

Vector

Respuesta a FIND_INITIAL_MEMBERS. Generada por PING. Enviada hacia arriba de la pila. Generada por la capa MERGE cuando se detecta otro miembro con el mismo nombre de grupo pero no incluido en la vista local. Enviada hacia arriba de la pila. Manipulada por la capa GMS. Instala una vista provisional. Usada por la capa GMS, entre otras, para que UDP enve hacia abajo de la pila un mensaje con la correcta membresa. En muchos casos le seguir un evento VIEW_CHANGE. Enviado hacia arriba/abajo de la pila por la capa GMS cuando un miembro se ha sido unido con xito al grupo.

MERGE

Vector

TMP_VIEW

View

BECOME_SERVER

Aunque los eventos y los mensajes son realmente diferentes, el trmino ``mensaje'' es usado indistintamente con el de ``evento'' en las secciones siguientes, donde el flujo de eventos/mensajes es ms importante que la diferencia entre ellos.

5.1.2 Arquitectura
La arquitectura de la pila de protocolos se muestra en la figura 5.1.

Figura 5.1: Arquitectura de la pila de protocolos

Todo canal org.javagroups.JChannel va asociado a un bloque org.javagroups.stack.ProtocolStack que dirige la pila de protocolos y usa el configurador org.javagroups.stack.Configurator (ver seccin 5.1.4) para crear y configurar una pila de protocolos. ProtocolStack funciona esencialmente como un adaptador entre la capa de protocolo ms alta y el canal JChannel. En el momento que elProtocolStack recibe un mensaje desde el canal (capa inmediatamente superior), es pasado a la capa de protocolo ms alta de la pila. Del mismo modo, cuando recibe un mensaje desde la capa ms alta de la pila, es pasado al canal. Cuando se crea un canal JChannel; al mismo tiempo, se genera una instancia de ProtocolStack encargada de dirigir la pila en su lugar. Cuando una aplicacin se conecta al canal, se activa la pila de protocolos y, cuando se desconecta, se desactiva. Cuando el canal se cierra, la pila se destruye, liberando sus recursos. Para realizar esta operacin, el ProtocolStack se ayuda del Configurator. Las capas de protocolo son apiladas y conectadas de forma directa a travs de las colas FIFO bidireccionales. Cada protocolo tiene dos colas: una para almacenar los mensajes entrantes (viajando hacia arriba en la pila) y otra para mensajes salientes (viajando hacia abajo). Cada cola es

atendida por un hilo de ejecucin (thread) independiente cuya funcin es coger los mensajes almacenados en la cola (si no hay ninguno, se bloquear hasta que uno sea aadido) y pasarlos hacia arriba o abajo de la siguiente capa invocando Up o Down, respectivamente. Entonces, la siguiente capa implicada lo almacenar en su cola entrante o saliente, segn el caso. Si un mensaje viajando hacia abajo es recibido por la capa ms baja, ser puesto en la red. Si el mensaje viajando hacia arriba es recibido por la capa ms alta, ser pasado al ProtocolStack que lo enva alJChannel. El JChannel almacena todos los mensajes recibidos por la pila de protocolos en una cola, donde pueden ser recuperados (y, por tanto, eliminados) por cualquier aplicacin llamando a JChannel.receive() directamente o usando un PullPushAdapter, indirectamente (ver seccin 4.1). De idntica forma, los mensajes enviados por elJChannel son pasados a la pila de protocolos para viajar hacia abajo por todas las capas hasta alcanzar la red.