Improving Third Sector Finances

Al´em dos mecanismos de IPC convencionais citados na sec¸˜ao 2.5.1, com a cont´ınua busca por mais eficiˆencia e flexibilidade e a constante evoluc¸˜ao de arquiteturas de sistemas, cada vez mais orientadas `a explorac¸˜ao do processamento paralelo e programac¸˜ao baseada em servic¸os, uma mir´ıade de dificuldades que antes n˜ao existiam precisam ser tratadas, como tolerˆancia `a falhas, disponibilidade e escalabilidade. Nesse contexto surgem novos mecanismos para atender tais necessidades e h´a uma tendˆencia clara, na ´ultima d´ecada, de criac¸˜ao de mecanismos de IPC baseados em filas e passagem de mensagens, o que suporta a hip´otese de que a abstrac¸˜ao de mensagens pode realmente facilitar o desenvolvimento de aplicac¸˜oes paralelas. Nesta sec¸˜ao ser˜ao abordados brevemente alguns dos mecanismos mais recentes nessa ´area de IPC.

ZeroMQ

ZeroMQ ´e uma biblioteca de passagem de mensagens ass´ıncrona de alta performance, de- senvolvida em C++, provinda do expertise adquirido pelos desenvolvedores em aplicac¸˜oes do mercado financeiro. Conta com uma grande comunidade de desenvolvimento e suporte pago para soluc¸˜oes corporativas. Trata-se de um framework de concorrˆencia que suporta conex˜oes

3.2 Conceitos Emergentes 54

diretas e fan-out sobre uma diversidade de protocolos de transporte.

Conhecida pelo termo ”sockets on steroids”, a biblioteca ZeroMQ oferece uma API que lembra os Berkeley (BSD) sockets, por´em se comportam como uma esp´ecie de generalizac¸˜ao entre os TCP sockets e os UNIX domain sockets. Implementa padr˜oes de programac¸˜ao PAIR, Request/Reply, Publish/Subscribe e Push/Pull via canais TCP, intra-processo e inter-processos, garantindo o recebimento de mensagens completas e ordenadas (o que explica a ausˆencia de suporte para UDP) (HINTJENS, 2013).

Consegue superar o throughput de uma conex˜ao em TCP sockets por utilizar um mecanismo de batching inteligente, minimizando a passagem de mensagens pela pilha de rede e desabili- tando o algoritmo de Nagle (respons´avel por minimizar a quantidade de pacotes enviados pela rede, controlando casos de congestionamento). Emprega tamb´em um padr˜ao denominado ”Sui- cidal Snail”, que forc¸a o encerramento de processos clientes muito lentos - a ideia desse padr˜ao consiste em ”falhar mais r´apido”, abrindo espac¸o para resoluc¸˜oes r´apidas do que potencialmente permitir que os processos operem de maneira inadequada ou com baixo desempenho.

ZeroMQ permite alcanc¸ar comunicac¸˜ao confi´avel, r´apida e escal´avel, tanto em ambientes distribu´ıdos como em ambientes de computac¸˜ao paralela, facilitando as comunicac¸˜oes intrapro- cessuais e interprocessuais utilizando os mesmos padr˜oes de programac¸˜ao. Tamb´em garante escalabilidade em ambientes multi-core sem grandes alterac¸˜oes no c´odigo-fonte, trabalhando como um middleware tradicional orientado `a mensagens (TREAT, 2014a).

nanomsg

A biblioteca de sockets nanomsg objetiva tornar a camada de rede r´apida, escal´avel e f´acil de usar. ´E implementada em C e trabalha com uma ampla variedade de sistemas operacionais sem muitas dependˆencias externas (SUSTRIK, 2015).

Ao inv´es de atuar como uma biblioteca de comunicac¸˜ao gen´erica, provˆe blocos semi- prontos para construc¸˜ao de sistemas distribu´ıdos escal´aveis e com bom desempenho, imple- mentando o que denomina-se protocolos de escalabilidade. Os protocolos de escalabilidade s˜ao padr˜oes de programac¸˜ao, abstrac¸˜oes sobre a camada de transporte da rede individualmente definidas, implementando um algoritmo distribu´ıdo espec´ıfico.

Atualmente define seis protocolos de escalabilidade diferentes:

• PAIR (Comunicac¸˜ao bidirecional): Implementa comunicac¸˜ao bidirecional um-para-um entre dois processos. Processos podem enviar e receber mensagens entre si atrav´es dessa

3.2 Conceitos Emergentes 55

conex˜ao exclusiva.

• REQREP (Request/Reply): Define o padr˜ao comumente conhecido como Cliente/Servi- dor, criando servic¸os stateless para processar requisic¸˜oes.

• PIPELINE (One-Way Dataflow): Provˆe fluxo unidirecional entre processos, ´util para implementac¸˜ao de pipelines de processamento balanceados. Um processo produtor sub- mete trabalho para um processo consumidor.

• BUS (Comunicac¸˜ao de Muitos-para-muitos): Permite o envio de mensagens de um pro- cesso para todos os outros processos na rede de conex˜oes.

• PUBSUB (Transmiss˜ao baseada em T´opicos): Permite que processos publisher envie mensagens em modo multicast categorizadas por t´opicos para zero ou mais processos subscribers. Os processos subscriber podem declarar interesse em um ou mais t´opicos, permitindo receber somente as mensagens relevantes para seus objetivos.

• SURVEY (Requisic¸˜ao para Grupo): Similar ao padr˜ao PUBSUB, onde um processo pode enviar uma mensagem para um grupo inteiro, por´em, diferente do PUBSUB, todos os processos respondem `a mensagem, o que permite avaliar o estado de um grande n´umero de sistemas de maneira f´acil e r´apida.

V´arias melhorias e correc¸˜oes foram propostas pela nanomsg quando comparada com a su- pracitada ZeroMQ. ´E totalmente POSIX-compliant, o que oferece uma interface mais limpa e compat´ıvel, e ´e thread-safe, permitindo sua utilizac¸˜ao em ambientes multithread de maneira segura e transparente ao programador. Oferece ainda um mecanismo real de transmiss˜ao zero- copy, o que melhora consideravelmente o desempenho permitindo que mem´oria seja copiada de m´aquina para m´aquina evitando a passagem pela CPU.

A grande quantidade de recursos e melhorias providas torna a biblioteca nanomsg promis- sora. Contudo, por ser um ferramental muito recente (ainda se encontra em vers˜ao Beta), n˜ao possui maturidade como a ZeroMQ e n˜ao ´e uma ferramenta adotada em ambientes de produc¸˜ao. Encontra-se em desenvolvimento ativo e pode oferecer em um futuro pr´oximo um conjunto de soluc¸˜oes robusto e eficiente (TREAT, 2014b).

LINX

LINX ´e um protocolo aberto de IPC, desenvolvido pela ENEA Software AB para ser inde- pendente de plataformas, permitindo que aplicac¸˜oes se comuniquem transparentemente em um

3.2 Conceitos Emergentes 56

mesmo hospedeiro ou em diferentes hospedeiros, no caso de sistemas distribu´ıdos, por exem- plo. LINX ´e baseado no conceito de passagem de mensagens e opera em conjunto com sistemas de tempo real propriet´arios.

Consiste em uma s´erie de m´odulos do kernel do Linux, uma biblioteca para dar suporte `a aplicac¸˜oes e algumas utilidades de linha de comando para monitoramento, gerenciamento e estat´ısticas (ENEA, 2009).

A transparˆencia ´e essencial para sistemas distribu´ıdos, pois permite que processos em m´aquinas diferentes ou aplicac¸˜oes distintas em m´ultiplos sistemas operacionais se comuniquem de maneira indistinta como se fossem executadas em um mesmo processador e em um mesmo sistema operacional. LINX permite que processos se localizem e se comuniquem de maneira transparente, sem fazer distinc¸˜ao se um processo ´e executado na mesma m´aquina, ou em uma m´aquina remota, ou mesmo via internet.

Um elemento chave na implementac¸˜ao do protocolo ´e o uso de um modelo de mapeamento de enderec¸os ´unicos, no qual os n´os comunicantes guardam somente os enderec¸os necess´arios para conex˜oes locais, e como resultado necessitam de recursos m´ınimos de mem´oria para c´odigo e armazenamento de dados, permitindo reconfigurac¸˜oes r´apidas e f´aceis. Esse conceito permite que o LINX escale para grandes redes com complexas topologias de clusters, incluindo tamb´em n´os minimalistas como DSPs e microcontroladores.

A comunicac¸˜ao ´e feita atrav´es de sinais, enviados para os peers conectados `a rede. Como a camada de transporte do LINX n˜ao oferece seguranc¸a, o tr´afego pode ser observado por qualquer processo conectado.

LINX pode ser visto como uma camada entre os clientes e uma interconex˜ao de dados para comunicac¸˜ao, como Ethernet, mem´oria compartilhada ou mesmo um protocolo de transmiss˜ao de pacotes como TCP ou UDP, provendo transporte de mensagens entre clientes. Um cliente, no contexto do protocolo LINX ´e denominado ”Comunicador”.

A arquitetura do protocolo LINX pode ser analogamente comparada com as camadas de Sess˜ao, Transporte e Enlace do modelo OSI, como visto na Figura 3.1. Contudo, qualquer pro- tocolo de transporte que se desejar utilizar dever´a ser anexado ao conjunto do protocolo LINX, portanto, LINX n˜ao substitui nenhum mecanismo, mas agrega funcionalidades ao mesmo (CH- RISTOFFERSON, 2006).

3.2 Conceitos Emergentes 57

Figura 3.1: Arquitetura do Procolo LINX (CHRISTOFFERSON, 2006)