Todas las operaciones de red en Graphly se ocultan detrás de una capa de gestión y comunicación deworkers(para abreviar, la capa de Comunicación) que proporciona el envío de datos deworker a worker, el descubrimiento y la gestión de los trabajadores, y un mecanismo de llamada a procedimiento remoto (RPC). Esta capa también es responsable de convertir objetos desde y hacia bytes (un proceso conocido comomarshalling) y la carga de clases remotas (en caso de que la clase de un objeto enviado por un usuario no se encuentra en elworker).
Networking
La implementación de esta capa se asemeja a una pila de módulos basados en la abstracción del procesador de mensajes (Message Processoro MP). Cada MP recibe un mensaje, lo procesa y lo envía al siguiente MP. En cada MP, los mensajes se añaden a una cola1 y se planifica su procesamiento.
1Para reducir el impacto de la cola en el procesamiento, los mensajes se agregan y se obtienen en lotes.
Este enfoque es similar al implementado por el Disruptor Ring Queue (Página Web del Disruptor https: //lmax-exchange.github.io/disruptor/), una cola sincronizada de alta performance usada en escenarios productor-consumidor.
En Graphly se proveen, por defecto, dos pilas de comunicación, una de ellas basada en el protocolo UDP y otra en TCP. Ambas se muestran en la Figura 4.2. Dichas pilas están dis- eñadas para ser utilizadas en diferentes escenarios. Por ejemplo, TCP es un protocolo basado en canales de comunicación, utilizado cuando se debe establecer una comunicación confiable entre dos procesos. Por otro lado, UDP está orientado al envío de paquetes no provee ninguna garantía de que, luego de enviar un conjunto de bytes, éstos lleguen a destino. UDP tiene la ventaja de consumir muchos menos recursos de red que TCP debido que no se debe mantener una conexión entre los nodos. De ser necesario, se pueden incluir un conjunto de MPs encima de UDP para poder brindar características similares a TCP, tal como fragmentación de mensajes largos, confirmaciones de recepción y agrupamiento de mensajes pequeños.
Toda la comunicación se realiza a través de un MP especial llamadoDataSender, que ayuda a enviar una serie de bytes a un worker determinado y, opcionalmente esperar una respuesta, independientemente del protocolo de comunicación subyacente.
Además de las abstracciones de red, la capa de comunicación proporciona un protocolo de descubrimiento deworkers. Este módulo fue implementado en dos versiones: utilizando multi- difusión y utilizandopings. La variante de multidifusión envía mensajes de multidifusión UDP a una dirección de multidifusión dada y espera respuestas de otrosworkers. El descubrimiento basadopingssimplemente envía mensajes UDP a un rango de direcciones definido por el usuario y espera las respuestas.
Un protocolo de detección de fallos se utiliza para realizar un seguimiento de la situación de losworkersdescubiertos. La implementación por defecto de este MP consiste en un protocolo basado en mensajes que envía un ping (es decir, un latido) periódicamente y espera las respuestas.
Abstracción del Cluster
La comunicación directa, es decir, enviar bytes a una dirección IP y un número de puerto, es incó- modo y muy propenso a errores. Como alternativa, la capa de comunicación ofrece una abstrac- ción Worker y otra de Cluster. La clase Worker permite al usuario enviar datos a otrosworkers que se identifican con una dirección lógica almacenada en un objeto Address, en lugar de un par
(ip,puerto). El Cluster agrupa objetos Worker, denotados como{Worker0,Worker1, . . . ,Workern},
como se muestra en la Figura 4.3, y administra la notificaciones de descubrimiento de loswork- ers(cuando losworkersnotifican su disponibilidad) y las fallas de losworkers. Se puede notar en la Figura que tanto el cliente como losworkersposeen una vista del cluster (el objeto Cluster, que aparece expandido en el nodo del cliente). Adicionalmente, se puede observar que más de unworkerpuede ser desplegado en un solo nodo.
Client Node
Cluster Node Cluster Node
Worker Worker Worker
Graphly Client Cluster
Cluster Cluster Cluster
Cluster Node Worker Cluster 0 0 0 1 2 1 2 3 1 2 3
Worker Worker Worker Worker
Figure 4.3: Un ejemplo de las abstracciones de clúster y workers desplegados en nodos.
ChatFactory ChatServer ChatBroadcast RPC Builder "Chat.java" (Java class or interface) RPC rpc = graphly.getRPC();
ChatServer server = new ChatServerImpl();
rpc.registerTarget(¨CHAT¨, server); RPC rpc = graphly.getRPC();
ChatFactory factory = ChatFactory.create(rpc,"CHAT"); Chat chat = factory.buildClient(¨worker_0¨);
chat.sendChatMessage(user,¨Hello, World¨); Server side
Client side
Figure 4.4: Flujo de trabajo para la creación de RPCs en Graphly.
Llamadas de Procedimiento Remoto
En los programas distribuidos, la posibilidad de llamar a métodos de objetos que existen en los workersremotos simplifica enormemente el diseño y la mantenibilidad. Graphly proporciona un framework de llamada a procedimiento remoto (RPC) para realizar fácilmente llamadas remotas a objetos. En la base de este framework se establece la clase RPC, que se encarga de registrar los objetos que son alcanzables mediante RPCs y llevar a cabo las invocaciones remotas. El proceso es sencillo: el trabajador puede utilizar su instancia RPC para llamar a cualquier método de un objeto remoto identificado por un identificador. En la práctica, el identificador es por lo general una constante predefinida por el usuario. Por ejemplo, en el desarrollo de una aplicación de chat, todas las instancias de la clase Chat pueden registrarse ellos mismos utilizando el iden- tificador "CHAT". El framework provee un conjunto de clases de ayuda que permite ocultar las invocaciones remotas y hacerlas parecer como si fuesen invocaciones locales. Estas clases de ayuda generan 3 clases: una fábrica, un cliente y una clase de difusión como se muestra en la Figura 4.4. La clase fábrica crea objetos del tipo cliente y difusión para un objeto y unworker dado. La clase cliente realiza las invocaciones a unworkeren particular, mientras que la clase de difusión realiza invocaciones a un conjunto deworkers.
getProperty(1000,¨username¨) Store Client 1000%4=2 0 2 3 1 worker worker worker worker 0 1 0 1
Worker
Vertices Properties Adjacency (1000,¨username¨) ¨acorbellini¨ 1000 [0,124,254,...] [300, 257, 354,...] IN OUT [...,1000,...] ... ... 0 Assigned Buckets: 0,2 Local StoreGraph Store
# of Virtual Buckets Virtual Bucketsvertex ID property name
Figure 4.5: Componentes que intervienen en una operación getProperty de ejemplo en el al- macén de grafos de Graphly.