4 C o m u n i c a ~ a o

Comunicas;ao entre processos esta no coras;ao de

todo sistema distribuido. Nao tern senti do estudar siste-
mas distribuidos semexaminar cuidadosamente os modos
pelos quais processos emmaquinas diferentes pocfemtro-
car informas;6es. A comunicas;ao emsistemas distribuidos
e sempre baseada em troca de mensagens de baixo nivel
como a oferecida pela rede subjacente. Expressar comu-
nicas;ao por meio de troca de mensagens e mais diffcil do
que usar primitivas baseadas emmemoria compartilhada,
como a disponivel para plataformas nao distribuidas.
Sistemas distribuidos modernos frequentemente con-
sistem em milhares ou ate milh6es de processos espalha-
dos por uma rede cuja comunicas;ao nao econfiavel, como
a Internet. A menos que os recursos de comunicas;ao ofe-
recidos pelas redes de computadores sejam substituidos
por alguma outra coisa, 0desenvolvimento de aplicas;6es
distribuidas emgrande escala eextremamente diffcil.
Neste capitulo, comes;aremos discutindo as regras as
quais os processos comunicantes tern de obedecer, conhe-
cidas como protocolos, enos concentraremos naestrutura-
s;aodesses protocolos na forma de camadas. Em seguida,
estudaremos tres modelos de comunicas;ao de ampla utili-
zas;ao: chamada de procedimento remoto (Remote
Procedure Call - RPC), middleware orientado a mensa-
gem (Message-Oriented Middleware - MOM) efluxo de
dados. Tambem discutiremos 0problema geral do envio
de dados avarios receptores, denominado multicasting.
Nosso primeiro modelo para comunicas;ao em siste-
mas distribuidos e a chamada de procedimento remoto
(RPC). Vma RPC visa aocultar grande parte das comple-
xidades da troca de mensagens e e ideal para aplicas;6es
cliente-servidor.
Em muitas aplicas;6es distribuidas, a comunicas;ao
nao segue 0padrao bastante restrito da interas;ao clien-
te-servidor. Nesses casos, verificamos que emais adequa-
do pensar emtermos de mensagens. Contudo, em muitos
aspectos, os recursos de comunicas;ao de baixo nivel das
redes de computadores nao sao adequados devido a falta
de transparencia de distribuis;ao. Vma alternativa e usar
urn modelo de alto nivel de enfileiramento de mensagens
no qual a comunicas;ao ocorra praticamente do mesmo
modo que em sistemas de correio eletronico. Middleware
orientado amensagem (MOM) eurn assunto importante 0
suficiente para justificar uma ses;ao so para ele.
Com 0advento de sistemas multimidia distribuidos,
ficou evidente que muitos sistemas careciam de suporte
para comunicas;ao demidia continua, como audio evideo.
oque faltava era anos;ao deurn fluxo que pudesse supor-
tar a sequencia continua de mensagens, sujeito a varias
restris;6es de temporizas;ao. Fluxos serao discutidos em
uma ses;ao separada.
Por fim, como agora entendemos melhor 0estabeleci-
mento de recursos multicast, surgiram novas e elegantes
solus;6es para disseminas;ao de dados. Daremos particular
atens;ao aesse assunto na ultima ses;aodeste capitulo.
Antes de iniciar nossa discussao sobre comunicas;ao
emsistemas distribuidos, primeiro faremos uma recapitu-
las;ao de algumas quest6es fundamentais relacionadas
com comunicas;ao. Na ses;ao seguinte, faremos uma breve
discussao sobre protocolos de comunicas;ao emrede por-
que eles formam abase para qualquer sistema distribuido.
Depois disso, adotaremos uma abordagem diferente por
meio da classificas;ao de diferentes tipos de comunicas;ao
que ocorrem em sistemas distribuidos.
Devido it ausencia de memoria compartilhada, toda
comunicas;ao em sistemas distribuidos e baseada no envio
e recebimento de mensagens (de baixo mYel). Quando 0
processo A quer se comunicar com 0processo B, em pri-
meiro lugar ele monta uma mensagem em seu proprio es-
pas;ode enderes;o. Depois, executa uma chamada de siste-
ma que faz com que 0sistema operacional envie amensa-
gempela rede ateB. Embora essa ideia basica pares;abem
simples, para evitar 0caos, A eB tern de concordar com 0
significado dos bits que sao enviados. SeA enviar urnnovo
elinda romance escrito emfrances ecodificado segundo 0
codigo decaracteres EBCDIC da IBM eB estiver esperan-
do 0estoque deurn supermercado escrito emingles ecodi-
ficado emASCII, acomunicas;ao nao sera otima.
Varios acordos diferentes sao necessarios. Quantos
volts devem ser usados para sinalizar urn bit 0, e quan-
tos volts para sinalizar urn bit I? Como 0receptor sabe
qual e 0ultimo bit da mensagem? Como ele pode detec-
tar se uma mensagem foi danificada ou perdida e 0que
deve fazer sedescobrir que isso aconteceu? Qual e0com-
primento dos numeros, cadeias e outros itens de dados, e
como eles sao representados? Em resumo, sao necessa-
rios acordos emuma variedade de nfveis que vao de deta-
lhes de baixo nivel de transmissao de bits a detalhes de
alto nfvel sobre como a informa<;ao deve ser expressa.
Para ficar mais facillidar comos varios niveis eques-
toes envolvidos em comunica<;ao, a International
Organization for Standardization (ISO) desenvolveu urn
modelo de referencia que identifica claramente os vmos
nfveis envolvidos, da-Ihes nomes padrQnizados e indica
qual nfvel deve fazer tal servi<;o.Esse modelo edenomina-
do modelo de referenda para interconexao de sistemas
abertos (Open Systems Interconnection Reference
Model) (Day eZimmerman, 1983), usualmente abreviado
para ISO OSI ou, as vezes, apenas para modelo OSI.
Devemos salientar que os protocolos que foram desenvol-
vidos como parte do modelo OSI nuncaforam amplamen-
te utilizados e, hoje em dia, estao definitivamente mortos
eenterrados. Contudo, 0modelo subjacente emsi mostrou
ser bastante util para entender redes de computadores.
Embora nossa inten<;ao nao seja dar uma descri<;ao com-
pIeta desse modelo e de todas as suas implica<;oes aqui,
uma curta introdu<;ao sera uti!. Para mais detalhes, veja
Tanenbaum (2003).
omodelo OSI e projetado para permitir que siste-
mas abertos se comuniquem. Urn sistema aberto e 0que
esta preparado para secomunicar com qualquer outro sis-
tema aberto usando regras padronizadas que regem0for-
mato, 0conteudo e 0significado das mensagens recebi-
das. Essas regras estao formalizadas no que denominamos
protocolos. Se urn grupo de computadores quiser se
comunicar por uma rede, todos eles tern de concordar
com os protocolos que serao utilizados. E feita uma dis-
tin<;aoentre dois tipos gerais de protocolos.
Com protocolos orientados a conexao, antes de tro-
car dados, 0remetente e 0receptor primeiro estabelecem
explicitamente uma conexao epossivelmente negociam 0
protocolo que usarao. Apos concluirem, devem liberar a
conexao. 0telefone e urn sistema de comunica<;ao orien-
tado a conexao. Quando 0protocolo e sem conexao, nao
epreciso estabelecer nada antecipadamente. 0remetente
apenas transmite a primeira mensagem quando estiver
pronta. Urn exemplo de comunica<;ao sem conexao e
colocar uma carta emuma caixa de correio. Em computa-
dores, ambos os tipos de comunica<;ao - orientada a
conexao e sem conexao - sao comuns.
No modelo OSI, acomunica<;ao edividida ematesete
nfveis ou camadas, como mostra aFigura 4 .1. Cada cama-
da lida com urn aspecto especffico da comunica<;ao. Desse
modo, 0problema pode ser dividido empor<;oesgerencia-
veis, e cada uma delas pode ser resolvida independente-
mente das outras. Cada camada fomece uma interface para
acamada que esta acima dela. A interface consiste emurn
conjunto deopera<;oesque, juntas, definem 0servi<;oque a
camada esta preparada para oferecer aseus usumos.
Quando 0processo A na maquina 1quer secomunicar
com 0processo B na maquina 2, ele constroi uma mensa-
gemepassa essa mensagem para acamada deaplica<;aoem
sua propria maquina. Essa camada poderia ser urn procedi-
mento debiblioteca, por exemplo, mas tambem poderia ser
implementada de algum outro modo (por exemplo, dentro
do sistema operacional, emurnprocessador derede exteruo
etc.). Em seguida, 0software de camada de aplica<;aoadi-
ciona urn cabe(,;alho afrente da mensagem e passa a men-
sagem resultante para a camada de apresenta<;ao por meio
da interface entre as camadas 6 e7. Por sua vez, acamada
de apresenta<;ao adiciona seu proprio cabe<;alho e passa 0
resultado para acamada de sessao, e assimpor diante.
Algumas camadas nao se limitam a adicionar urn
cabe<;alho a frente da mensagem; adicionam tambem urn
er ao final. Quando a mensagem chega ao nfvel mais
o. acamada ffsica transmite amensagem (cujo aspec-
e sa altura, poderia estar parecido com 0que mostra
:?:gura 4 .2) colocando-a no meio ffsico de transmissao.
Quando amensagem chega amaquina 2, ela epassa-
=- . ara cima e cada camada retira e examina seu proprio
.- ,<llho. Por fim, amensagem chega ao receptor, 0pro-
_--- B, que pode responde-l ausando 0carninho inverso.
ormac;ao contida no cabec;alho da camada n e usada
o protocolo da camada n.
Para exemplificar por que protocol os em camadas
importantes, considere a comunicac;ao entre duas
resas, Zippy Airlines e sua fornecedora de refeic;oes
- bordo, Mushy Meals, Inc. Todo mes, achefe do servi-
_ ce bordo da Zippy pede a sua secretaria que entre em
tata com a secretaria da gerente de vendas da Mushy
olocar urn pedido de cern mil caixas de frango. Por
.,ao, os pedidos erarn enviados pelo correio. Contudo,
o 0servic;opostal piorou, acerta altura as duas secre-
decidiram abandona-Io e se comunicar por e-mail.
- podiam fazer isso sern incomodar a chefia, uma vez
":.20protocolo que usam trata da transmissao ffsica de
_ didos, e nao de seu conteudo.
De maneira semelhante, a chefe do servic;o de bordo
::- e decidir abandonar 0frango e experimentar 0novo
o especial de costela de bode da Mushy, semque essa
. ao afete as secretarias. aque se deve notar e que
=mo duas camadas aqui, as chefes e as secretarias. Cada
~ada tern seu proprio protocolo - sujeito a discussao
= :ondic;oes de tecnologia -, que pode ser alterado inde-
dentemente do outro. E exatamente essa independen-
que torna atraentes os protocolos em camadas. Cada
pode ser alterado a medida que a tecnologia avanc;a,
:~rn que os outros sejarn afetados.
o modelo oSI nao ha duas camadas, mas sete,
:orno vimos naFigura 4 .1. aconjunto de protocol os utili-
~ 0emdeterminado sistema edenominado suite de pro-
los ou pilha de protoeolos. E importante distinguir
modelo de referencia de seus protocolos propriamente
. os. Como mencionarnos, os protocolos oSI nunca
=mammuito populares. Ao contrario, os protocolos desen-
;olvidos para aInternet, como TCP eIP, sao os mais usa-
dos. Nas sec;oes seguintes, examinaremos brevemente
cada uma das camadas oSI por vez, comec;ando pela que
esta mais embaixo. Entretanto, emvez de dar exemplos de
protocolos oSI, onde for adequado, destacaremos alguns
dos protocolos da Internet usados emcada camada.
Cornec;aremos discutindo as tres camadas mais bai-
xas da pilha de protocolos oS1. J untas, essas camadas
implementam as func;oes basicas que abrangern uma rede
de computadores.
A camada ffsica se ocupa de transnutlr os bits.
Quantos volts usar para e 1, quantos bits pOI segundo
podem ser enviados e se a transmissao pode ocorrer em
ambas as direc;oes simultaneamente sao questoes funda-
mentais na camada ffsica. Ademais, 0tamanho e aforma
do conector de rede (plug), bem como 0numero de pinos
e 0significado de cadaurn, tarnbem entram aqui.
aprotocolo da camada ffsica trata da padronizac;ao
das interfaces eletrica, medinica e de sinalizac;ao, de
modo que, quando uma rnaquina enviar urn bit 0, este seja
real mente recebido como urn bit 0, e nao como urn bit 1.
Foram desenvolvidos rnuitos padroes de camada ffsica
(para mfdias diferentes): por exemplo, 0padrao RS-232-
C para linhas de comunicac;ao seriais.
A camada ffsica se limita aenviar bits. Contanto que
nao ocorra nenhum erro, tudo corre bem. Entretanto,
redes de comunicac;ao reais estao sujeitas a erros, por
isso e necessario algum mecanismo para detecta-Ios e
corrigi-Ios. Esse mecanismo eatarefaprincipal da cama-
da de enlace. aque ela faz e agrupar os bits em unida-
des, as vezes denominadas quadros, e providenciar para
que cada quadro seja corretamente recebido.
A camada de enlace faz seu trabalho colocando urn
paddlo especial debits no infcio eno final decada quadro
para marca-Io, bem como calcula uma soma de verifiea-
~ao somando todos os bits presentes no quadro de certa
maneira. A camada de enlace anexa a soma de verifica~
c;aoao quadro. Quando 0quadro chega, 0receptor calcu-
la novamente asoma de verificac;ao dos dados eacompa-
ra com a soma de verificac;ao que acornpanha 0quadro.
Se as duas combinarem, 0quadro econsiderado correto e
C a be<;a lho da c a m a da de en la c e
C a be<;a lho da c a m a da de rede
C a be<;a lho da c a m a da de tra n spo rte
C a be<;a lho da c a m a da de sessa o
C a be<;a lho da c a m a da de a presen ta <;a o
C a be<;a lho da c a m a da de a pli c a <;a o
--.....,r-
Bi ts qu e rea lm en te a pa rec em n a rede
e aceito. Se as somas nao combinarem, 0receptor solici-
ta ao remetente que retransmita 0quadro. Os quadros
recebem uma sequencia de numeros no cabe9alho de
modo que todos possam reconhecer qual equal.
Em uma LAN, em geral nao h:i necessidade de 0
remetente localizar 0receptor. Ele apenas coloca amensa-
gem na rede e 0receptor aretira. Entretanto, uma rede de
longa distancia consiste emurn grande numero de maqui-
nas, cada qual com algumas linhas para outras maquinas,
mais ou menos como urnmapa emgrande escala que mos-
tra as cidades principais e as rodovias que as conectam.
Para ir do remetente ate 0receptor, uma mensagem talvez
tenha defazer alguns saltas escolhendo, emcada urn, uma
linha de saida para usar. A questao de como escolher 0
melhor caminho edenominada roteamento ee, emessen-
cia, atarefa primaria da camada de rede.
oproblema e complicado pelo fato de que a rota
mais curta nem sempre e a melhor. 0que realmente
importa e 0atraso total em determinada rota 0qual, por
sua vez, esta relacionado com a quantidade de trafego e
com 0numero de mensagens enfileiradas para transmis-
sao nas varias linhas. Assim, 0atraso pode mudar ao
longo do tempo. Alguns algoritmos de roteamento ten-
tam se adaptar a cargas variaveis, enquanto outros se
contentam em tomar decisoes com base em medias de
longo prazo.
No momento, 0protocolo de rede de mais ampla uti-
liza9ao e 0protocolo de Internet (Internet Protocol -
IP) sem conexao, que faz parte da pilha de protocolos da
Internet. Urn pacote - termo tecnico para uma mensagem
na camada de rede - IP pode ser enviado sem nenhuma
prepara9ao antecipada. Cada pacote IF e roteado ate seu
destinatario, independentemente de todos os outros. Ne-
nhum caminho interno e selecionado, tampouco lembrado.
P ro to c o lo s de tra n spo rte
A camada de transporte forma a ultima parte do que
poderia ser denominada pilha basica de protocolos de
rede, no sentido de que ela implementa todos os servi90s
que nao sao fornecidos na interface da camada de rede,
mas que sao razoavelmente necessarios para construir
aplica90es de rede. Em outras palavras, a camada de
transporte transforma a rede subjacente em algo que urn
desenvolvedor de aplica9ao pode usar.
Pacotes podem ser perdidos no caminho entre 0
remetente e 0receptor. Embora algumas aplica90es pos-
sam manipular sua pr6pria recupera9ao de erros, outras
preferem uma conexao confiaveI. 0trabalho da camada
de transporte e fornecer esse servi90. A ideia e que a
camada de aplica9ao deva ser capaz de entregar uma
mensagem a camada de transporte com a expectativa de
que ela sera entregue sem se perder.
Ao receber uma mensagem da camada de aplica9ao.
a camada de transporte a desmembra em por90es peque-
nas 0suficiente para transmissao, designa acada uma urn
numero de sequencia e entao envia todas elas. A discus-
sao no cabe9alho da camada de transporte refere-se a
quais pacotes foram enviados, quais foram recebidos.
quantos mais 0receptor tern espa90para aceitar, quais
devem ser retransmitidos e t6picos semelhantes.
Conexoes de transporte confiaveis - que, por defini-
9ao, sao orientadas aconexao - podem ser construidas em
cima de servi90s derede orientados aconexao e semcone-
xao. No primeiro caso, todos os pacotes chegarao na se-
quencia correta (sechegarem), mas no segundo caso epo.-
sivel que urn pacote siga uma rota diferente e chegue mais
cedo do que 0pacote enviado antes dele. Cabe ao software
decamada detransporte colocar tudo emordem novamente
para manter a ilusao de que uma conexao de transporte e
como urn grande tubo - voce coloca mensagens dentro
dele eelas saem, semdanos, namesma ordememqueentra-
ram. Fornecer esse comportamento de comunica9ao fim-a-
fimeurn aspecto importante da camada de transporte.
oprotocolo de transporte da Internet edenominado
protocolo de controle de transmissao (Transmission
Control Protocol - TCP) e edescrito com detalhes em
Comer (2006). A combina9ao TCP/IP agora e usadz.
como urn padrao de facto para comunica9ao em rede. A
pilha de protocolos da Internet tambem suporta urn pro-
tocolo de transporte sem conexao denominado protoco-
10 universal de datagramas (Universal Datagram
Protocol- UDP), que e, em essencia, apenas 0IP COIL
algumas pequenas adi90es. I Programas de usuario que
nao precis am de urn protocolo orientado a conexao nor-
malmente usam UDP.
Protocolos de transporte adicionais sao propostos de
tempos emtempos. Por exemplo, para suportar transferen-
cia de dados em tempo real, foi definido 0protocolo de
transporte em tempo real (Real-time Transport
Protocol - RTP). 0RTP e urn ambiente operacional no
senti do de que especifica formatos de pacote para dado:
emtempo real semfornecer os mecanismos propriamente
ditos para garantir aentrega de dados. Ademais, ele espe-
cifica urn protocolo para monitorar econtrolar transferen-
cia de dados de pacotes RTP (Schulzrinne et aI., 2003).
Acima da camada de transporte, 0OSI distinguiu
tres camadas adicionais. Na prMica, somente acamada do
aplica9ao e usada. Na verdade, na pilha de protocol os dz.
Internet, tudo 0que esta acima da camada de transpone
foi agrupado. Veremos nesta se9ao que, quando setrata de
sistemas middleware, nem aabordagem do OSI nem adz.
Internet sao realmente adequadas.
1. Entenda-se neste trecho que 0protocolo UDP acrescenta algumas poucas fun<;:6esao protocolo IP, enao que 0UDP sejaparecido com0
IP (N. do RT).
A amada de sessao e, emessencia, uma versao apri-
da camada de transporte. Ela proporciona controle
ogo para monitorar qual eaparte que esta falando no
uto considerado e fornece facilidades de sincroniza-
ultimas sao uteis para permitir que usuanos insi-
?CJ ntos de verifica<;ao em transferencias longas de
..; que, na eventualidade de uma queda, basta voltar ate
o ponto de verifica<;ao, em vez de ate 0inicio. Na
poucas aplica<;6esestao interessadas na camada de
- eeraro que ela seja suportada. Ela nao esta presente
mesmo na pilha de protocolos da Internet. Entretanto,
texto de desenvolvimento de solu<;6esde middlewa-
conceito deuma sessao eseus protocolos relacionados
user bastante relevante, emespecial na defini<;aode
olos de comunica<;ao de niveis mais altos.
Diferentemente das camadas mais baixas,.que sepreo-
emlevar os bits do remetente ao receptor com con-
'dade e eficiencia, acamada de apresenta<;ao sepreo-
om0significado dos bits. A maioria das mensagens
nsiste emcorrentes aleat6rias de bits, mas eminfar-
mais estruturadas como nomes de pessoas, endere-
quantias de dinheiro eassirn por diante. Na camada de
nta<;aoepossivel definir registros quecontemcampos
esses eentao fazer comque0remetente avise0recep-
-: e amensagem contem determinado registro emcerto
o. Isso facilita a comunica<;ao entre maquinas que
representa<;6es internas diferentes.
A inten<;aooriginal da camada de aplica<;aoOSI era
er urn conjunto de aplica<;6es padronizadas de rede,
as de correio eletronico, transferencia de arquivos e
<;aodeterminal. Mas, agora, ela setornou 0reposit6-
para todas asaplica<;6eseprotocolos que, deuma manei-
_ au deoutra, nao seajustam auma das camadas subjacen-
_ Da perspectiva do modelo de referencia OSI, pratica-
- Ietodos ossistemas distribuidos sao apenas aplica<;6es.2
oque falta nesse modelo e uma clara distin<;aoentre
- =- ' <;6es,protocolos especificos deaplica<;aoeprotocolos
ogeral. Por exemplo, 0protocolo de transferencia de
uivos (File Transfer Protocol - FTP) da Internet
el eReynolds, 1985; Horowitz eLunt, 1997) define urn
010para transferir arquivos entre uma maquina clien-
~~uma maquina servidara. 0protocolo nao deve ser con-
- dido com0programaftp, que euma aplica<;aode usua-
- - = final para transferir arquivos e que tambem (nao apenas
coincidencia) implementa 0FIP da Internet.
Urn outro exemplo tipico de protocolo especifico de
.lica<;ao e 0protocolo de transferencia de hipertexto
HyperText Transfer Protocol- HTTP) (Fielding et aI.,
999), que eprojetado para gerenciar emanipular remota-
teatransferencia depaginas Web. 0protocolo eimple-
- ntado por aplica<;6es como browsers Web e servidores
eb. Contudo, hoje 0HTIP tambem eusado por sistemas
que nao estao intrinsecamente vinculados a Web. Par
exemplo, 0mecanismo de invoca<;aode objeto do J ava usa
HTIP para requisitar a invocac;ao de objetos remotos que
saoprotegidos por urnfirewall (Sun Microsystems, 2004 b).
Tambem ha muitos protocolos de uso geral que sao
uteis para muitas aplica<;6es, mas que nao podem ser qua-
lificados como protocolos de transporte. Em muitos
casos, esses protocolos entram na categoria de protocolos
de middleware, que discutiremos a seguir.
Middleware e uma aplica<;ao que reside logicamen-
te, na maioria das vezes, na camada de aplica<;ao, mas que
contem muitos protocolos de uso geral que justificam
suas pr6prias camadas, independentemente de outras apli-
cac;6es mais especificas. Pode-se fazer uma distin<;ao
entre protocolos de comunicac;ao de alto nivel e protoco-
los para estabelecer varios servi<;osde middleware.
Ha inumeros protocolos para suportar uma varieda-
de de servic;os de middleware. Como discutiremos no
Capitulo 9, ha vanas maneiras de estabelecer autentica-
<;ao,isto e, fornecer prova de uma identidade declarada.
Protocolos de autenticac;ao nao estao fortemente vincula-
dos anenhuma aplica<;aoespecifica; emvez disso, podem
ser integrados a urn sistema middleware como urn servi-
<;0geral. Da mesma maneira, protocol os de autoriza<;ao
que concedam a usuarios e processos autenticados per-
missao de acesso somente a recursos para os quais
tenham autorizac;ao tendem a ter uma natureza geral,
independente de aplica<;ao.
Como outro exemplo, consideraremos varios proto-
colos distribuidos de comprometimento no Capitulo 8.
Protocolos de comprometimento estabelecem que, emurn
grupo de processos, ou todos os processos executam
determinada operac;ao ou a operac;ao nao e executada de
jeito nenhum. Esse fenomeno e denominado atomicida-
de etern ampla aplicac;ao em transac;6es. Como veremos,
alem de transa<;6es, outras aplica<;6es, como as tolerantes
a falha, tambem podem aproveitar as vantagens dos pro-
tocolos distribuidos de comprometimento.
Como ultimo exemplo, considere urn protocolo dis-
tribuido de bloqueio pelo qual urn recurso pode ser prote-
gido contra acesso simultaneo por urn conjunto deproces-
sos que sao distribuidos por varias maquinas. Encon-
traremos varios desses protocolos no Capitulo 6. Mais
uma vez, esse e urn exemplo de protocolo que pode ser
usado para implementar urn servic;o geral de middleware,
mas que, ao mesmo tempo, tern grande independencia em
relac;ao aqualquer aplica<;ao especifica.
Protocol os de comunica<;ao de middleware suportam
servic;os de comunicac;ao de altonivel. Por exemplo, nas
duas sec;6esseguintes discutiremos protocolos que permi-
- . 'aturalmente os autores nao pretendemabordar aqui os enormes esforc;:osdepadronizac;:aodacamada deaplicac;:aoocorridos no ambien-
~051 enaInternet (N. do R.T.).
tam a urn processo chamar urn procedimento ou invocar
urn objeto em uma maquina mantendo alta transparencia.
De maneira semelhante, ha servi~os de comunica~ao de
alto nivel para estabelecer esincronizar fluxos para trans-
ferir dados emtempo real, como os necessanos para apli-
ca~6es multimfdia. Como ultimo exemplo, alguns siste-
mas de middleware oferecern servi~os multicast confia-
veis que podem ser ampliados para milhares de recepto-
res espalhados par uma rede de longa distancia.
Alguns dos protocolos de comunica~ao de middlewa-
repoderiam, comigual propriedade, pertencer acamada de
transporte, mas talvez haja raz6es especificas para mante-
los emurn nivel mais alto. Por exemplo, servi~os multicas-
ting confiaveis que garantem escalabilidade podem ser
implementados somente se os requisitos da aplica~ao
forem levados emconta. Por conseqiiencia, urn sistema de
middleware pode oferecer diferentes protocolos (adapta-
veis), cada urn, por sua vez, usando diferentes protocol os
de transporte, mas oferecendo uma unica interface.
A ado~ao dessa abordagem de camadas resulta em
urn modelo de referencia para comunica~ao ligeiramente
adaptado, como mostra aFigura 4 .3. Emcompara~ao com
o modelo OSI, as camadas de sessao e apresenta~ao
foram substituidas por uma unica camada de middleware
que contern protocolos independentes de aplica~ao. Esses
protocolos nao pertencem as camadas mais baixas que
acabamos de discutir. as servi~os de transporte originais
tambem podem ser oferecidos como urn servi~o de mid-
dleware, sem modifica~ao. Essa abordagem e, de certo
modo, analogaaoferecer UDP no nivel de transporte. Da
mesma maneira, servi~os de comunica~ao de middleware
podem incluir servi~os de troca de mensagens compara-
veis aos oferecidos pela camada de transporte.
No restante deste capitulo, vamos nos concentrar em
quatro servi~os de comunica~ao de middleware de alto
nivel: chamadas de procedimentos remotos, servi~os de
enfileiramento de mensagens, suporte para comunica~ao
de midia continua por fluxos e multicasting. Antes de
fazer isso, ha outros criterios gerais para distinguir comu-
nica~ao (de middleware) que discutiremos a seguir.
4 . 1 . 2 T i p os d e c om u ni c ac ao
Para entender as vanas alternativas de comunica~ao
que 0middleware pode oferecer a aplica~6es, vemos 0
middleware como urn servi~o adicional de computa~ao
cliente-servidor, como mostra aFigura 4 .4 . Considere, por
exemplo, urn sistema de correio eletronico. Em principio,
o cerne do sistema de entrega de correio pode ser visto
Si nc roni zar na
a presen ta 98.0 da
requ i si 98.0
Si n c ro n i za r n a
en trega da
requ i si 98.0
Si n c ro n i za r a p6s
pro c essa m en to
pelo servi do r
urn servi~o de comunica~ao de middleware. Cada
~eiro executa urn agente de usm'irio que permite aos
-0compor, enviar e receber e-mail. Urn agente de
- 0remetente passa 0correio para 0sistema de entre-
_ ~correio esperando que este, par sua vez, entregue,
gum momento, 0correio ao receptor pretendido. Da
maneira, 0agente de usuano no lado do receptor
ecta com0servi~o de entrega de correio para ver se
--~ou alguma mensagem. Em caso positivo, as mensa-
= - ao transferidas para 0agente de usuano, de modo
_ ~passam ser apresentadas elidas pelo usmirio.
Urn sistema de correio eletronico eurn exemplo tipi-
o qual a comunica~ao e persistente. Com comunica-
- persistente, uma mensagem que foi apresentada para
missao earmazenada pelo middleware de comunica-
- durante 0tempo que for necessario para entrega-Ia ao
;;plor. Nesse caso, 0middleware arrnazenara a mensa-
em urn ou em varios recursos de armazenamento
ados na Figura 4 .4 . Por conseqiiencia, nao e neces-
0que a aplica~ao remetente continue em execu~ao
~ - apresentar a mensagem. Da mesma maneira, a apli-
_ >- 0 receptora nao precisa estar em execu~ao no
mento emque a mensagem e apresentada.
Emcompara~ao, no caso da comunicac;ao transien-
uma mensagem e armazenada pelo sistema de comu-
,ao somente durante 0tempo em que a aplica~ao
:=metente e a aplica~ao receptora estiverem executando.
_!ai exatamente: com referencia aFigura 4 .4 , se 0mid-
- eware nao pode entregar uma mensagem devido a uma
terrup~ao de transmissao, ou se 0receptor nao estiver
. 0no momenta considerado, amensagem sera simples-
ente descartada. Normalmente, todos os servi~os de co-
unica~ao de nivel de transporte oferecern somente
::omunica~ao transiente. Nesse caso, 0sistema de comu-
. a~ao consiste em repassadores tradicionais do tipo
:mnazena-e-reenvia. Seurn repassador nao puder entregar
:nna mensagem ao pr6ximo repassador, ou ao hospedeiro
.iedestino, ele apenas descarta amensagem.
Alem de persistente ou transiente, a comunica~ao
mmbempode ser assincrona ou slncrona. 0aspecto carac-
~stico da comunicac;ao assincrona eque urn remetente
::ontinua sua execu~ao imediatamente ap6s ter apresenta-
o sua mensagem para transmissao. Isso significa que a
mensagem e imediatamente armazenada, temporariamen-
, pelo middleware assim que apresentada. Com comuni-
cac;ao sincrona, 0remetente e bloqueado ate saber que
sua requisi~ao foi aceita. Ha, emessencia, tres pontos em
ue a sincroniza~ao pode ocorrer. Primeiro, 0remetente
pode ser bloqueado ate que 0middleware avise que se
encarregara da transmissao da requisi~ao. Segundo, 0
remetente pode sincronizar ate que sua requisi~ao seja
entregue ao receptor pretendido. Terceiro, asincroniza~ao
pode ocorrer permitindo que 0remetente espere ate que
uarequisi~ao tenha sido total mente processada, isto e, ate
o instante emque 0receptor retomar uma resposta.
Na pritica, ocorrem varias combina~5es de persis-
tencia e sincroniza~ao. As populares sao persistencia
combinada com sincroniza~ao na apresenta~ao da requi-
si~ao, que e urn esquema comum para muitos sistemas de
enfileiramento de mensagens que discutiremos mais
adiante neste capitulo. Da mesma maneira, a comunica-
~ao transiente com sincroniza~ao ap6s a requisi~ao ter
sido totalmente processada tambem e amplamente usada.
Esse esquema corresponde a chamadas de procedimento
remoto, que tambem discutiremos mais adiante.
Alem da persistencia e da sincroniza~ao, ainda
deveriamos fazer uma distin~ao entre comunica~ao dis-
creta e par fluxos. Ate aqui todos os exemplos caem na
categoria de comunicar;ao discreta: as partes se comuni-
cam por mensagens e cada mensagem forma uma unida-
de de informar;ao completa. Ao contrario, fluxo envolve
enviar varias mensagens, uma atras da outra, sendo que
as mensagens estao relacionadas umas com as outras
pela ordem emque sao enviadas, ou porque ha uma rela-
~ao temporal. Mais adiante voltaremos a comunica~ao
em fluxo com mais detalhes.
4 .2 C h am ad a d e p roc e d i m e nt o re m ot o
Muitos sistemas distribuidos sao baseados em troca
explfcita de mensagens entre processos. Contudo, os pro-
cedimentos sen d e rec ei ve nao escondem absolutamente
nada da comunica~ao, 0que eimportante para obter trans-
parencia de acesso em sistemas distribuidos. Esse proble-
ma e conhecido hi muito tempo, mas pouco tinha sido
feito para resolve-Io ateque urnartigo deautoria deBirrell
eNelson (1984 ) propos urn modo completamente diferen-
tede manipular comunicar;ao. Embora aideia seja bastan-
te simples (depois que alguem ateve), as implica~5es fre-
qiientemente sao sutis. Nesta ser;ao, examinaremos 0con-
ceito, sua implementar;ao, suas for~as e suas fraquezas .
Resumindo, a sugestao de Birrell e Nelson era per-
mitir que programas chamassem procedimentos locali-
zados em outras maquinas. Quando urn processo na
maquina A chama urn procedimento na maquina B, 0
processo chamador em A e suspenso, e a e)(eCUr;aodo
procedimento chamado ocorre em B. Informar;5es
podem ser transportadas do chamador para quem foi
chamado nos panlmetros epodem vol tar no resultado do
procedimento. Absolutamente nada da troca de mensa-
gens evisivel para 0programador. Esse metodo econhe-
cido como chamada de procedimento remoto ou, mui-
tas vezes, apenas como RPC.
Embora a ideia basica parer;a simples e elegante,
existem problemas sutis. Para come~ar, como 0procedi-
mento chamador e 0procedimento chamado rodam em
maquinas diferentes, executam em espar;os de enderer;o
diferentes, 0que causa complica~5es. Tambem e preciso
passar parametros eresultados, 0qile pode ser complica-
do, em especial se as maquinas nao forem identicas. Por
fim, qualquer uma das duas maquinas pode falhar e cada
uma das possiveis falhas causa problemas diferentes.
Ainda assim, e possivel lidar com muitos desses proble-
mas, eaRPC euma tecnica de ampla utilizac;ao subjacen-
te a muitos sistemas distribuidos.
4 . 2 . 1 O p e rac ao M s i c a d e R P C
Comec;aremos discutindo chamadas de procedimen-
to convencionais e em seguida explicaremos como a pr6-
pria chamada pode ser subdividida em uma parte cliente
e em outra servidora, que sac executadas em maquinas
diferentes.
Para entender como uma RPC funciona, emprimeiro
lugar e importante entender completamente como funcio-
nauma chamada deprocedimento convencional, isto e, em
uma unica maquina. Considere uma chamada emC como
onde fd e urn inteiro que indica urn arquivo, buf e urn
vetor de caracteres no qual os dados sac lidos, e nbytes e
urn outro inteiro que informaquantos bytes ler. Se acha-
mada for feita pelo programa principal, a pilha vai estar
como mostra aFigura 4 .5(a) antes dachamada. Para fazer
a chamada, 0chamador passa os parametros para a pilha
emordem, comec;ando pelo ultimo, como mostra aFigura
4 .5(b). (A razao por que compiladores C passam os para-
metros na ordem inversa tern a ver comprintj - fazendo
isso, printj sempre pode localizar seu primeiro parametro,
acadeia de formato.)
Ap6s a conclusao da exeCUc;aodo procedimento
read, ele coloca 0valor de retorno em um registrador,
remove 0enderec;o deretorno edevolve 0controle ao cha-
mador. Entao, este retira osparametros dapilha, devolven-
do-a ao estado original que tinha antes da chamada.
j
P o n tei ro da pi lha
Va ri a vei s lo c a i s do
pro gra m a pri n c i pa l
~
Vari ave i s l oc ai s d o
pro gra m a pri n c i pa l
n bytes
bu f
fd
en dere~ o de reto rn o
vari ave i s l oc ai s
de rea d
~
fa ) P a ssa gem de pa ra m etro s em u m a c ha m a da
de pro c edi m en to lo c a l: a pi lha a n tes da c ha m a da a
rea d. (b) A pi lha en qu a n to 0pro c edi m en to c ha m a do
esta a ti vo .
Ha varias coisas que merecem ser observadas. Uma
delas e que, em C, parametros podem ser chamadas por
valor ou chamadas por referenda. Urn parametro de
valor, como fd ou nbytes, e simplesmente copiado para a
pilha, como mostra aFigura 4 .5(b). Para 0procedimento
chamado, urn parametro de valor e apenas uma variavel
local com valor definido. 0procedimento chamado pode
modifica-lo, mas tais alterac;6es nao afetam 0valor origi-
nal no lado chamador.
Urn parametro de referencia em C e urn ponteiro
para uma variavel - isto e, 0enderec;o da variavel -, e
nao 0valor da variavel. Na chamada a read, 0segundo
parametro e urn parametro de referencia porque vetores
sac sempre passados por referencia em C. 0que e real-
mente passado para a pilha e 0enderec;o do vetor de
caracteres. Se 0procedimento chamado usar esse parame-
tro para armazenar algo no vetor de caracteres, ele real-
mente modifica 0vetor no procedimento chamador. A
diferenc;a entre chamadas por valor e chamadas por refe-
rencia e muito importante para RPC, como veremos.
Tambem existe urn outro mecanisme de passagem de
parametro, embora nao seja usado emC, denominado cha-
mada por copiar/restaurar. Ele consiste emfazer 0cha-
mador copiar avariavel para apilha, como emchamada par
valor, eentao copia-Ia de volta ap6s achamada, sobrescre-
venda 0valor original do chamador. Sob amaioria das con-
dic;6es, isso tern exatamente 0mesmo efeito que chamar
por referencia; porem, em algumas situac;6es, tal como 0
mesmo parametro estar presente vaDas vezes na lista de
parametros, asemantica ediferente. 0mecanismo chama-
da por copiar/restaurar nao eusado emmuitas linguagens. .
A decisao de qual mecanismo de passagem de para-
metro usar normalmente etomada pelos projetistas delin-
guagem eeuma propriedade fixa da linguagem. As vezes
ela depende do tipo de dado que esta sendo passado. Por
exemplo, emC, inteiros e outros tipos escalares sac sem-
pre passados por valor, ao passe que vetores sac sempre
passados por referencia, como vimos. Alguns compilado-
res Ada usam copiar/restaurar para parametros de entrada
esaida (in out), mas outros usam chamada por referencia.
A definic;ao da linguagem permite qualquer uma das
opc;6es, 0que torna a semantica urn pouco vaga.
R p e nd i c e s d e c l i e nt e e d e s e rvi d or
A ideia que fundamenta aRPC e fazer com que uma
chamada de procedirnento remoto parec;a0mais possivel
uma chamada local. Em outras palavras, queremos que
RPC seja transparente - 0procedimento de chamada nao
deve estar ciente deque 0procedirnento chamado esta exe-
cutando em uma maquina diferente ou vice-versa.
Suponha que urnprograina precise ler alguns dados de urn
arquivo. 0programador coloca uma chamada para read
no c6digo para obter os dados. Em urn sistema tradicional
- monoprocessador -, arotina read eextraida dabiblio-
teca pelo ligador einserida no programa objeto. E urn pro-
~nto curto, que emgeral eimplementado chamando
~hamada de sistema rea d equivalente. Em outras
. 0procedimento rea d eurntipo deinterlace entre
-go de usuario e0sistema operacionallocal.
.-\inda que rea d fac;:auma chamada de sistema, ela e
da maneira usual, passando os parametros para a
omo mostra aFigura 4 .5(b). Assim, 0programador
- 5Gbe que, na verdade, rea d esta fazendo algo suspeito.
RPC consegue sua transparencia de modo analogo.
o rea d e, na verdade, urn procedimento remoto -
=xemplo, urn procedimento que executara na maqui-
ervidor de arquivo -, uma versao diferente de
- =~ denominada apendice de c1iente, e colocada na
- eca. Como a original, ela e chamada usando a
=_-~ncia de chamada da Figura 4 .5(b). Tambem como a
ela faz uma chamada ao sistema operacional
6 que, diferentemente da original, ela nao pede ao
-=rna operacional que the de dados. Em vez disso,
ota os parametros em uma mensagem e requisita
a mensagem seja enviada para 0servidor, como
do na Figura 4 .6. Em seguida a chamada para
. 0apendice de cliente chama rec ei ve, bloqueando
mesmo ate que aresposta volte.
Espera pelo resu lta do
C li en te / ----------l~
C ha m a da de Reto rn o da
pro c edi m en to rem o to c ha m a da
80.,,,,"",-"'"0 J R",-P,""_
C ha m a da de pro c edi m en to Te~
lo c a l e reto rn o de resu lta do s
::-_~ r4 .6 P ri n c i pi o de RP C en tre u m pro gra m a c Hen te
e u m pro gra m a servi do r.
Quando a mensagem chega ao servidor, 0sistema
racional do servidor apassa para urn apendice de ser-
Odor. Urn apendice de servidor e 0equivalente, no lade
ervidor, a urn apendice de cliente: e urn pedac;:ode
:6digo que transforma requisic;:6esque vem pel arede em
~adas de procedimento locais. Normalmente 0apen-
~. e de servidor tera chamado rec ei ve e estara bloquea-
e perando por mensagens que chegam. 0apendice de
-ervidor desempacota os parametros da mensagem e
almo chama 0procedimento do servidor da maneira
sual, isto e, como na Figura 4 .5.
Do ponto de vista do servidor, e como se ele fosse
~hamado diretamente pelo cliente - os parametros e
::nderec;:oderetorno estao todos na pilha aqual pertencem
~nada parece fora do normal. 0servidor executa seu tra-
i>alhoe entao retorna 0resultado ao chamador do modo
ual. Por exemplo, no caso de rea d, 0servidor enchera
o buffer, apontado pelo segundo parametro, com os
dados. Esse buffer sera interno ao apendice de servidor.
Quando 0apendice de servidor retoma 0controle de
volta ap6s aconclusao da chamada, ele empacota 0resul-
tado (0buffer) em uma mensagem e chama sen d para
retorna-Io ao cliente. Depois disso, 0apendice de servidor
usualmente faz novamente uma chamada a rec ei ve, afim
de esperar pela pr6xima requisic;:aoque chegar.
Quando amensagem volta a maquina cliente, 0sis-
tema operacional do cliente ve que ela esta enderec;:ada
ao processo cliente (ou, na verdade, ao apendice de
cliente, mas 0sistema operacional nao pode ver a dife-
renc;:a).A mensagem e copiada para 0buffer que esta a
espera e 0processo cliente e desbloqueado. 0apendice
de cliente inspeciona amensagem, desempacota 0resul-
tado, 0copia para seu chamador e retorna da maneira
usual. Quando 0chamador retoma 0controle em segui-
da a chamada para rea d, tudo que ele sabe e que seus
dados estao disponiveis. Ele nao tern ideia de que 0tra-
balho foi realizado remotamente em vez de pelo sistema
operacional local.
Essa santa ignorancia da parte do cliente e0born de
todo 0esquema. No que the diz respeito, servic;:osremo-
tos sac acessados fazendo chamadas de procedimento
comuns - isto e, locais -, e nao chamando sen d e
rec ei ve. Todos os detalhes da troca de mensagens ficam
ocultos nos dois procedimentos de biblioteca, exatamente
como os detalhes de fazer chamadas de sistema ficam
ocultos embibliotecas tradicionais.
Resumindo, uma chamada de procedimento remoto
ocorre nas seguintes etapas:
1. 0procedimento de cliente chama 0apendice de
cliente do modo normal.
2. 0apendice de cliente constr6i uma mensagem e
chama 0sistema operacional local.
3. 0 SO do cliente envia a mensagem para 0SO
remoto.
4 . 0SO remoto da amensagem ao apendice de ser-
vidor.
5. 0apendice de servidor desempacota os parame-
tros e chama 0servidor.
6. 0servidor faz 0servic;:oeretorna 0resultado para
o apendice.
7. 0apendice de servidor empacota 0resultado em
uma mensagem e chama seu SO local.
B. 0SO do servidor envia a mensagem ao SO do
cliente.
9. 0SO do cliente da a mensagem ao apendice de
cliente.
10. 0apendice desempacota 0resultado e retorna ao
cliente.
oefeito liquido de todas essas etapas e converter a
chamada local pelo procedimento de cliente ao apendice
de cliente emuma chamada local para 0procedimento de
servidor sem que nem 0cliente nem 0servidor fiquem
cientes das etapas intermediarias ou daexistencia darede.
4 . 2 . 2 P as s ag e m d e p aram e t ros
A fun<;aodo apendice de cliente e pegar seus para-
metros, empacota-los em uma mensagem e envia-los ao
apendice de servidor. Embora essa opera<;ao pare<;adire-
ta, nao etao simples como parece a primeira vista. Nesta
se<;ao, veremos algumas das quest6es referentes a passa-
gem de parametros em sistemas RPc.
Empacotar parametros emuma mensagem e denomi-
nado montagem de parametros. Como urnexemplo muito
simples, considere urn procedimento remoto, add(i, j),
que pega dois parametros inteiros, i ej, eretoma sua soma
aritmetica como resultado. Na pr<itica, normalmente nin-
guem faria urn procedimento remoto ,desse procedimento
tao simples, mas ele serve bem como exemplo.
A chamada para add e mostrada na parte esquerda
(no processo cliente) da Figura 4 .7. 0apendice de clien-
te toma seus dois parametros e os coloca emuma mensa-
gem como indicado. Coloca tambem 0nome ou 0mime-
ro do procedimento a ser chamado na mensagem porque
o servidor poderia suportar vanas chamadas diferentes e
e preciso the dizer qual delas erequerida.
Quando amensagem chega ao servidor, 0apendice a
examina para ver qual procedimento e necessaria e entao
faz achamada apropriada. Se 0servidor tambem suportar
outros procedimentos remotos, 0apendice de servidor
poderia conter urn comando de chaveamento para selecio-
nar 0procedimento a ser chamado, dependendo do pri-
meiro campo da mensagem. A chamada propriamente
dita do apendice para a servidor eparecida com achama-
da original do cliente, exceto que os parametros san varia-
veis inicializadas com base na mensagem que entra.
Quando 0servidor terminou, 0apendice de servidor
retoma novamente 0controle. Ele pega 0resultado devol-
vi do pelo servidor e0empacota emuma mensagem. Essa
1. C ha m a da do c li en te
a pro c edi m en to
Apen di c e
Apen di c e de servi do r
de c li en te
2. Apen di c e m o n ta
m en sa gem
mensagem e enviada de volta ao apendice de cliente, que
a desempacota para extrair 0resultado e retoma 0valor
para 0procedimento de cliente aespera.
Contanto que as maquinas cliente e do servidor
sejam identicas etodos os parametros eresultados sejam
tipos escalares, como inteiros, caracteres e booleanos,
esse modelo funciona bem. Contudo, em urn sistema
distribuido de grande porte, e comum estarem presentes
varios tipos de maquinas. Cada maquina costuma ter sua
pr6pria representa<;ao para numeros, caracteres e outros
itens de dados. Por exemplo, mainframes IBM usam 0
c6digo de caracteres EBCDIC, enquanto computadores
pessoais IBM usam ASCII. Em decorrencia, nao e pos-
sivel passar urn parametro de caractere de urn cliente
IBM PC para urn servidor mainframe IBM usando 0
esquema simples da Figura 4 .7: 0servidor interpretara 0
caractere incorretamente.
Problemas semelhantes podem ocorrer com arepre-
senta<;aode inteiros (complemento de urn versus comple-
mento de dais) e de numeros de ponto flutuante. Alem
disso, existe urn problema ainda mais irritante porque
algumas maquinas, como Intel Pentium, numeram seus
bytes da direita para aesquerda, enquanto outras, como a
Sun SPARG, os numeram ao contrario. 0formato Intel e
denominado little endian, e0formata SPARC edenomi-
nado big endian, termos cunhados com base emAs via-
gens de Gulliver: alguns politicos se desentenderam por-
que uns defendiam quebrar ovos pela extremidade menor
(little end), e outros, pela extremidade maior (big end)
(Cohen, 1981). Como exemplo, considere urn procedi-
mento com dois parametros, urn inteiro euma corrente de
quatro caracteres. Cada parametro requer uma palavra de
32 bits. A Figura 4 .8(a) mostra a possivel aparencia da
por<;ao de parametros de uma mensagem construida por
urn apendice de cliente emuma maquina Intel Pentium. A
primeira palavra contem 0parametro inteiro, 5 nesse
caso, e a segunda contem acorrente' J ILL'.
5. Apen di c e desem pa c o ta
m en sa gem
4. SO servi do r en trega m en sa gem
a a pen di c e de servi do r
:_~ :_~ :_~ :_~
0 0 0 5
: } - L~
i _~ : _ ' : !
L L I J
0:
1
,
2
,
3: 0: 1
,
2: 3: , ,
- _. 1
5 0 0 0 0 0 0 5
_ ' : ! J 5:
_~J _~J _~J _~J _ E ? J }~J
J L L L L I J
(b) (c )
Iu ra 4 .8 la ) Men sa gem o ri gi n a l n o P en ti u m . IbJ Men sa gem a p6s reeebi m en to n a SP ARe. Ie) Men sa gem a p6s ser i n verti da .
Os pequ en o s n u m ero s n o s qu a dra do s i n di ea m 0en derei ;o de ea da byte.
Cma vez que as mensagens SaG transferidas pela
_ ~byte por byte (na verdade, bit por bit), 0primeiro
_ ~enviado e 0primeiro byte a chegar. Na Figura
mostramos que aspecto teria a mensagem da
7"= ra 4 .8(a) se recebida por uma SPARC, que numera
- b tes com 0a esquerda (byte de ordem alta) em
_~de a direita (byte de ordem baixa), como fazem
- - os chips Intel. Quando 0apendice de servidor ler
~ ametros nos endere~os 0e 4 , respectivamente,
::onrrani urn inteiro igual a 83,886,080 (5 X 2
24
) e
orrente 'J ILL'.
Uma abordagem 6bvia, embora infelizmente incor-
eapenas inverter os bytes de cada palavra depois de
_~ idos, 0que resulta na Figura 4 .8(c). Desta vez, 0
-~iroe5, e acorrente e 'LLIJ '. Nesse caso, 0problema
_ _ os inteiros SaGinvertidos pela ordena~ao diferente
)1es, mas as correntes nao. Sem informa~6es adicio-
- - obre 0que euma corrente e 0que eurn inteiro, nao
- -enhum modo de reparar 0dano.
Chegamos agora a urn problema diffcil: como sao
- dos ponteiros au, em geral, referencias? A resposta
~. - mente com amaior das dificuldades, seeque secon-
e. Lembre-se de que urn ponteiro s6 e significativo
=- rro do espa~o de endere~o do processo no qual esta
: do usado. Voltando ao nosso exemplo da chamada
- d ja discutido, se acaso a segundo parametro - a
_ ere~o do buffer - for 1000no cliente, nao podemos
;uer passar a numero 1000para a servidor e esperar que
",-e funcione. 0endere~o 1000no servidor poderia estar
meio do texto do programa.
Uma solu~ao e proibir ponteiros e parametros de
~ erencia em geral. Cantu do, eles sao tao importantes
"1. e essa solu~ao e muitissimo indesejavel. Na verdade,
bemnao enecessaria. No exemplo de read, a apendi-
~~de cliente sabe que a segundo parametro aponta para
:un conjunto de caracteres. Suponha, por enquanto, que
ele tambem saiba qual e a tamanho do vetor. Entao, uma
rrategia se toma aparente: copiar a vetor para a mensa-
.=: me envia-lo ao servidor. Assim, a apendice de servidor
poc!echamar 0servidor com urn ponteiro para esse vetor,
ainda que esse ponteiro tenha urn valor numerico diferen-
-~do valor do segundo parametro de read.
As altera~6es que a servidor faz usando a ponteiro
- por exemplo, armazenar dados nele - afetam direta-
mente 0buffer de mensagem dentro do apendice de servi-
dor. Quando a servidor termina, a mensagem original
pode ser enviada de volta ao apendice de cliente, que
entao a copia de volta para a cliente. Na verdade, chamar
por referencia foi substituida par copiar/restaurar.
Embora isso nem sempre seja identico, frequentemente e
born a suficiente.
Vma otimiza~ao toma esse mecanismo duas vezes
mais eficiente. Se as apendices souberem seabuffer eurn
parametro de entrada ou urn parametro de saida para a
servidor, uma das c6pias pode ser eliminada. Se 0vetor
for entrada para a servidor - par exemplo, emuma cha-
mada para write -, ele nao precisa ser copiado de volta.
Se for saida, nem precisa ser enviado.
Como ultimo comentario, vale a pena notar que, se
bem que agora possamos manipular ponteiros para veto-
res e estruturas simples, ainda nao podemos manipular 0
caso mais geral de urn ponteiro para uma estrutura de
dados arbitraria como urn grafico complexo. Alguns siste-
mas tentam lidar com esse caso realmente passando a
ponteiro para 0apendice de servidor e gerando c6digo
especial no procedimento de servidor para usar ponteiros.
Por exemplo, uma requisi~ao pode ser enviada de volta
para que a cliente fome~a as dados referenciados.
Especi~ca~ao d e p aram e t ros egera~ao d e ap e nd i c e s
Pel a que explicamos ate aqui, fica claro que ocultar
uma chamada de procedimento remota requer que 0cha-
mador e a chamado concordem com a fonnato das men-
sagens que trocam e sigam as mesmas etapas quando se
tratar de, par exemplo, passar estruturas dedados cample-
xas. Em outras palavras, ambos as lados de uma RPC
devem seguir a mesmo protocolo, au a RPC nao funcio-
nara corretamente.
Como urn exemplo simples, considere a procedi-
mento da Figura 4 .9(a). Ele tern tres parametros, urn
caractere, urn numero de ponto flutuante e urn vetor de
cinco inteiros. Considerando que uma palavra tern quatro
bytes, a protocolo RPC poderia prescrever que deveria-
mos transmitir urn caractere no byte da extrema direita de
uma palavra (deixando as 3 bytes seguintes vazios), urn
flutuante como uma palavra inteira e u.mvetor como urn
grupo de palavras igual ao comprimento do vetor, prece-
dido par uma palavra indicativa de seu comprimento,
como mostra aFigura 4 .9(b). Assim, dadas essas regras, a
apendice de cliente para foobar sabe. que deve usar 0for-
mato da Figura 4 .9(b), eo apendice de servidor sabe que
as mensagens que chegam para foobar tedio 0formato da
Figura 4 .9(b).
Definir 0formato da mensagem eurn aspecto de urn
protocolo RPC, mas nao e suficiente. Tambem precisa-
mos que 0cliente e0servidor concordem comarepresen-
ta<;ao de estruturas de dados simples, como inteiros,
caracteres, booleanos e assim por diante. 0 protocolo
poderia prescrever, por exemplo, que inteiros sao repre-
sentados em complementos de dois, caracteres em
Unicode de 16 bits e flutuantes no formato padrao IEEE
#754 com tudo armazenado em little endian. Com essa
informa<;ao adicional, as mensagens podem ser interpre-
tadas sem nenhuma ambigtiidade.
Agora que as regras de codifica<;ao estao fixadas ate
o ultimo bit, aunica coisa que resta fazer e que 0chama-
dor e 0chamado concordem com a troca de mensagens
propriamente dita. Pode-se decidir usar urn servi<;o de
transporte orientado a conexao como TCPIIP, por exem-
plo. Uma alternativa e usar urn servi<;onao confiavel de
datagramas e deixar que 0cliente e 0servidor implemen-
tern urn esquema de controle de erro como parte do pro-
tocolo RPC. Na pritica, existem diversas variantes.
Tao logo 0protocolo RPC esteja total mente defini-
do, os apendices de cliente e servidor precisam ser
implementados. Felizmente, a unica diferen<;a entre
apendices para 0mesmo protocolo, mas procedimentos
diferentes, normalmente sao suas interfaces com as
aplica<;6es. Uma interface consiste em urn conjunto de
procedimentos que podem ser chamados por urn cliente
e que sao implementados por urn servidor. Em geral,
uma interface esta disponfvel na mesma linguagem de
programa<;ao em que 0cliente ou servidor e escrito,
embora, em termos estritos, isso nao seja necessario.
Para simplificar as coisas, interfaces costumam ser
especificadas por meio de uma linguagem de progra-
maf;ao de interface (Interface Definition Language
- IDL). Portanto, uma interface especificada em tal
IDL e, na seqtiencia, compilada para zerar urn apendice
de cliente e urn apendice de servidor, junto com as
fo o ba r(c ha r x; flo a t y; i n t z[5] )
{
}
interfaces adequadas em tempo de compila<;ao e tempo
de execu<;ao.
A pritica mostra que usar uma linguagem de defini-
<;aode interface simplifica consideravelmente aplica<;6es
cliente-servidor baseadas em RPCs. Como e facil gerar
completamente apendices de cliente e de servidar, todos
os sistemas de middleware baseados em RPC oferecern
uma IDL para suportar desenvolvimento deaplica<;ao. Em
alguns casos, usar IDL e ate obrigatorio, como veremos
mais adiante em outros capftulos.
Como emchamadas deprocedimento convencionais,
quando urn cliente chama urn procedimento remoto, 0
cliente bloqueia ate que uma resposta seja retornada. Esse
comportamento estrito requisi<;ao/resposta edesnecessario
quando nao ha nenhum resultado a retornar, e so leva ao
bloqueio do cliente enquanto ele poderia ter continuado e
realizado trabalho utillogo apos requisitar 0procedimen-
to remoto a ser chamado. Entre os exemplos emque mui-
tas vezes nao ha necessidade de esperar por uma resposta
estao: transferir dinheiro de uma conta para outra, adicio-
nar entradas emurnbanco dedados, iniciar servi<;osremo-
tos, processainento emlote e assim par diante.
Para suportar essas situa<;6es, sistemas RPC podem
fornecer facilidades para 0que denominamos RPCs
assincronas, pelas quais urn cliente continua imediata-
mente apos emitir arequisi<;ao RPc. Com RPCs assfncro-
nas, 0servidor envia imediatamente uma resposta devolta
ao cliente no momenta em que a requisi<;ao RPC e rece-
bida e, depois disso, chama 0procedimento requisitado. A
resposta age como urn reconhecimento para 0cliente de
que 0servidor vai processar a RPc. 0cliente continuara
sem mais bloqueio, tao logo tenha recebido 0reconheci-
mento do servidar. A Figura 4 .1O(b) mostra como cliente
e servidor interagem no casu de RPCs assfncronas. Por
compara<;ao, a Figura 4 .1O(a) mostra 0comportamento
requisi<;ao-resposta normal.
RPCs assfncronas tambem podem ser uteis quando
uma resposta vai ser retornada mas 0cliente nao esta pre-
Va ri a vei s lo c a i s
de fo o ba r
I x
y
5
z(O]
z[1]
z[2]
z[3]
z[4]
0para esperar por ela e, enquanto espera, nada faz.
exemplo, urn cliente pode querer buscar antecipada-
- os endere<;:osde rede de urn conjunto de hospedei-
- '1 eespera contatar dentro de pouco tempo. Enquanto
- servir;o de nomear;ao esta colhendo esses enderer;os, 0
epode querer fazer outras coisas. Nesses casos, tern
- -do organizar acomunicar;ao entre 0cliente e0servi-
par meio de duas RPCs assincronas, como mostra a
- =- =:!la4 .11. Na primeira, 0cliente chama 0servidor para
- - entregar uma lista de nomes de hospedeiros que
emser consultados econtinua quando 0servidor reco-
-"""'or0recebimento dessa lista. A segunda chamada e
pelo servidor, que chama 0cliente para Theentregar
=nderer;os que encontrou. A combinar;ao de duas RPCs
, ronas as vezes tambem e denominada RPC assin-
na deferida.
E preciso notar que existem variantes deRPCs assin-
nas quais 0cliente continua executando imediata-
le ap6s enviar a requisir;ao ao servidor. Em outras
Has, 0cliente nao espera por urn reconhecimento da
~ra<;:ao da requisir;ao pelo servidor. Denominamos
chamadas RPCs de uma via. 0problema com essa
gem e que, quando a confiabilidade nao e garanti-
o cliente nao pode saber, com certeza, se a requisir;ao
- ou nao processada. Voltaremos a esses assuntos no
'rulo 8. Da mesma maneira, no caso de RPC sincrona
- -rida, 0cliente pode sondar 0servidor para ver se os
.sulrados estao disponiveis, emvez de deixar que 0ser-
r chame 0cliente de volta.
/
C ha m a pro c edi m en to
rem o to
'"
Reto rn a da
c ha m a da
Servi do r C ha m a pro c edi m en to Tem P 4
lo c a l e reto m a resu lta do s
4 .2.4 E x e m p l o: D C E R P C
Chamadas de procedirnento remoto foram ampla-
mente adotadas como base de middleware e sistemas dis-
tribuidos em geral. Nesta ser;ao, examinaremos mais de
perto urn sistema RPC especifico: 0ambiente distribuido
de computm.;ao (Distributed Computing Environment
- DCE), que foi desenvolvido pela Open Software
Foundation (OSF), agora denominada Open Group. 0
DCE RPC nao e tao popular como alguns outros sistemas
RPC, em particular 0Sun RPc. Contudo, ainda assim 0
DCE RPC erepresentativo de outros sistemas RPC e suas
especificar;6es foram adotadas no sistema basico da
Microsoft para computar;ao distribuida, DCOM (Eddon e
Eddon, 1998). Comer;amos com uma breve introdur;ao ao
DCE e depois consideramos 0principal modo de funcio-
namento do DCE RPc. Informar;6es tecnicas detaThadas
sobre como desenvolver ap1icar;6es baseadas em RPC
podem ser encontradas em Stevens (1999).
oDCE eurn verdadeiro sistema middleware no sen-
tido de que e projetado para executar como uma camada
de abstrar;ao entre sistemas operacionais existentes (rede)
e aplicar;6es distribuidas. Inicialmente projetado para
Unix, agora ele foi portado para todos os sistemas opera-
cionais importantes, entre eles variantes de VMS e
Windows, bem como para sistemas operacionais de com-
putadores de mesa. A ideia eque 0cliente possa pegar urn
/
C ha m a pro c edi m en to
rem o to
\
Reto rn a da
c ha m a da
Espera po r
C li en te ~ c - e~ tla J ~ ~
C ha m a pro c edi m en t/ ~ eto rn a da
rem o to c ha m a da
Requ i si <;a o Ac ei ta requ i si <;a o
Servi do r - - - - - - - - - - - - - - -
C ha m a pro c edi m en to lo c a l
conjunto de maquinas existentes, adicionar 0software
DCE e entao possa executar aplicar;oes distribufdas, tudo
isso sem perturbar aplicar;oes existentes (nao distribuf-
das). Embora a maioria dos pacotes DCE execute em
espar;o de usuario, em algumas configurar;oes e precise
adicionar urn pedar;o (parte do sistema de arquivo distri-
bufdo) ao micleo. 0proprio Open Group so vende codi-
go-fonte, que os fabricantes integram a seus sistemas.
omodelo de programar;ao subjacente a todo 0DCE
e 0modele cliente-servidor, que discutimos extensiva-
mente no capftulo anterior. Processos de usuarios agem
como clientes para acessar servir;os remotos fomecidos
por processos de servidor. Alguns desses servir;os sao
parte do proprio DCE, mas outros pertencem as aplica-
r;oes e sao escritos pelos programadores de aplicar;oes.
Toda acomunicar;ao entre clientes ese{vidores ocorre por
meio de RPCs.
Ha varios servir;os que fazem parte do DCE emsi. 0
servil;o de arquivo distribufdo e urn sistema de arquivo
de ambito mundial que fomece urn modo transparente de
acessar qualquer arquivo no sistema do mesmo modo. Ele
pode ser construfdo em cima dos sistemas nativos de
arquivo do hospedeiro, ou usado no lugar desses sistemas.
o servir;o de diretorio e usado para monitorar a
localizar;ao de todos os recurs os no sistema. Entre esses
recursos estao maquinas, impressoras, servidores, dados
e muito mais, e eles podem ser distribufdos geografica-
mente no mundo inteiro. 0servir;o de diretorio permite
que urn processo solicite urn recurso e nao tenha de se
preocupar com 0lugar em que ele esta, a menos que 0
processo se importe.
o servil;o de seguran~a permite que recursos de
todos os tipos sejam protegidos, portanto 0acesso pode
ser restrito as pessoas autorizadas.
Por fim, 0servi~o distribuido de honirio eurn ser-
vir;o que tenta manter sincronizados globalmente os relo-
gios presentes nas diferentes maquinas. Como veremos
em capftulos posteriores, ter alguma nor;ao do horario
global facilita muito na garantia da consistencia em urn
sistema distribufdo.
D b j e t i vos d o D C E R P C
OS objetivos do sistema DCE RPC sao relativamen-
te tradicionais. Antes de qualquer coisa, 0sistema RPC
permite a urn cliente 0acesso a urn servir;o remoto por
meio de uma simples chamada aurn procedimento local.
Essa interface possibilita que programas clientes, isto e,
aplicar;oes, sejam escritos de modo simples, familiar a
maioria dos programadores. Ele tambem facilita aexecu-
r;ao de grandes volumes de codigo em urn ambiente dis-
tribufdo com poucas alterar;oes, se tanto.
Cabe ao sistema RPC ocultar todos os detalhes dos
clientes e, ate certo ponto, tambem dos servidores. Para
comer;ar, o sistema RPC pode localizar automaticamente 0
servidor correto e, na sequencia, estabelecer a comunica-
r;ao entre software cliente e software servidor (em geral
denominada vincula~ao). Tambem pode manipular 0
transporte de mensagens em ambas as direr;oes, fragmen-
tando e montando novamente essas mensagens conforme
necessario (por exemplo, se urn dos parametros for urn
grande vetor). Por fim, 0sistema RPC pode manusear
automaticamente conversoes de tipos de dados entre 0
cliente e0servidor, ainda que eles executem emarquitetu-
ras diferentes eque tenham ordenar;ao de bytes diferente.
Como consequencia da capacidade de sistemas RPC
para ocultar os detalhes, e alto 0grau de independencia
entre clientes eservidores. Umcliente pode ser escrito em
J ava e urn servidor em C, ou vice-versa. Urn cliente eurn
servidor podem rodar em diferentes plataformas de hard-
ware e usar sistemas operacionais diferentes. Tambem e
suportada uma variedade de protocolos de rede e repre-
sentar;oes de dados, tudo sem nenhuma intervenr;ao do
cliente ou do servidor.
osistema DCE RPC consiste em varios componen-
tes, entre eles linguagens, bibliotecas, daemons, progra-
mas de utilidades etc. J untos, eles possibilitam escrever
clientes e servidores. Nesta ser;ao, descreveremos os
pedar;os e como eles se ajustam. 0processo inteiro de
escrever e usar urn cliente e servidor RPC esta resumido
na Figura 4 .12.
Em urn sistema cliente-servidor, a cola que mantern
tudo unido e a definir;ao da interface, como especificada
na linguagem de defini~ao de interface, ou IDL. Ela
permite declarar;oes de procedimento em uma forma
muito parecida com prototipos de funr;ao em ANSI C.
Arquivos IDL tambem podem conter definir;oes de tipos,
declarar;oes de constantes e outras informar;oes necessa-
rias para montar parametros e desmontar resultados cor-
retamente. 0ideal seria que adefinir;ao de interface tam-
bem contivesse uma definir;ao formal sobre 0que os pro-
cedimentos fazem, mas tal definir;ao nao esta ao alcance
nem mesmo da tecnologia mais modema existente hoje,
portanto a definir;ao de interface apenas define a sintaxe
das chamadas, e nao sua semantica. Na melhor das hip6-
teses, 0escritor pode adicionar alguns comentarios que
descrevam 0que os procedimentos fazem.
Urn elemento crucial em todo arquivo IDL e urn
identificador global exclusivo para ainterface especifica-
da. 0cliente envia esse identificador na primeira mensa-
gem RPC, e 0servidor verifica se ela esta correta. Desse
modo, se urn cliente tentar se vincular inadvertidamente
ao servidor errado, ou ainda auma versao mais antiga do
servidor correto, 0servidor detectara 0erro, e a vincula-
r;ao nao ocorrera.
Definir;oes de interface e identificadores exclusivos
sac intimamente relacionados emDCE. Como ilustrado na
Figura 4 .12, aprimeira etapa para escrever uma aplicar;ao
cliente/servidor normalmente e chamar 0programa uuid-
_ e olicitar que ele gere urn prot6tipo de arquivo IDL
_-= ontenha urn identificador de interface com agarantia
e esse identificador nunca mais sera utilizado em
-- uma interface gerada em nenhum lugar por uuidgen.
- =- ~ lusividade eassegurada com acodifica~ao da locali-
>- edo horario da cria~ao. 0identificador consiste em
llllinero binario de 128 bits representado no arquivo
L omo uma corrente ASCII emhexadecimal.
A pr6xima etapa eeditar 0arquivo IDL, preenchendo
- nomes dos procedimentos remotos e seus parametros.
:" eapena observar que RPC nao etota1mente transparen-
-~- por exemplo, 0cliente e 0servidor nao podem com-
~ar variaveis globais -, mas as regras IDL impossi-
ilitam expressar constru~6es que nao sejam suportadas.
Quando 0arquivo IDL estiver conclufdo, 0compila-
.. IDL e chamado para processa-lo. A safda do compila-
...; IDL consiste em tres arquivos:
1. Urn arquivo de cabe~alho (por exemplo, inteifa-
ce.h, em termos C).
2. 0apendice de cliente.
3. 0apendice de servidor.
o arquivo de cabe~alho contem identificador
~xclusivo, defini~6es de tipos, defini~6es de constantes
eprot6tipos de fun~ao. Deve ser inclufdo (using #inclu-
de) em ambos os c6digos, de cliente e de servidor. 0
apendice de cliente contern os procedimentos propria-
mente ditos que 0programa cliente chamara. Esses pro-
edimentos sao os responsaveis por colher e empacotar
os parametros na mensagem de safda e depois chamar 0
sistema de execu~ao para envia-los. 0 apendice de
cliente tambem manipula 0desempacotamento da res-
posta e 0retorno de val ores para 0cliente. 0apendice
de servidor contern os procedimentos chamados pelo
sistema de execu~ao na maquina do servidor quando
chega uma mensagem de entrada. Esses, por sua vez,
chamam os procedimentos de servidor propriamente
ditos, que fazem 0trabalho.
A pr6xima etapa e 0autor da aplica~ao escrever 0
c6digo de cliente e de servidor. Entao, ambos sao compi-
lados, assim como os dois procedimentos de apendice.
Em seguida, 0c6digo do cliente e os arquivos-objeto de
apendice de cliente resultantes sao ligados a biblioteca de
execu~ao para produzir 0binario executavel para 0clien-
te. De maneira semelhante, 0c6digo do servidor e0apen-
dice de servidor sao compilados eligados para produzir 0
binario do servidor. 0cliente e 0servidor sao iniciados
emtempo de execu~ao, de modo que aaplica~ao eexecu-
tada por meio deles.
Vi nc u l ac ao d e u rn c l i e nt e a u rn s e rvi d or
Para permitir que urn cliente chame urn servidor, e
necessario que 0servidor seja registrado eesteja prepara-
do para aceitar chamadas que chegam. 0registro de urn
servidor possibilita que urn cliente localize e se vincule a
urn servidor. A localiza~ao e feita emduas etapas:
1. Localizar amaquina do servidor.
2. Localizar 0servidor - isto e, 0processo correto
- naquela maquina.
A segunda etapa e urn tanto sutil. Basicamente, ela
se resume no fato de que, para se comunicar com urn
servidor, 0 cliente precisa conhecer uma porta na
maquina do servidor para 0qual ele possa enviar mensa-
gens. Vma porta (tambem conhecida como terminal) e
usada pelo sistema operacional do servidor para distin-
guir mensagens que chegam de diferentes processos. Em
DCE, uma tabela de pares (servidor, porta) e mantida
em cada maquina servidora por urn processo denomina-
do daemon D e E . Antes de ficar disponivel para requi-
si~5es que chegam, 0servidor deve solicitar uma porta
ao sistema operacional. Entao, ele registra essa porta no
daemon DCE. 0daemon DCE registra essa informa~ao
(incluindo quais protocolos 0servidor fala) na tabela de
portas para utiliza~ao futura.
oservidor tambem se registra !I0servi~o de diret6-
rio fornecendo-Ihe 0endere~o de rede da maquina servi-
dora e urn nome sob 0qual 0servidor possa ser procura-
do. Portanto, a vincula~ao de urn cliente a urn servidor
prossegue como mostra aFigura 4 .13.
Vamos supor que 0cliente queira sevincular aurnser-
vidor de video que e conhecido no local sob 0nome/
local/multimedia/video/movies. Ele passa esse nome para 0
servidor de diret6rio, que retorna 0endere~o de rede da
maquina que estaexecutando 0servidor devideo. Portanto,
o cliente vai ate0daemon DCE naquela maquina (que tern
uma porta bem conhecida) e solicita que ele consuite a
porta do servidor de video em sua tabela de portas. De
posse dessa informa~ao, agora a RPC pode ocorrer. Nas
RPCs subseqtientes, essa consulta nao emais necessaria. 0
DCE da a clientes a capacidade de realizar buscas mais
sofisticadas por urn servidor adequado quando isso for
necessario. RPC segura tambem e uma op~ao quando a
confidencialidade ou aintegridade dos dados for crucial.
E x e c u c ao d e u m a R P C
A RPC propriamente dita e executada transparente-
mente ede maneira usual. 0apendice de cliente monta os
parametros para a biblioteca de execu~ao para transmis-
sac usando 0protocolo escolhido em tempo de vincula-
~ao. Quando uma mensagem chega no lado do servidor,
ela e roteada para 0servidor correto com base na porta
contida na mensagem de entrada. A biblioteca de execu-
~ao passa a mensagem ao apendice de servidor, que des-
monta os parametros echama 0servidor. A resposta volta
pel arota inversa.
o DCE fornece varias op~5es de semantica. 0
padrao (default) eaopera~ao no maximo uma vez, caso
em que nenhuma chamada jamais e executada mais de
uma vez, mesmo em face da queda do sistema. Na prMi-
ca, isso significa que, se urn servidor cair durante uma
RPC e depois se recuperar rapidamente, 0cliente nao
repete a opera~ao, por temer que elaja tenha sido execu-
tada uma vez.
Como alternativa, e possivel marcar urn procedimen-
to remoto como idempotente (no arquivo IDL), caso em
que elepode ser repetido varias vezes semdano. Por exem-
plo, aleitura deurnbloco especificado emurnarquivo pode
ser tentada uma vez atras da outra ate ser bem-sucedida.
Quando uma RPC idempotente falha por causa daqueda de
urn servidor, 0cliente pode esperar ate que 0servidor rei-
nicie e entao tenta mais uma vez. Ha tambem outras
semanticas disponiveis, mas raramente usadas; entre elas
fazer broadcast da RPC para todas as maquinas presentes
na rede local. Voltaremos a semantica de RPC no Capitulo
8, quando discutirmos RPC na presen~a de falhas.
4 . 3 C om u ni c ac ao ori e nt ad a a m en sa gem
Chamadas de procedimento remoto e invoca~5es de
objeto remoto contribuem para ocultar comunica~ao em
sistemas distribuidos, isto e, aprimoram a transparencia
de acesso. Infelizmente, nenhum dos dois mecanismos e
sempre adequado. Em particular, quando nao se pode
adotar como premissa que 0lado receptor esta executan-
do no momenta em que uma requisi~ao e emitida, sac
necessarios servi~os alternativos de comunica~ao. Da
mesma maneira, a natureza sincrona inerente das RPCs,
pel a qual urn cliente e bloqueado ate que sua requisi~ao
2. Regi stra r servi ,o
Ma qu i n a servi do ra
ido processada, as vezes precisa ser substituida por
outra coisa.
"= a Dutra coisa e a troca de mensagens. Nesta se~ao
nos concentrar emcomunica<;ao orientada amensa-
em sistemas distribuidos, em primeiro lugar fazendo
exame mais minucioso do que e, exatamente, 0com-
o ento sincrono e quais sao suas implica<;6es. Em
-=--:da discutiremos sistemas de troca de mensagens que
a premissa de que as partes estao executando no
ento da comunica<;ao. Por fim, estudaremos sistemas
- eiramento demensagens, que permitem aos proces-
- ~ informa<;6es ainda que a outra parte nao esteja
do no momenta emque acomunica<;ao einiciada.
om u ni c ac ao t rans i e nt e ori e nt at l a a m e ns ag e m
_1uitos sistemas distribuidos e aplica<;6es sao cons-
- - diretamente em cima do modele simples orienta-
.;.mensagem oferecido pela camada de transporte. Para
r entender e apreciar sistemas orientados a mensa-
OIDO parte de solu<;6es de middleware, emprimeiro
_~ discutiremos troca de mensagens por meio deportas
- 'Yel de transporte.
.. : eBer~ele~
A padroniza<;ao da interface da camada de transpor-
: - . alvo de especial aten<;aopara permitir que progra-
- ~ res usem todo 0seu conjunto de protocolos (de troca
nsagens) por meio de urn conjunto simples de pri-
. Ademais, interfaces padronizadas facilitam por-
a aplica<;aopara uma maquina diferente.
Como exemplo, faremos uma breve discussao da
ace Sockets como proposta na decada de 1970
- _ 0Unix Berkeley. Uma outra interface importante e
_ TIT (XIOpen Transport Interface), que quer dizer
rface de trans porte X/Open, anteriormente deno-
da interface de camada de transporte (Transport
_.;er Interface - TLI) e desenvolvida pela AT&T.
-ets eXTI sao muito semelhantes no que serefere a
__ modelo de programa<;ao de rede, mas seus conjuntos
=- - ~ rimitivas sao diferentes.
Em termos de conceito, urn soquete e urn terminal
omunica<;ao para 0qual uma aplica<;aopode escrever
o que devem ser enviados pel a rede subjacente e do
pode ler dados que chegam. Urn soquete forma uma
- =rra<;aosobre 0terminal de comunica<;ao propriamente
- 0que e usado pelo sistema operacional local para urn
'ocolo de transporte especifico. No texto a seguir,
os nos concentrar nas primitivas de interface para
-;CP, que sao mostradas na Tabela 4 .1.
Em geral, servidores executam as quatro primeiras
;::imitivas, normalmente na ordem dada. Ao chamar apri-
~tiva so c ket, 0chamador cria urn novo terminal de
_ munica<;ao para urn protocolo de transporte especifico.
-ternamente, a cria<;ao de urn terminal de comunica<;ao
significa que 0sistema operacionallocal reserva recursos
para atender ao envio e ao recebimento de mensagens de
epara 0protocolo especificado.
A primitiva bi n d associa urn endere<;o local com 0
soquete recem-criado. Por exemplo, um servidor deve
vincular a urn soquete 0endere<;o IP de sua maquina,
junto com urn numero de porta (possivelmente bem
conhecido). A vincula<;ao diz ao sistema operacional que
o servidor quer receber mensagens somente no endere<;o
eporta especificados.
Si g ni fi c ad o
C ri e u m n o vo term i n a l de c o m u n i c a c ;;a o
An u n c i e a di spo si c ;;a o de a c ei ta r
c o n ex6es
Blo qu ei e 0c ha m a do r a te c hega r
u m a requ i si 9a o de c o m u n i c a 9a o
Ten le esta belec er u m a c o n exa o
a ti va m en te
Rec eba a lgu n s da do s pela c o n exa o
-
_c _lo _s_e I. Ten te esta belec er u m a c o n exa o
A primitiva li sten e chamada somente no caso de
comunica<;ao orientada a conexao. E uma chamada nao
bloqueadora que permite ao sistema operacional local
reservar buffers suficientes para urn numero especificado
de conex6es que 0chamador esta disposto a aceitar.
A chamada a c c ept bloqueia 0chamador ate chegar
uma requisi<;ao de conexao. Quando chega uma requisi-
<;ao, 0sistema operacional local cria urn novo soquete
com as mesmas propriedades do original e 0retorna ao
chamador. Essa abordagem permitira que 0servidor, por
exemplo, bifurque urn processo que, na sequencia,
manipulara a comunica<;ao propriamente dita por meio
da nova conexao. Enquanto isso, 0servidor pode voltar
e esperar por uma outra requisi<;ao de conexao no
soquete original.
Agora vamos examinar 0lado cliente. Tambem aqui,
em primeiro lugar e precise criar urn soquete usando a
primitiva so c ket, mas nao enecessario vincular 0soquete
explicitamente a urn endere<;o local, visto que 0sistema
operacional pode alocar dinamicamente uma porta quan-
do a conexao for estabelecida. A primitiva c o n n ec t
requer que 0chamador especifique 0endere<;ode nivel de
transporte para 0qual uma requisi<;ao deconexao deve ser
enviada. 0cliente e bloqueado ate que uma conexao seja
estabelecida com sucesso e, depois disso, ambos os lados
podem come<;ar atrocar informa<;6es por meio das primi-
tivas sen d e rec ei ve.
Por fim, 0fechamento de uma conexao e simetrico
quando se usa a interface Sockets, e e conseguido ao se
fazer com que ambos, cliente eservidor, chamem aprirni-
tiva c lo se. 0padrao geral seguido por umcliente eservi-
dor para comunicac;ao orientada a conexao usando a
interface Sockets e mostrado na Figura 4 .14 . Detalhes
sobre programac;ao de rede que usa Socket e outras inter-
faces em um ambiente Unix podem ser encontrados em
Stevens (1998).
In terfa c e de tro c a de m en sa gen s [MP I]
Com 0advento de multicomputadores de alto desem-
penho, desenvolvedores comec;aram a procurar prirnitivas
orientadas amensagem que lhes perrnitissem escrever com
facilidade aplicac;5es de alta eficiencia. Isso significa que
as primitivas devem estar emumnivel conveniente deabs-
trac;ao (para facilitar 0desenvolvimento da aplicac;ao) e
que sua implementac;ao incorra em uma sobrecarga mini-
ma. Soquetes foram considerados insuficientes por duas
raz5es. A primeira e que eles estavam no myel errado de
abstrac;ao porque suportavam somente primitivas simples
sen d e rec ei ve. A segunda eque a interface Sockets foi
projetada para comunicac;ao por redes que usam pilhas de
protocolos de uso geral, tal como TCPIIP. Eles nao eram
considerados adequados para os protocolos proprietarios
desenvolvidos para redes deinterconexao de alta velocida-
de, como as usadas em clusters de servidores de alto
desempenho. Esses protocolos requeriam uma interface
que pudesse manipular caracteristicas mais avanc;adas,
como diferentes farmas de buffer e sincronizac;ao.
oresultado foi que amaioria das redes de intercone-
xao e multicomputadores de alto desempenho era despa-
chada com bibliotecas de comunicac;ao proprietarias.
Essas bibliotecas ofereciam uma profusao de prirnitivas
de comunicac;ao de alto nivel, em geral, eficientes. Claro
que todas as bibliotecas eram mutuamente incompativeis,
de modo que, nessa circunstancia, os desenvolvedores de
aplicac;ao tinham umproblema de portabilidade.
A certa altura, a necessidade de ser independente de
hardware e de plataforma resultou na definic;ao de um
padrao para troca de mensagens, denominado simples-
mente interface de passagem de mensagens (Message-
Passing Interface), ou MPI. A MPI eprojetada para apli-
cac;5es paralelas e, par isso, talhada para comunicac;ao
transiente. Ela faz uso direto da rede subjacente. Alem
,
,
P o n to de si n c ro n i za <;a o -J
,
so c ket
C li en te
disso, considera que falhas serias, como quedas de pro-
cessos ou partic;5es de rede, sejam fatais e nao requeiram
recuperac;ao automarica.
A MPI adota aprernissa de que acomunicac;ao ocar-
redentro deumgropo conhecido deprocessos. Cada gropo
recebe umidentificador. Cada processo dentro deumgropo
tamMm recebe um identificador (local). Por conseguinte,
um par (group/D, process/D) identifica exclusivamente a
fonte ou 0destinatario de uma mensagem e e usado no
lugar de umenderec;o denivel detransporte. Varios gropos
de processos, possivelmente sobrepostos, poderao estar
envolvidos em um servic;o de computac;ao, e todos eles
poderao estar emexecuc;ao ao mesmo tempo.
No cerne daMPI estao prirnitivas de mensagem para
implementar comunicac;ao transiente; as mais intuitivas
estao resurnidas na Tabela 4 .2.
Comunicac;ao assincrona transiente e suportada por
meio daprirnitiva MP I_bsen d. 0remetente apresenta uma
mensagem para transrnissao que, em geral, primeiro e
copiada para umbuffer local no sistema de execuc;aoMPI.
Quando amensagem foi copiada, 0remetente continua. 0
sistema de execuc;ao MPI local remover<l a mensagem de
seu buffer local e providenciara a transrnissao assim que
umreceptor tenha chamado uma prirnitiva receive.
P ri m i ti va Si gn i fi c a do
-,
MP I_bsen d An exa m en sa gem de sa i da a u m
bu ffer lo c a l de en vi o
MP I_sen d En vi a u m a m en sa gem e espera a te qu e
seja c o pi a da pa ra bu ffer lo c a l o u rem o to
MP I_ssen d En vi a u m a m en sa gem e espera
a te 0rec ebi m en to c o m e'ta r
MP I_sen drec v En vi a u m a m en sa gem e espera
po r respo sta
MP Usen d P a ssa referen c i a pa ra m en sa gem
de sa i da e c o n ti n u a
MP Ussen d
P a ssa referen c i a pa ra m en sa gem de sa i da
e espera a te 0rec ebi m en to c o m e'ta r
MP Uec v Rec ebe u m a m en sa gem ; blo qu ei a se
n a o ho u ver n en hu m a
MP Urec v Veri fi c a se ha u m a m en sa gem
c hega n do , m a s n a o blo qu ei a
Ta bela 4.2 Algu m a s da s pri m i ti va s de tro ea de m en sa gen s m a i s
i n tu i ti va s da MP I.
,
,
,
C o m u n i c a 98.0 \
,
Ha tambem uma opera<;ao de envio bloqueadora,
orninada MP I_sen d, cuja semantica e independente da
lementa<;ao. A primitiva MP I_sen d pode bloquear 0
ador ate que a mensagem especificada tenha sido
iada para 0sistema de execu<;aoMPI no lado do reme-
ou ate que 0receptor tenha iniciado uma opera<;aode
~ bimento. A comunica<;aosincrona, pela qual 0remeten-
loqueia ate que sua requisi<;aoseja aceita para ulterior
: essamento, esta disponivel por meio da primitiva
I_ssen d. Por fim, a forma mais forte de comunica<;ao
ona tambem esuportada: quando urnremetente chama
:ll_sen drec v, eleenviauma requisi<;aoao receptor eblo-
-..::<::ia ate que esse ultimo retorne uma resposta. Basica-
te, essa primitiva corresponde auma RPC normal.
Ambas, MP I_sen d e MP Lssen d, tern variantes
__e evitam a copia de mensagens de buffers de usuarios
buffers internos do sistema de execu<;ao MPI local.
variantes correspondem auma forma de comunica-
- assincrona. Com MP Usen d, urn remetente passa urn
teiro para a mensagem; em seguida 0sistema de exe-
__';- 0MPI providencia acomunica<;ao. 0remetente con-
~ imediatamente. Para evitar sobrescrever a mensa-
~ antes da conclusao da comunica<;ao, a MPI oferece
;:iJ nitivas para verificar conclusao, ou atebloquear, sefor
iso. Assim como acontece com MP Lsen d, nao e
:cificado se a mensagem foi realmente transferida
o receptor ou se ela foi simples mente copiada pelo
- ma de execu<;ao MPI local para urn buffer interno.
Da maneira semelhante, com MP Ussen d, urn
;=metente tambem passa somente urn ponteiro para 0sis-
-ana de execu<;ao MPI. Quando 0sistema de execu<;ao
car que processou a mensagem, 0remetente tern a
prantia de que 0receptor aceitou amensagem e esta tra-
-alhando com ela naquele momento.
A opera<;ao MP I_rec v e chamada para receber uma
~,ensagem; ela bloqueia 0chamador ate chegar uma men-
__ em. Tambem ha uma variante assincrona, denominada
Urec v, pel a qual urn receptor indica que esta prepa-
o para aceitar uma mensagem. 0receptor pode verifi-
se a mensagem realmente chegou ou nao ou bloquear
-" que uma chegue.
A semantica das primitivas de comunica<;ao MPI
::a n sempre e direta e, as vezes, primitivas diferentes
emser trocadas semafetar acorre<;aodeurnprograma.
_...razao oficial por que sao suportadas tantas formas dife-
:-=Iltesde comunica<;ao eque isso da aos implementadores
istemas MPI possibilidades suficientes para otimizar
empenho. Os ceticos talvez digam que 0comite nao
:0 eguiu chegar auma decisao conjunta, portanto aceitou
mas as propostas. A MPI foi projetada para aplica<;6es
aIelas de alto desempenho, 0que facilita entender sua
- "ersidadeem diferentes primitivas de comunica<;ao.
Sequiser saber mais sobre MPI, consulte Gropp et al.
998b). A referencia completa, na qual sao explicadas
. ralhadamente as mais de cern fun<;6esda MPI, pode ser
=n ontrada emSnir et al. (1998) eemGropp et al. (1998a).
4 . 3 . 2 C om u ni c ac ao p e rs i s t e nt e ori e nt ad a a m e ns ag e m
Chegamos agora auma classe importante de servi<;os
de middleware orientados a mensagem, geralmente
conhecidos como sistemas de enfileiramento de mensa-
gens, ou apenas middleware orientado a mensagem
(MOM). Sistemas de enfileiramento de mensagens pro-
porcionam suporte extensivo para comunica<;ao assincro-
na persistente. A essencia desses sistemas e que eles ofe-
recem capacidade de armazenamento de medio prazo
para mensagens, sem exigir que 0remetente ou 0recep-
tor estejam ativos durante a transmissao da mensagem.
Uma diferen<;a importante entre a interface Sockets
Berkeley e MPI e sistemas de enfileiramento de mensa-
gens e que estes normalmente visam ao suporte de trans-
ferencias de mensagens que tern permissao de durar
minutos em vez de segundos ou milissegundos. Em pri-
meiro lugar, explicamos uma abordagem geral para siste-
mas de enfileiramento de mensagens e concluimos esta
se<;aocomparando-os com sistemas mais tradicionais, em
particular os sistemas de e-mail da Internet.
A ideia basica que fundamenta urn sistema de enfi-
leiramento de mensagens eque aplica<;6es se comunicam
inserindo mensagens em filas especificas. Essas mensa-
gens sao repassadas por uma serie de servidores de
comunica<;ao e, a certa altura, entregues ao destinatario,
mesmo que ele nao esteja em funcionamento quando a
mensagem foi enviada. Na pratica, amaioria dos servido-
res de comunica<;ao estao diretamente conectados uns
aos outros. Em outras palavras, emgeral uma mensagem
e transferida diretamente a urn servidor destinatario. Em
principio, cada aplica<;ao tern sua propria fila particular
para a qual outras aplica<;6es podem enviar mensagens.
Uma fila so pode ser lida por sua aplica<;ao associada,
mas tambem e possivel que varias aplica<;6es comparti-
lhem uma unica fila.
Urn aspecto importante de sistemas de enfileiramento
de mensagens e que, em geral, urn remetente so tern a
garantia de que, acerta altura, sua mensagem sera inserida
nafilado receptor. Nenhuma garantia edada sobre quando,
nemao menos se, amensagem sera realmente lida, 0que e
totalmente deterrninado pelo comportamento do receptor.
Essa semantica permite comunica<;ao fracamente
acoplada em rela<;ao ao tempo. Por isso, nao ha necessi-
dade de 0receptor estar em execu<;ao quando uma men-
sagem for enviada para sua fila. Da mesma maneira, nao
ha nenhuma necessidade de 0remetente estar em execu-
<;aono momenta em que sua mensagem e apanhada pelo
receptor. 0remetente e 0receptor podem. executar em
completa independencia urn emrela<;aoao outro. Na ver-
dade, tao logo uma mensagem tenha sido depositada em
uma fila, ali permanecera ate ser removida, independente-
mente de seu remetente ou receptor estar "emexecu<;ao.
Isso nos da quatro combinac;6es emrelac;ao ao modo
de execuc;ao do remetente e receptor, como mostra a
Figura 4 .15.
Na Figura 4 .15(a), ambos, remetente ereceptor, exe-
cutam durante toda a transmissao de uma mensagem. Na
Figura 4 .15(b), somente 0remetente esta em execuc;ao,
enquanto 0receptor esta passivo, isto e, emurn estado no
qual aentrega da mensagem nao epossivel. Ainda assim,
oremetente pode enviar mensagens. A combinac;ao deurn
remetente passivo eurn receptor emexecuc;ao e mostrada
na Figura 4 .15(c). Nesse caso, 0receptor pode ler mensa-
gens que the foram enviadas, mas nao e necessario que
seus respectivos remetentes estejam tambem em execu-
c;ao. Por fim, na Figura 4 .15( d), vemos a situac;ao emque
o sistema esta armazenando - e possivelmente transmi-
tindo - mensagens mesmo enquantG 0remetente e 0
receptor estao passivos.
Em princfpio, mensagens podem conter quaisquer
dados. 0unico aspecto importante daperspectiva do mid-
dleware e que as mensagens sejam adequadamente ende-
rec;adas. Na prMica, 0enderec;amento efeito com 0forne-
cimento de urn nome exclusivo no ambito do sistema da
fila destinataria. Em alguns casos, 0tamanho da mensa-
gem pode ser lirnitado, embora tambem seja possivel que
o sistema subjacente se encarregue de fragmentar e mon-
tar grandes mensagens de modo completamente transpa-
rente para aplicac;6es. Urn efeito dessa abordagem eque a
interface basica oferecida as aplicac;6es pode ser extrema-
mente simples, como mostra aTabela 4 .3.
A prirnitiva put echamada por urnremetente para pas-
sar uma mensagem ao sistema subjacente, mensagem essa
que eanexada afilaespecificada. Como explicamos, essa e
uma chamada nao bloqueadora. A prirnitiva get euma cha-
mada bloqueadora pela qual urn processo autorizado pode
retirar amensagem que esta pendente hamais tempo nafila
especificada. 0processo ebloqueado somente seafilaesti-
ver vazia. Variac;6esdessa chamada permitem procurar uma
Rem eten te
em exec u 9a o
D
t
W
t
D
Rem eten te
em exec u 9a o
D
t
W
. . . . - - - - - - 1
I I
I I
I I
I I
I I
~- - - - - _ - !
Rec epto r
em exec u 9a o
(a )
Rec epto r
pa ssi vo
(b)
mensagem especffica na fila, por exemplo, usando uma
prioridade ou urn padrao de comparac;ao. A variante nao
bloqueadora e dada pela prirnitiva po ll. Se a fila estiver
vazia, ou seuma mensagem especffica nao puder ser encon-
trada, 0processo chamador simplesmente continua.
Si g ni fi c ad o
An exe u m a m en sa gem a u m a fi la
espec i fi c a da
Blo qu ei e a te qu e a fi la espec i fi c a da esteja
n a o va zi a e reti re a pri m ei ra m en sa gem
Veri fi qu e u m a fi la espec i fi c a da em bu sc a de
m en sa gen s e reti re a pri m ei ra . Nu n c a blo qu ei e
In sta le u m m a n i pu la do r a ser c ha m a do qu a n do u m a
m en sa gem fo r c o lo c a da em u m a fi la espec i fi c a
Ta bela 4.3 In terfa c e ba si c a pa ra u m a fi la em u m si stem a de
en fi lei ra m en to de m en sa gen s.
Por fim, a maioria dos sistemas de enfileiramento
tambem permite que urnprocesso instale urn manipulador
como umaftmf'clO de chamada de retorno, que e automa-
ticamente invocada sempre que uma mensagem for colo-
cada na fila. Chamadas de retorno tambem podem ser
usadas parainiciar automaticamente urn processo que
buscara mensagens na fila senenhum processo estiver em
execuc;ao naquele instante. Essa abordagem costuma ser
implementada por meio de urn daemon no lado do recep-
tor, que monitora continuamente afila embusca de men-
sagens que chegam e as manipula de acordo.
A rQ u i t e t u ra g e ni i d e u m s i s t e m a d e e nnl e i ram e nt o d e m e ns ag e ns
Agora vamos exarninar mais de perto 0que e, em
geral, urn sistema de enfileiramento de mensagens. Uma
das primeiras restlic;6es que fazemos e que mensagens so
podem ser colocadas em filas locais do remetente, isto e,
filas na mesma maquina ou, no maximo, emuma maquina
proxima, tal como na mesma LAN, e que possam ser
Rem eten te
pa ssi vo
Rem eten te
pa ssi vo
. . . . - - - - - - 1
I I
I I
I I
I I
I I
~ 2
. . . . - - - - - - 1
I I
I I
I I
I I
I I
~ - - - - - - ~
W
t
D
,- - - - - - - 1
I I
I I
I I
I I
I I
~ 2
Rec epto r
em exeC U9a o
(c )
Rec epto r
pa ssi vo
(d)
::aDc;adasdemodo eficiente por meio de uma RPC. Essas
- ao denominadas filas de fonte. Da mesma maneira,
agens s6 podem ser lidas em filas locais. Contudo,
mensagem colocada emuma filacontern aespecifica-
- de uma fila de destino para a qual ela deve ser trans-
-~.da. Cabe ao sistema de enfileiramento de mensagens a
sponsabilidade defornecer filas para remetentes erecep-
eprovidenciar para que as mensagens sejam transfe-
da sua fila de fonte para asua fila de destino.
E importante perceber que 0conjunto de filas e dis-
'do por varias maquinas. Por conseqiiencia, para
ferir mensagens, urn sistema de enfileiramento de
agens deve manter urn mapeamento de filas para
xalizac;oes derede. Na pratica, isso significa que eletern
manter bancos de dados (possivelmente distribuidos)
nomes de filas para localizac;oes de rede, como mostra
_ "1gura 4 .16. Note que tal mapeamento e completamen-
alogo autilizac;ao do Sistema de Nomes de Domfnio
~_ 'S) para e-mail na Internet. Por exemplo, quando
iamos uma mensagem para 0enderec;o 16gico de cor-
steen@cs.vu.nl, 0sistema de correio consultara 0
_. para achar 0enderec;o de rede (isto e, 0enderec;o IP)
ervidor de correio do receptor e 0usara para a trans-
. -ncia da mensagem propriamente dita.
Filas san gerenciadas por gerenciadores de fila.
almente, urn gerenciador de fila interage diretamen-
om a aplicac;ao que esta enviando ou recebendo uma
agem. Contudo, tambem ha gerenciadores especiais
- iila que funcionam como roteadores, ou repassadores:
_. sammensagens que chegam para outros gerenciado-
- de fila. Desse modo, urn sistema de enfileiramento de
agens pode crescer gradativamente ate uma rede de
breposil;ao completa denivel de aplicac;ao, por cima de
a rede de computadores existente. Essa abordagem e
. ar aconstruc;ao do primeiro MBone sobre aInternet,
- qual processos comuns de usuario eram configurados
_ mo repassadores multicast. Ocorre que multicasting
meio de redes de sobreposic;ao ainda e importante,
_ mo discutiremos mais adiante neste capitulo.
Repassadores podem ser convenientes por varias
:!Zoes.Por exemplo, emmuitos sistemas deenfileiramen-
C o n su lta do en dereqo
de fi la de n (vel
de tra n spo rte
to de mensagens nao ha urn servic;o geral de nomeac;ao
disponivel que possa manter dinamicarnente mapeamen-
tos fila-Iocalizac;ao. Ao contrario, a topologia da rede de
enfileiramento eestatica, ecada gerenciador de fila preci-
sa de uma c6pia do mapeamento fila-localizaC;ao. Nao e
preciso dizer que, emsistemas de enfileiramento de gran-
de escala, essa abordagem pode resultar facilmente em
problemas de gerenciamento de rede.
Uma soluc;ao e usar alguns repassadores que conhe-
cern a topologia da rede. Quando urn remetente A coloca
uma mensagem para 0destinatano B em sua fila local,
essa mensagem primeiro e transferida para 0repassador
mais proximo, digarnos, Rl, como mostra a Figura 4.17.
Nesse ponto, 0repassador sabe 0que fazer com amensa-
gem e a repassa na direc;ao de B. Por exemplo, Rl pode
entender, pelo nome deB, que amensagem deve ser repas-
sada para 0repassador R2. Desse modo, so os repassado-
res precisam ser atualizados quando filas sao adicionadas
ou removidas, enquanto todos os outros gerenciadores de
fila so tern de saber onde esta 0repassador mais proximo.
Portanto, de maneira geral, repass adores podem aju-
dar a construir sistemas escalaveis de gerenciamento de
fi.las. Contudo, a medida que as redes de enfileiramento
crescem, e claro que, em pouco tempo, a configurac;ao
manual de redes ficara completamente impossivel de
gerenciar. A unica soluc;ao e adotar esquemas de rotea-
mento dinamico, como se faz emredes de computadores.
Nesse particular, provoca certa surpresa que essas solu-
c;oesainda nao estejam integradas em alguns dos popula-
res sistemas de enfileiramento de mensagens.
Uma outra razao por que repassadores sao usados e
que eles permitem processamento secundano de mensa-
gens. Por exemplo, as vezes ha mensagens que precisam
ser registradas por razoes de seguranc;a e tolerancia a
falha. Uma forma especial de repassador que discutire-
mos na proxima sec;ao e a que funciona como urn gate-
way, transformando mensagens para urn formato que
pode ser entendido pelo receptor.
Por fim, repassadores podem ser usados para finali-
dade de multicasting. Nesse caso, uma mensagem que
chega e simplesmente colocada emcada fila de envio.
B rok e rs d e m e ns ag e ns
Uma importante area de aplicar,;ao de sistemas de
enfileiramento de mensagens eaintegrac;:aodenovas apli-
cac;:6esem urn unico e coerente sistema distribufdo de
informac;:6es. Integrac;:ao requer que aplicac;:6es possam
entender as mensagens que recebem, 0que, na pnitica,
significa que as mensagens enviadas pelo remetente
devam ter 0mesmo formato das mensagens do receptor.
o problema com essa abordagem eque cada vez que
uma aplicac;:aoeadicionada ao sistema que requer urn for-
mato diferente de mensagem, cadareceptor potencial teni
de ser ajustado de modo aproduzir aquele formato.
Uma alternativa e concordar com urn formato de
mensagem comum a todos, como e feito nos protocolos
tradicionais de rede. Infelizmente, de modo gera!, essa
abordagem nao funcionani para sistemas de enfileira-
mento de mensagens. 0problema e0nivel de abstrar,;ao
no qual esses sistemas operam. Urn formato de mensa-
gem comum atodos so tern sentido se 0conjunto de pro-
cessos que usam esse formato realmente tiver muito em
comum. Se 0conjunto de aplicac;:6esque comp6e urn sis-
tema distribuido de informac;:6es apresentar alta diversi-
dade, 0que freqiientemente acontece, entao 0melhor
formato comum pode perfeitamente ser nada mais do que
uma seqiiencia de bytes.
Embora alguns formatos de mensagem em comum
tenham sido definidos para dominios de aplicac;:aoespeci-
ficos, aabordagem geral eaprender aviver com diferentes
formatos etentar providenciar os meios para simplificar ao
maximo as convers6es. Em sistemas de enfileiramento de
mensagens, convers6es sao manipuladas par nos especiais
emuma rede deenfileiramento, conhecidos como brokers
de mensagens. Urn broker (intermediario) de mensagens
age como urn gateway de nfvel de aplicac;:aoemurn siste-
ma de enfileiramento de mensagens. Sua principal finali-
dade econverter mensagens que chegam demodo que elas
sejam entendidas pela aplicac;:aodestinataria. Observe que,
para urn sistema de enfileiramento de mensagens, urn bro-
ker de mensagens e apenas uma outra aplicac;:ao, como
. mostra aFigura 4 .18. Em outras palavras, de modo geral,
0::0::::

0::0::::
R1
0::0::::
.
.
Repo si t6ri o c o m regra s
e pro gra m a s de c o n versa o
roker de mensagens nao e considerado como uma
~integral do sistema de enfileiramento.
Urn broker de mensagens pode ser tao simples como
reformatador para mensagens. POl'exemplo, suponha
~uma mensagem que chega contenha uma tabela de
banco de dados na qual os registros sac separados pOl'
delimitador especial definal de registro eque os cam-
- - dentro de urn registro tenham urn comprimento fixo
ecido. Se aaplicac:;aodestinatana esperar urn delimi-
r diferente entre registros, e tambem esperar que os
os tenham comprimentos variaveis, urn broker de
-= agens pode ser usado para converter mensagens para
:ormato esperado pelo destinatario.
Emurn ambiente mais avanc:;ado,urn broker de men-
_ gens pode agir como urn gateway de nivel de aplicac:;ao
-;....i'. pOl'exemplo, manipule aconversao entre duas aplica-
_- - diferentes debancos dedados. Nesses casos, freqiien-
~ntenao sepode garantir que toda ainformac:;aoconti-
_ na mensagem de entrada possa ser realmente transfor-
emalgo apropriado para amensagem de safda.
Contudo, 0mais comum e utilizar urn broker de
-=ll agens para integra~ao avanc:;ada de aplica~oes
presariais (E nterprise Application Integration -
, como discutimos no Capitulo I. Nesse caso, em
~z de (apenas) converter mensagens, urn broker e res-
.: avel pOl' combinar aplicac:;6es com base nas mensa-
~=ns que sac trocadas. Nesse modelo, denominado
ublicar/subescrever, aplicac:;6es enviam mensagens na
=arma de publicar. Em particular, elas podem publicar
a mensagem sobre 0t6pico X, que depois e enviada
..:. broker. Entao, aplicac:;6es que declararam seu interes-
:~em mensagens sobre 0topico X, isto e, subscreveram
_ ~ as mensagens, as receberao do broker. Formas mais
..:. :anc:;adasde intermediac:;ao tambem sac possiveis, mas
'aremos discuss6es mais detalhadas ate 0Capitulo 13,
o centro deurnbroker demensagens encontra-se urn
::-eposit6riode regras e programas que podem transformar
a mensagem do tipo Tl emuma mensagem do tipo 72.
oproblema edefinir as regras edesenvolver os programas.
.-\maioria dos produtos debroker demensagens vemacom-
?afi.hada de sofisticadas ferramentas de desenvolvirnento
mas, narealidade, 0reposit6rio ainda precisa ser preenchi-
o par especialistas. Este eurnexemplo perfeito deproduto
-omercial cuja propaganda enganosa declara que eleforne-
'inteligencia' quando, na verdade, a unica inteligencia
que sepode encontrar esta nacabec:;ados especialistas.
b s e rvac ao s ob re s i s t e m as d e e nnl e i ram e nt o d e m e ns ag e ns
Considerando 0que dissemos sobre sistemas deenfi-
leiramento de mensagens, poderiamos concluir que eles
existem ha longo tempo na forma de implementac:;6es
para servic:;osde e-mail. Sistemas de e-mail geralmente
sao implementados par meio de urn conjunto de servido-
res de correio que armazenam e repassam mensagens em
nome dos usuarios em hospedeiros diretamente conecta-
dos ao servidar. Em geral, 0roteamento e excluido, por-
que sistemas de e-mail podem fazer usa direto dos servi-
c:;osde transporte subjacentes. Par exemplo, no protocolo
de correio para a Internet, SMTP (Postel, 1982), uma
mensagem e transferida estabelecendo uma conexao TCP
direta com 0servidor de correio destinatario.
oque tomaos sistemas de e-mail especiais emcom-
parac:;aocom os sistemas de enfileiramento de mensagens
e que eles visam primariamente a prover suporte direto a
usuarios finais. Isso explica, pOl'exemplo, pOl'que varias
aplicac:;6esde groupware sac baseadas diretamente emurn
sistema de e-mail (Khoshafian e Buckiewicz, 1995).
Ademais, sistemas de e-mail podem tel' requisitos muito
especificos como filtragem automatica de mensagens,
supOltepara bancos dedados avanc:;adosdemensagens (pOl'
exemplo, para recuperar comfacilidade mensagens arma-
zenadas anteriormente) e assim pOl'diante.
Sistemas gerais de enfileiramento de mensagens nao
visam a suportar somente usuarios finais. Uma questao
importante e que eles sac montados para possibilitar
comunicac:;ao persistente entre processos, independente-
mente de urn processo estar ou nao executando uma apli-
cac:;aode usuario, manipular acesso aurn banco de dados,
realizar calculos e assim par diante. Essa abordagem
resulta em urn conjunto de requisitos para sistemas de
enfileiramento de mensagens diferente do conjunto de
requisitos para sistemas de e-mail pmos. Par exemplo,
em geral, sistemas de e-mail nao precisam fornecer
entrega garantida de mensagens, prioridades de mensa-
gens, facilidades de registro, multicasting eficiente,
balanceamento de carga, tolerancia a falha e assim pOl'
diante, para uso geral.
POl' conseguinte, sistemas de enfileiramento de
mensagens de usa geral tern ampla faixa de aplicac:;6es,
incluindo e-mail, fluxo de trabalho, groupware e proces-
samento em lotes. Entretanto, como ja afirmamos antes,
aarea de aplicac:;aomais importante eaintegrac:;aode urn
conjunto de bancos de dados e aplicac:;6es (possivelmen-
te amplamente dispersos) em urn sistema federativo de
informac:;6es (Hohpe e Woolf, 2004 ). POl' exemplo, uma
consulta que abranja varios bancos de dados pode preci-
sar ser repartida emsubconsultas que sac repassadas para
bancos de dados individuais. Sistemas de enfileiramento
de mensagens ajudam fornecendo meios basicos para
empacotar cada subconsulta em uma mensagem e rotea-
la ate 0banco de dados adequado. Outras facilidades de
comunicac:;ao que discutimos neste capitulo sac muito
menos adequadas.
4 . 3 . 3 E x e m p l o: s i s t e m a d e e nfi l e i ram e nt o d e m e ns ag e ns
W e b Sp h e re d a I B M '
Para ajudar a entender como sistemas de enfileira-
mento de mensagens funcionam na pratica, vamos estu-
dar urn sistema especifico, a saber, 0sistema de enfilei-
ramento de mensagens que faz parte do produto
WebSphere da IBM. Conhecido anteriormente como
MQSeries, agora seu nome e WebSphere MQ. Ha uma
profusao de documentac;;ao sobre 0WebSphere MQ e,
no que vamos expor a seguir, so podemos recorrer aos
princfpios basicos. Muitos detalhes arquitet6nicos refe-
rentes as redes de enfileiramento de mensagens podem
ser encontrados em IBM (2005b, 2005d). Programar
redes de enfileiramento de mensagens nao e algo que
possa ser aprendido em uma tarde de domingo, e 0guia
de programac;;ao do MQ (IBM, 2005a) e urn born exem-
plo para mostrar que ir dos princfpios a pratica requer
consideravel esforc;;o.
A arquitetura basica de uma redede enfileiramen-
to MQ ebastante direta, como mostrado na Figura 4 .19.
Todas as filas sao gerenciadas por gerenciadores de
fila. Urn gerenciador de fila e responsavel por retirar
mensagens de suas filas erepassa-las a outros gerencia-
dores de fila. Da mesma maneira, urn gerenciador de
fila e responsavel por manipular mensagens que che-
gam retirando-as da rede subjacente e, na sequencia,
armazenando cada mensagem na fila de entrada adequa-
da. Para dar uma ideia do que a troca de mensagens
pode significar: uma mensagem tern urn tamanho
padrao maximo (default) de 4 MB, mas este pode ser
aumentado ate 100MB. Normalmente uma fila e res-
tringida a 2 GB de dados, porem, dependendo do siste-
ma operacional subjacente, e facil ajustar esse maximo
para urn valor mais alto.
Gerenciadores de fila sao conectados aos pares por
meio de canais de mensagens, que sao uma abstrac;;aode
conexoes de myel de transporte. Urn canal de mensagens
euma conexao unidirecional confiavel entre urn gerencia-
dor de fila de envio e urn gerenciador de fila de recebi-
mento, pela qual as mensagens enfileiradas sao transpor-
tadas. Por exemplo, urn canal de mensagens baseado na
Tro c a de m en sa gen s
(a ssi n c ro n a s)
Internet e implementado como uma conexao TCP. Cada
uma das duas extrernidades de urn canal de mensagens e
gerenciada por urn agente de canal de mensagens
(Message Channel Agent - MCA).
Basicamente, urn MCA de envio nada mais faz do
que verificar filas de envio em busca de uma mensagem,
embrulhar essa mensagem em urn pacote de nlvel de
transporte e envia-la pela conexao a seu MCA de recebi-
mento associado. Da mesma maneira, a tarefa basica de
urn MCA de recebimento e ficar a escuta de urn pacote
que chega, desempacota-lo e, na sequencia, armazenar a
mensagem desempacotada na fila apropriada.
Gerenciadores de fila podem ser ligados ao
mesmo processo que a aplicac;;ao cujas filas eles geren-
ciam. Nesse caso, as filas ficam ocultas da aplicac;;ao
por tras de uma interface padronizada mas, na verdade,
podem ser manipuladas diretamente pela aplicac;;ao.
Uma organizac;;ao alternativa e aquela em que gerencia-
dores de fila e aplicac;;oes executam em maquinas dife-
rentes. Nesse caso, e oferecida a aplicac;;ao a mesma
interface oferecida quando 0gerenciador de fila ecolo-
cado na mesma maquina. Contudo, ainterface eimple-
mentada como urn proxy que se comunica com 0
gerenciador de fila usando a tradicional comunicac;;ao
slncrona baseada em RPC. Desse modo, 0MQ conser-
va basicamente 0modelo no qual so filas locais para
uma aplicac;;ao podem ser acessadas.
Urn componente importante do MQ eformado pelos
canais de mensagens. Cada canal de mensagens tern exa-
tamente uma fila de envio associada, naqual ele obtem as
mensagens que deve transferir para a outra extrernidade.
A transferencia ao longo do canal pode ocorrer se os seus
MCAs, de envio e de recepc;;ao, estiverem ligados e em
funcionamento. Exceto a iniciac;;aomanual de ambos os
MCAs, ha diversos modos alternativos de iniciar urn
canal, alguns dos quais discutiremos a seguir.
-ma alternativa e fazer com que uma aplica~ao ini-
- - tamente sua extremidade de urn canal ativando 0
~de envio ou de recebimento. Contudo, do ponto de
transparencia, essa alternativa nao emuito atraen-
-ma abordagem mais apropriada para iniciar urn
_~ de envio e configurar a fila de envio do canal de
a acionar urn gatilho logo que uma mensagem for
da na fila. Esse gatilho esta associado com urn
ulador para iniciar 0MCA de envio de modo que
aremover mensagens da fila de envio.
Lma outra alternativa e iniciar urn MCA pel a rede.
7_ ?CUticular,seurn lado de urn canal ja estiver ativo, ele
enviar uma mensagem de controle requisitando que
MCA seja iniciado. Tal mensagem de controle e
da a urn daemon que esta a escuta em urn endere~o
onhecido na mesma maquina eIl).que 0outro MCA
- r er iniciado.
Canais param automaticamente ap6s a expira~ao de
ernpo especificado durante 0qual nenhuma mensa-
foi colocada na fila de envio.
Cada MCA tern urn conjunto de atributos associados
_~ determinam 0comportamento global de urn canal.
= desses atributos sao apresentados na Tabela 4 .4 .
_ ;alores dos atributos do MCA de envio erecebimento
- em ser compativeis e talvez negociados antes de urn
poder ser estabelecido. Por exemplo, e 6bvio que
os MCAs devem suportar 0mesmo protocolo de
orte. Urn exemplo de urn atributo nao negociavel e
mensagens devem ou nao ser entregues na mesma
_ ~rn em que foram colocadas na fila de envio. Se urn
_ CA quiser entrega emordem Fifo, 0outro deve aquies-
_ . Urn exemplo de urn valor de atributo negociavel e 0
primento maximo da mensagem, que sera escolhido
nas como 0valor minimo especificado por qualquer
dos MCAs.
Desc ri ~ a o
Determ i n a 0pro to c o lo de tra n s po rte
a ser u sa do
In di c a qu e a s m en sa gen s devem ser
en tregu es n a o rdem em qu e fo ra m en vi a da s
C o m pri m en to m a xi m o de u m a u n i c a
m en sa gem
Espec i fi c a 0n u m ero m a xi m o de n o va s
ten ta ti va s de i n i c i a r 0MC A rem o to
Nu m ero m a xi m o de vezes qu e 0MC A ten ta ra
c o lo c a r u m a m en sa gem rec ebi da n a fi la
C c m pri m en to
de m en sa gem
'u ste de c o n ta gem
de n o va s ten ta ti va s
o va s ten ta ti va s
de en trega
a bela 4.4 Algu n s a tri bu to s a sso c i a do s c o m a gen tes de c a n a l
de m en sa gen s.
frans fe re nc i a d e m en sa gen s
Para transferir uma mensagem de urn gerenciador
de fila para outro gerenciador de fila (possivelmente
remoto), e necessario que cada mensagem contenha 0
endere~o de seu destinatario, para 0que e usado urn
cabe~alho de transmissao. Urn endere~o em MQ e com-
posta de duas partes. A primeira parte consiste no nome
do gerenciador de fila para 0qual a mensagem deve ser
entregue. A segunda parte e 0nome da fila destinataria
que esta sob os cuidados do gerenciador ao qual a men-
sagem deve ser anexada.
Alem do endere~o do destinatario, tambem e
necessario especificar a rota que a mensagem deve
seguir. A especifica~ao da rota e feita com 0forneci-
mento do nome da fila de envio local a qual a mensa-
gem deve ser anexada. Portanto, nao enecessario forne-
cer a rota completa em uma mensagem. Lembre-se de
que cada canal de mensagens tern exatamente uma fila
de envio. Quando determinamos a qual fila de envio
uma mensagem deve ser anexada, na verdade estamos
especificando para qual gerenciador de fila uma mensa-
gem deve ser repassada.
Na maioria dos casos, as rotas estao armazenadas
explicitamente dentro de urn gerenciador de fila em uma
tabela de roteamento. Uma entrada de uma tabela de
roteamento eurn par (destQM, sendQ), onde destQM e 0
nome do gerenciador da fila destinataria, e sendQ e 0
nome da fila de envio local a qual uma mensagem para
aquele gerenciador de fila deve ser anexada. [Urnaentra-
da de tabela de roteamento e denominada 'apelido'
(alias) emMQ.]
E possivel que uma mensagem precise ser transferi-
da por varios gerenciadores de fila antes de chegar a seu
destino. Sempre que urn desses gerenciadores intermedia-
rios de fila recebe amensagem, ele simples mente extrai 0
nome do gerenciador da fila destinataria do cabec;:alhoda
mensagem e faz uma consulta a tabela de roteamento
local para descobrir aqual fila de envio local amensagem
deve ser anexada.
E importante perceber que cada gerenciador de fila
tern urn nome exclusivo no ambito do sistema, e esse
nome eefetivamente usado como identificador para esse
gerenciador de fila. 0problema de usar tais nomes eque
substituir urn gerenciador de fila ou mudar seu nome
afetara todas as aplica~6es que the enviam mensagens.
Os problemas podem ser amenizados utilizando urn ape-
lido local para nomes de gerenciadores de fila. Urn ape-
lido definido dentro de urn gerenciador de fila M1e urn
outro nome para 0gerenciador de fila M2, mas que s6
esta disponivel para aplicac;:6es que tenham interface
para M1. Urn apelido permite a utilizac;:ao do mesmo
nome (16gico) para uma fila, mesmo que 0gerenciador
dessa fila mude. Mudar 0nome de urn gerenciador de
fila requer que mudemos seu apelido em todos os geren-
ciadores de fila. Contudo, as aplicac;:6es podem conti-
nuar sem ser afetadas.
oprincipio da utiliza~ao de tabelas de roteamento e
apelidos e mostrado na Figura 4 .20. Por exemplo, uma
aplica~ao ligada ao gerenciador defila QMA pode serefe-
rir aurn gerenciador remoto defila usando 0apelido local
LAI. Em primeiro lugar, 0gerenciador de fila consul tara
o destinatario real na tabela de apelidos para descobrir
que ele e 0gerenciador de fila QMC. A rota para QMC e
encontrada na tabela de roteamento, que determina que
mensagens para QMC devem ser anexadas a fila de saida
SQI, usada para transferir mensagens para 0gerenciador
de fila QMB. Esse ultimo usara sua tabela de roteamento
para repassar a mensagem para QMC.
Seguir essa abordagem de roteamento e apelido
resulta em uma interface de programa~ao que, em essen-
cia, e relativamente simples, denominada interface de
fila de mensagens (Message Queue Interface - MQI).
As primitivas mais importantes da MQI estao resumidas
na Tabela 4 .5.
Atri bu to
MOo pen
MOc i o se
MOpu t
MOget
Descri"iio
Abra u m a fi la (po ssi velm en te rem o ta )
Fec he u m a fi la
C o lo qu e u m a m en sa gem em u m a fi la a berta
Obten ha u m a m en sa gem de u m a fi la (lo c a l)
Tabela 4 .5 P ri m i ti va s di spo n i vei s n a i n terfa c e de en fi lei ra m en to
de m en sa gen s.
Para colocar mensagens emuma fila, uma aplica~ao
chama a primitiva MQo pen , especificando uma fila des-
tinataria em urn gerenciador de fila especifico. 0geren-
ciador de fila pode ser nomeado usando 0apelido dispo-
nivel no local. Se afila destinataria e, na verdade, remota
ou nao e completamente transparente para a aplica~ao.
MQo pen tambem deve ser chamada se aaplica~ao quiser
obter mensagens de sua fila local. Somente filas locais
podem ser abertas para ler mensagens que chegam.
Quando uma aplica~ao concluir 0acesso auma fila, deve
fechar chamando MQc lo se.
Mensagens podem ser escritas para uma fila com 0
uso de MQpu t ou lidas de uma fila com 0uso de MQget.
Em principio, mensagens sac retiradas de uma fila de
acordo com uma prioridade. Mensagens com a mesma
prioridade sac retiradas com base no criterio primeira a
entrar, primeira a sair, isto e, a mensagem que esta pen-
dente hii mais tempo e retirada em primeiro lugar.
Tambem epossivel requisitar mensagens especificas. POl'
fim, MQ fornece facilidades para sinalizar as aplica90es
quando chegaram mensagens, evitando assim que uma
aplica9ao tenha de sondar continuamente uma fila de
mensagens aprocura de mensagens que entram.
G eren c i a m en to de redes de so brepo si c a o
Pela descri~ao que fizemos ate aqui, deve ter fica-
do claro que uma parte importante do gerenciamento de
sistemas MQ e conectar os varios gerenciadores de fila
por uma rede de sobreposi~ao consistente. Ah~m do
mais, essa rede precisa ser mantida ao longo do tempo.
Para redes pequenas, essa manuten~ao nao exigira mais
do que urn trabalho medio de administra9ao, mas as
coisas se complicam quando 0enfileiramento de men-
sagens e usado para integrar e desintegrar grandes sis-
temas existentes.
Uma questao importante em MQ e que redes de
sobreposi~ao precisam ser administradas manualmente.
Essa administra~ao nao envolve apenas erial' canais
entre gerenciadores de fila, mas tambem preencher as
tabelas de roteamento. E 6bvio que isso pode se trans-
formar em urn pesadelo. Infelizmente, 0suporte de
gerenciamento para sistemas MQ e avan9ado somente
no sentido de que urn administrador pode ajustar prati-
camente todos os atributos posslveis e retocar qualquer
configura~ao imaginavel. Todavia, a verdade nua e crua
e que os canais e tabelas de roteamento precisam ser
mantidos manualmente.
No centro do gerenciamento darede de sobreposi~ao
esta 0componente fun~ao de controle de canal que logi-
camente esta situado entre agentes de canais de mensa-
gens. Esse componente permite que urn operador monito-
:;c exatamente 0que estl acontecendo nas duas extremi-
de urn canal. Adernais, ele eusado para criar canais
las de roteamento, mas tambem para gerenciar os
_ nciadores de fila que hospedam os agentes de canais
- mensagens. De certo modo, essa abordagem do geren-
ento da sobreposi~ao e muito parecida com a do
;=-"n iamento de urn cluster de servidores no qual e
- 0urn unico servidor de administra~ao. Nesse ultimo
- . 0servidor oferece, emessencia, somente uma shell
_ ota para cada maquina no cluster, junto com algumas
~oes coletivas, para manipular grupos de maquinas.
a noticia sobre gerenciamento de sistemas distribui-
. =eque ele oferece varias oportunidades se voce estiver
urando uma area na qual explorar novas solu~oes
problemas serios.
C om u ni c ac ao ori e nt ad a a fl u x o
A discussao sobre comunica~ao que fizernos ate aqui
~ oncentrou na troca de unidades de informa~ao mais
_ menos completas e independentes. Entre os exemplos
__- 0urna requisi~ao para invocar urn procedimento, a
5pOsta a essa requisi~ao e mensagens trocadas entre
lica~6es, como em sistemas de enfileiramento de men-
- ~ens. 0aspecto caracteristico desse tipo de comunica-
>- 0eque nao importa em que ponto particular do tempo
_ omunica~ao ocorre. Embora 0funcionarnento de urn
rnapossa ser muito lento ou muito rapido, aternpori-
,ao nao tern efeito sobre a corre~ao.
Tambem ha formas de comunica~ao nas quais a
-~mporiza~ao desempenha papel crucial. Considere, por
i'xemplo, urn fluxo de audio construido como uma
seqUencia de amostras de 16bits, cada uma representan-
o a amplitude de uma onda sonora, como e feito na
:nodula~ao por codifica~ao de pulso (Pulse Code
_lodulation - PCM). Suponha tambem que 0fluxo de
audio represente qualidade de CD, o.que significa que a
onda sonora original foi amostrada auma freqUencia de
.100Hz. Para reproduzir 0som original, e essencial
que as amostras no fluxo de audio sejam tocadas na
ordem em que aparecem no fluxo, mas tambem a inter-
valos de exatamente 1/44.100 segundos. Reproduzi-Ias a
uma taxa diferente resultara em uma versao incorreta do
om original.
A questao que abordamos nesta se~ao equais SaGas
facilidades que urn sistema distribuido deve oferecer
para trocar informa~6es dependentes de tempo como
fluxos de audio e video. Varios protocolos de rede que
tratam de comunica~ao orientada a fluxo sao discutidos
em Halsall (2001). Steinmetz e Nahrstedt (2004) ofere-
cern uma introdu~ao global a questoes de multimidia,
das quais faz parte a comunica~ao orientada a fluxo.
Processamento de consulta em fluxos de dados e discu-
tido em Babcock et a1, (2002).
4 . 4 . 1 Su p ort e p ara m T d i a c onI T nu a
osuporte para a troca de informa~6es dependentes
do tempo costuma ser denominado suporte para midia
continua. Midia se refere aos meios pelos quais a infor-
ma~ao e transmitida, nos quais estao incluidos meios de
armazenamento e transmissao, meios de apresenta~ao
como urn monitor e assim por diante. Urn tipo importan-
te de meio e 0modo como a informa~ao e representada.
Em outras palavras, como a informa<;ao e codificada em
urn sistema de computa<;ao? Diferentes representa~oes
sao usadas para diferentes tipos deinforma~ao. Por exem-
plo, em geral, 0texto e codificado como ASCII ou
Unicode. Imagens podem ser representadas emdiferentes
formatos como GIF ou J PEG. Fluxos de audio podem ser
codificados em urn sistema de computa~ao, por exemplo,
tomando amostras de 16bits usando PCM.
Emmidia continua (de representa(,;ao), as rela<;oes
temporais entre diferentes itens de dados san fundamen-
tais para interpretar corretamente 0que os dados realmen-
te significam. J a demos urn exemplo da reprodu~ao de
onda sonora correspondente a urn fluxo de audio. Como
outro exemplo, considere 0movimento. 0 moviinento
pode ser representado por uma serie de imagens na qual
imagens sucessivas devem ser apresentadas aespa~os uni-
formes detempo, T, sendo que urn valor tipico e30-4 0ms
por imagem. A reprodu~ao correta requer nao somente
mostrar cadaquadro individual de imagem na ordem cor-
reta, mas tambem aurna freqUencia constante de lIT ima-
gens por segundo.
Ao contrario da midia continua, a midia discreta
(de representa(,;ao) e caracterizada pelo fato de que as
rela~oes temporais entre itens de dados nao sao funda-
mentais para interpretar corretamente os dados. Exemplos
tipicos de midia discreta sao representa<;oes de texto e
imagens estaticas, mas tambem c6digo-objeto ou arqui-
vos executaveis.
Para capturar troca de informa~6es dependentes de
tempo, emgeral os sistemas distribuidos fornecem supor-
te para fluxos de dados. Urn fluxo de dados nada mais e
do que uma seqUencia de unidades de dados. Fluxos de
dados podem ser aplicados amidia discreta, bem como a
midia continua. Por exemplo, pipes Unix ou conex6es
TCP/IP sao exernplos tipicos de fluxos discretos de dados
(orientados abytes). Reproduzir urn arquivo de audio nor-
malmente requer estabelecer urn fluxo continuo de dados
entre 0arquivo e 0dispositivo de audio.
A temporiza~ao e crucial para fluxos continuos de
dados. Para capturar asp~ctos da temporiza~ao, costuma-
se fazer uma distin~ao entre diferentes modos de trans-
missao. No modo de transmissao assincrono os itens de
dados emurn fluxo sao transmitidos urnap6s 0outro, mas
nao ha nenhuma restri~ao de temporiza~ao sobre quando
a transmissao de itens deve ocorrer. Esse e 0caso tfpico
de fluxos discretos de dados. Por exemplo, urn arquivo
pode ser transferido como urn fluxo de dados mas, na
maioria das vezes, e irrelevante 0momenta exato emque
atransferencia de cada item e conclufda.
No modo de transmissao sincrono, ha urn atraso
fim-a-fim maximo definido para cada unidade em urn
fluxo de dados. Nao importa seuma unidade de dados for
transferida com muito mais rapidez do que 0atraso maxi-
mo tolerado. Por exemplo, urn sensor pode tomar uma
amostra detemperatura acerta taxa etransmiti-la por uma
rede ate urn operador. Nesse caso, pode ser importante
garantir que 0tempo de propagac;ao fim-a-fim pela rede
seja menor do que 0intervalo de tempo entre tomadas de
amostras, mas nenhum dano sera causado se as amostras
forem propagadas commaior rapidez do que anecessaria.
Por fim, emmodo de transmissao isocrono eneces-
sano que as unidades de dados sejam transferidas no
tempo certo. Isso significa que a transferencia de dados
esta sujeita aumatraso fim-a-fim que tern urn valor maxi-
mo e urn valor mfnimo, tambem denominados varia~5es
de atraso delimitado. 0modo de transmissao is6crono e
particularmente interessante para sistemas distribuidos de
multimidia, porque ele desempenha papel crucial na
representa~ao de audio e video. Neste capitulo, conside-
ramos fluxos de dados usando transmissao is6crona, aos
quais vamos nos referir simplesmente como fluxos.
Fluxos podem ser simples ou complexos. Urn fluxo
simples consiste em uma unica sequencia de dados, ao
passo que urn fluxo complexo consiste em vanos fluxos
simples relacionados denominados subfluxos. A rela~ao
entre os subfluxos emurn fluxo complexo tambem costu-
ma ser dependente de tempo. Por exemplo, audio estereo
pode ser transmitido por meio deurn fluxo complexo con-
sistindo em dois subfluxos, cada urn usado por urn unico
canal de audio. Contudo, eimportante que esses dois sub-
fluxos estejam continuamente sincronizados. Em outras
palavras, unidades de dados de cada fluxo devem ser
comunicadas aos pares para garantir 0efeito estereo.
Urn outro exemplo de fluxo complexo e 0que trans-
mite urn filme. Esse fluxo poderia consistir em urn unico
fluxo de video junto com dois fluxos para transmitir 0
Servi do r de
m u lti m i di a
Da do s de
m u lti m i di a
c o m pri m i do s
som do filme emestereo. Urn quarto fluxo poderia conter
legendas para surdos ou uma tradu~ao para uma lingua
diferente da do audio. Mais uma vez, asincroniza~ao dos
subfluxos eimportante. Se asincroniza~ao falhar, arepro-
du~ao do filme falhara. Voltaremos a sincroniza~ao de
fluxos mais adiante.
Da perspectiva de sistemas distribuidos, podemos
distinguir diversos elementos que sao necessarios para
suportar fluxos. Para simplificar, vamos nos concentrar
em fluxos de dados armazenados, ao contrario de fluxos
de dados transmitidos ao vivo. Nesse ultimo caso, dados
capturados em tempo real sao enviados a receptores pela
rede. A principal diferen~a entre os dois eque atransmis-
sao de fluxos de dados ao vivo oferece menos oportunida-
des de sintonizar urn fluxo. Entao, segundo Wu et al.
(2001), podemos esquematizar uma arquitetura cliente-
servidor geral para suportar fluxos continuos de multirni-
dia, como mostra aFigura 4 .21.
Essa arquitetura geral revela varias quest5es impor-
tantes que precisam ser enfrentadas. Em primeiro lugar,
os dados de multimfdia, em particular de video e, em
menor propor~ao, de audio, precisarao ser comprirnidos
substancialmente de modo a reduzir 0armazenamento
requerido e, em especial, a capacidade da rede. 0mais
importante da perspectiva de comunica~ao sao 0controle
da qua1idade da transmissao e as quest5es de sincroniza-
~ao. N6s os discutiremos em seguida.
4 . 4 . 2 F l u x os e Q u al i d ad e d e s e rvi c o
Requisitos de temporiza~ao (e outros nao funcio-
nais) geralmente sao expressos como requisitos de quali-
dade de servi~o (Quality of Service - QoS). Esses
requisitos descrevem 0que enecessano da parte do siste-
ma distribuido subjacente e da rede para assegurar que,
por exemplo, as rela~5es temporais em urn fluxo possam
ser preservadas. QoS para fluxos continuos dedados refe-
rem-se principalmente apontualidade, ao volume eacon-
fiabilidade. Nesta se~ao, exarninaremos mais de perto a
QoS e sua rela~ao com 0estabelecimento de urn fluxo.
Muito ja foi dito sobre como especificar QoS requeri-
da (veja, por exemplo, J in eNahrstedt, 2004 ). Da perspec-
aplicac;ao, emmuitos casos tudo se resume a espe-
algumas propriedades importantes (Halsall, 2001):
A taxa debits requerida aqual os dados devem ser
transportados.
o maximo atraso ate 0estabelecimento de uma
essao, isto e, quando uma aplicac;ao pode come-
>ar aenviar dados.
omaximo atraso fim-a-fim, isto e, quanta tempo
levara ate que uma unidade de dados chegue aurn
receptor.
A maxima variancia de atraso, ou vibrac;ao.
omaximo atraso de viagem de ida e volta.
E precise observar que ha muitos refinamentos que
~mser feitos para essas especificac;6es, como expli-
. por exemplo, por Steinmetz eNahrstadt (2004 ).
rudo, quando se trata de comunicac;ao orientada a
o baseada na pilha de protocolos da Internet, temos
as de aceitar viver com 0fato de que a base de
unicac;ao eformada por urn servic;o de datagramas de
or esforc;o extremamente simples: 0IF. Quando as
ficam pretas, como e facil de acontecer na
--ernet, a especificac;ao do IP perrnite que uma imple-
tac;ao do protocolo descarte pacotes sempre que
_ ar necessario. Hoje em dia, muitos (se nao todos) sis-
distribufdos que suportam comunicac;ao orientada
_ =uxo sao construfdos em cima da pilha de protocolos
=- Internet. La se van as especificac;6es de QoS! (Na ver-
e, 0IP fornece algum suporte de QoS, mas ele rara-
-~nte e implementado.)
Dado que 0sistema subjacente oferece apenas urn
::ervic;ode entrega de melhor esforc;o, urn sistema distri-
- ido pode tentar ocultar 0maximo possfvel afalta de
-:. .dade de servic;o. Felizmente ha varios mecanismos
que ele pode disponibilizar.
Em primeiro lugar, a situac;ao nao e realmente tao
ruim quanta a pintamos ate agora. Por exemplo, a
- ternet proporciona meios para diferenciar classes de
dos por meio dos seus servil;os diferenciados. Em
e encia, urn hospedeiro remetente pode marcar pacotes
de safda como pertencentes auma de varias classes, entre
P a c o te sa i da fo n te ~ 00B~ ~ 60
P a c o te c hega n o bu ffer ~ 0 0B~ ~
I ! I
5
elas uma classe de repasse acelerado que, basicamente,
especifica que urn pacote deve ser repassado pelo
repassador corrente com absoluta prioridade (Davie et
aI., 2002). Alem disso, ha tambem uma classe de repas-
se garantido, pela qual 0trafego e dividido em quatro
subclasses, aliadas atres modos de descartar pacotes se a
rede ficar congestionada. Por conseguinte, 0repasse
garantido define efetivamente uma faixa de prioridades
que podem ser designadas a pacotes e, por isso, perrnite
que as aplicac;6es diferenciem pacotes sensfveis ao
tempo de pacotes nao crfticos.
Alem dessas soluc;6es em nfvel de rede, urn sistema
distribufdo tambem pode ajudar a levar dados ate os
receptores. Embora em geral nao haja muitas ferramen-
tas disponfveis, uma que e particularmente util e usar
buffers para reduzir variancia de atraso. 0principio e
simples, como mostra aFigura 4 .22. Considerando certa
variancia no atraso da entrega de pacotes quando trans-
mitidos pela rede, 0receptor apenas os armazena emurn
buffer pelo tempo maximo. Isso permitira que 0receptor
passe pacotes para aaplicac;ao auma taxa regular, porque
sabe que sempre havera numero suficiente depacotes
entrando no buffer que garantira a reproduc;ao posterior
aquela taxa.
Claro que as coisas podem dar errado, como ilustra-
do pelo pacote #8 na Figura 4 .22. 0tamanho do buffer do
receptor corresponde a9 segundos de pacotes para passar
para a aplicac;ao. Infelizmente, 0pacote #8 levou 11
segundos para chegar ao receptor, quando entao 0buffer
ja estava completamente vazio. 0resultado e uma lacuna
na reproduc;ao da aplicac;ao. A unica soluc;ao e aumentar
o tamanho do buffer. A desvantagem 6bvia eque 0atraso
com que aaplicac;ao receptora pode comec;ar areproduzir
os dados contidos nos pacotes tambem aumenta.
Outras tecnicas tambem podem ser usadas. Perceber
que estamos lidando comurn servic;osubjacente demelhor
esforc;o tambem quer dizer que pacotes podem ser perdi-
dos. Para compensar essa perda na qualidade de servic;o,
precisamos aplicar tecnicas de correc;ao de erros (Perkins
et aI., 1998; Wah et aI., 2000). Requisitar que 0remetente
retransrnita urnpacote que esta faltando emgeral esta fora
de questao, portanto eprecise aplicar correl;3o de erro de
envio (forward error correction - FEC). Uma tecnica
~ 00B~ ~ ~ c u n a n a repro dU9a o
I I I
10 15 20
Tem po (s)
bem conhecida ecodificar os pacotes de saida de modo tal
que k de n pacotes recebidos seja 0suficiente para recons-
truir k pacotes corretos.
Urn problema que pode ocorrer e que urn unico
pacote contenha varios quadros de audio evideo. Por con-
sequencia, quando urn pacote e perdido, 0receptor pode-
ra realmente perceber uma grande lacuna durante arepro-
du<;aodos quadros. Esse efeito pode ser contornado, ate
certo ponto, intercalando quadros, como mostra a Figura
4 .23. Desse modo, quando urn pacote eperdido, alacuna
resultante em quadros sucessivos e distribuida ao longo
do tempo. Todavia, observe que essa abordagem requer
urn buffer de recebimento maior em compara~ao com a
nao-intercala~ao e, por isso, imp5e urn atraso de partida
mais alto para a aplica~ao receptora. Por exemplo, consi-
deremos a Figura 4 .23(b). Para repJ ;oduzir os primeiros
quatro quadros, 0receptor precisara ter quatro pacotes
entregues, em vez de so urn pacote, em compara~ao com
atransmissao nao intercalada.
4 . 4 . 3 Si nc roni zaG ao d e fl u x os
Uma questao importante em sistemas multirnfdia e
que fluxos diferentes, possivelmente na forma de urn
fluxo complexo, sao mutuamente sincronizados. A sin-
croniza~ao de fluxos trata de manter rela~5es temporais
entre fluxos. Ocorrem dois tipos de sincroniza~ao.
A forma mais simples e a sincroniza~ao entre urn
fluxo discreto de dados e urn fluxo continuo de dados.
Considere, por exemplo, uma exibi~ao de slides na Web
que foi aprimorada com audio. Cada slide etransferido do
servidor para 0cliente na forma de urn fluxo discreto de
dados. Ao mesmo tempo, 0cliente deve reproduzir urn
fluxo (ou parte dele) de audio especffico que combina
com 0slide emapresenta~ao e que tambem ebuscado no
servidor. Nesse caso, 0fluxo de audio tern de ser sincro-
nizado com a apresenta~ao dos slides.
Urn tipo mais exigente de sincroniza~ao e entre flu-
xos continuos de dados. Urn exemplo diario e a reprodu-
~ao de urnfilme na qual 0fluxo de video precisa estar sin-
cronizado com 0fluxo de audio, algo mais conhecido
como sincroniza~ao dos labios (lipsync). Urn outro exem-
plo de sincroniza~ao eareprodu~ao de urn fluxo de audio
estereo que consiste em dois subfluxos, urn para cada
canal. A reprodu~ao adequada requer que asincroniza~ao
entre os dois subfluxos seja bem exata: uma diferen~a de
mais de 20IlS pode distorcer 0efeito estereo.
A sincroniza~ao ocorre no nivel das unidades de
dados que comp5em urn fluxo. Em outras palavras, pode-
mos sincronizar dois fluxos somente entre unidades de
dados. A escolha doqueeexatamente uma unidade dedados
depende muito do nivel de abstra~ao no qual urn fluxo de
dados e visto. Para trazer as coisas para 0terreno concre-
to, considere mais uma vez urn fluxo de audio de qualida-
de de CD (de urn so canal). Em sua granularidade mais
fina, esse fluxo aparece como uma sequencia de amostras
de 16bits. Com uma frequencia de amostragem de4 4 .100
Hz, a sincroniza~ao com os outros fluxos de audio pode-
ria, em teoria, ocorrer aproximadamente a cada 23 IlS.
Ocorre que, para efeitos de estereo de alta qualidade, tal
myel de sincroniza~ao erealmente necessario.
Contudo, quando consideramos sincroniza~ao entre
urn fluxo de audio eurn fluxo de video para sincroniza~ao
dos labios (lipsync), podemos admitir uma granularidade
muito mais grosseira. Como explicamos, quadros de
video precisam ser apresentados a uma taxa de 25 Hz ou
mais. Considerando 0popular padrao NTSC de 29,97 Hz,
poderfamos agrupar amostras de audio em unidades logi-
cas que durassem tanto quanta aapresenta~ao de urn qua-
dro (33 ms). Assim, com uma frequencia de amostragem
de 4 4 .100Hz, 0tamanho de uma unidade de dados de
audio poderia ser de ate 1.4 70amostras, ou 11.760bytes
(considerando que cada amostra tenha 16 bits). Na prati-
P a c o te perdi do
En vi a do s IITJ0 0~ 110~ [2]~ IIrn [illlTIJ@]II ~ G] [ill IT ] I
P a c o tes perdi do s
I ITJ 0rn ~ 110~ [ill G] 110[2]lTIJ[illil ~ ~ @]IT ]I
ITJ 0~~rn~@]~G] 15 IT ]
Qu a dro s perdi do s
Ibl
~dades maiores, que duram 4 0, ou ate 80ms, podem
~oleradas (Steinmetz, 1996).
~ i sm o s d e s i nc roni zac ao
Agora vamos ver como a sincroniza<;ao e realmente
E preciso distinguir duas quest6es: (1) os mecanis-
- . asicos para sincronizar dois fluxos e (2) adistribui-
esses mecanismos emurn ambiente de rede.
~ecanismos de sincroniza<;ao podem ser vistos em
- -::rentes niveis de abstra<;ao. No nivel mais baixo, asin-
:=Diliza<;aoe feita explicitamente por opera<;6es sobre
Cl des de dados de fluxos simples. Esse principio e
::uado na Figura 4 .24 . Em essencia, ha urn processo
_-= -implesmente executa opera<;6es de leitura e escrita
~ Yarios fluxos simples, assegurando que essas opera-
_- - obede<;amas restri<;6es especificas de temporiza<;ao
= croniza<;ao.
Por exemplo, considere urn filme que e apresentado
o dois fluxos de entrada. 0fluxo de video contem
~ens nao comprimidas de baixa qualidade de
X~4 0pixels, cada uma codificada par urn unico byte,
_ e resulta em unidades de dados de video de 76.800
_ - cada. Suponha que as imagens sejam apresentadas a
~ 3z. ou uma imagem acada 33 ms. Adotamos apremis-
que 0fluxo de audio contem amostras de audio
~adas emunidades de 11.760bytes, cada uma corres-
: ente a 33 ms de audio, como acabamos de explicar.
- 0processo de entrada puder manipular 2,5 MB/s,
: ~mos conseguir sincroniza<;ao entre imagem e som
P ro c edi m en to qu e
Ie du a s u n i da des de
da do s de a u di o pa ra c a da
u n i da de de da do s de vi deo
simplesmente alternando entre aleitura de uma imagem e
aleitura de urn bloco de amostras de audio acada 33 ms.
A desvantagem dessa abardagem e que a aplica<;ao
fica total mente responsavel par implementar asincroniza-
<;ao, embora s6 tenha a disposi<;ao facilidades de baixo
nive!' Uma abardagem mais apropriada e oferecer auma
aplica<;ao uma interface que Ihepermita urn controle mais
facil de fluxos edispositivos. Voltando ao nosso exemplo,
suponha que a tela de video tenha uma interface de con-
trole que the permita especificar ataxa a qual as imagens
devem ser apresentadas. Alem disso, ainterface oferece a
facilidade para registrar urn manipulador definido por
usuario que e chamado toda vez que chegarem k novas
imagens. Uma interface semelhante e oferecida pelo dis-
positivo de audio. Com essas interfaces de controle, urn
desenvolvedor de aplica<;ao pode escrever urn programa
monitor simples que consiste emdois manipuladares, urn
para cada fluxo, que, em conjunto, verificam se os fluxes
de video eaudio estao suficientemente sincronizados e, se
necessario, ajustam a taxa com que sao apresentadas as
unidades de vIdeo ou audio.
Esse ultimo exemplo esta ilustrado na Figura 4 .25 ee
tipico de muitos sistemas middleware de multimidia. Na
verdade, middleware de multimidia oferece urn conjunto
de interfaces para controlar fluxos de audio e video,
incluindo interfaces para controlar dispositivos como
monitares, cameras, microfones e assim por diante. Cada
dispositivo tern suas proprias interfaces de alto nivel, entre
elas interfaces para avisar uma aplica<;ao quando ocorre
C o n tro le de m u lti m i di a
epa rte do m i ddlewa re
C a m a da de m i ddlewa re- {
Flu xo de en tra da
Apli c a qa o di z a o
m i ddlewa re 0qu e
la zer c o m Ilu xo s
de en tra da
algum evento. Esses eventos sao usados para escrever
manipuladores para sincronizar fluxos. Exemplos dessas
interfaces sao dados emBlair e Stefani (1998).
A distribuic.;ao de mecanismos de sincronizac.;ao e
uma outra questao que precisa ser examinada. Emprimei-
ro lugar, 0lado receptor de urn fluxo complexo, que con-
siste em subfluxos que requerem sincronizac.;ao, precisa
saber exatamente 0que fazer. Em outras palavras, ele
deve ter uma especijicar;iio de sincronizar;iio completa
disponivel no local. Uma pnitica comum e fomecer essa
informac.;ao de modo implicito, pela multiplexac.;ao de
diferentes fluxos em urn unico fluxo que contem todas as
unidades de dados, incluindo as de sincronizac.;ao.
Essa ultima abordagem para asincronizac.;aoe adota-
da por fluxos MPEG. Os padroes MPE G (Motion
Picture E xperts Group - grupo de especialistas em
cinema) formam urn conjunto de algoritmos para compri-
mir video e audio. Existem vanos padroes MPEG. 0
MPEG-2, por exemplo, foi projetado originalmente para
comprimir video de qualidade para transmissao broadcast
em4 a6Mbps. EmMPEG-2, urnmimero ilirnitado deflu-
xos continuos e discretos pode ser fundido em urn unico
fluxo. Cada fluxo de entrada e primeiro transformado em
urn fluxo de pacotes que transport a uma marca de tempo
baseada em urnrelogio de sistema de 90kHz. Na sequen-
cia, esses fluxos sao multiplexados em urn fluxo de pro-
grama que, entao, consiste em pacotes de comprimentos
variaveis, mas que tern algo em comum: todos eles tern a
mesma base de tempo. 0lado receptor demultiplexa 0
fluxo, usando as marcas de tempo de cada pacote como 0
mecanismo' basico para sincronizac.;aoentre fluxos.
Uma outra questao importante e se a sincronizac.;ao
deve ocorrer no lado remetente ou no lado receptor. Se 0
remetente manipular a sincronizac.;ao, pode ser possivel
fundir fluxos emurn unico fluxo comurn tipo diferente de
unidade de dados. Considere mais uma vez urn fluxo de
audio estereo que consiste em dois subfluxos, urn para
cada canal. Uma possibilidade etransferir cada fluxo inde-
pendentemente ao receptor e deixar que este sincronize as
amostras par apar. Como cada subfluxo pode estar sujeito
a atrasos diferentes, e obvio que a sincronizac.;ao pode ser
extremamente dificil. Uma abordagem mais apropriada e
fundir os dois subfluxos no remetente. 0fluxo resultante
consiste em unidades de dados compostas de pares de
amostras, uma para cada canal. Agora, basta apenas 0
receptor ler uma unidade de dados e subdividi-la em uma
amostra direita e outra esquerda. Nessa circunstancia, os
atrasos para ambos os canais sao identicos.
4 . 5 C om u ni c ac ao m u l t i c as t
Urn topico importante da comunicac.;ao em sistemas
distribuidos e 0suporte para enviar dados a varios recep-
tores, tambem conhecido como comunicac.;ao multicast.
Durante muitos anos, esse topico pertenceu ao dominio
dos protoccilos de rede, no qual foram implementadas e
avaliadas varias propostas para soluc.;oesno nivel de rede
e no nivel de transporte (J anie, 2005; Obraczka, 1998).
Uma questao importante emtodas as soluc.;oesera estabe-
lecer caminhos de comunicac.;ao para a disseminac.;ao de
informac.;oes. Na pr<itica, isso envolvia urnimenso esfon;o
de gerenciamento que, em muitos casos, exigia interven-
c.;aohumana. Ademais, como nao havia nenhuma conver-
gencia de propostas, os ISPs se mostravam relutantes em
suportar multicasting (Diot et aI., 2000).
Com 0advento da tecnologia peer-to-peer e, princi-
pal mente, do gerenciamento estruturado de sobreposic.;ao.
ficou mais facil estabelecer caminhos de comunicac.;ao.
Como as soluc.;oespeer-to-peer costumam ser disponibili-
zadas na camada de aplicac.;ao, varias tecnicas de multi-
casting de nivel de aplicac.;aoforam apresentadas. Nesta
sec.;ao,faremos urn breve estudo dessas tecnicas.
A comunicac.;aomulticast tambem pode ser consegui-
da de outros modos alem de por meio do estabelecimento
de caminhos explicitos de comunicac.;ao. Como veremos
nesta sec.;ao,a disseminac.;ao de informac.;oes baseada em
gossiping, termo explicado mais adiante, oferece modos
simples (se bem que menos eficientes) para multicasting.
4 . 5 . 1 M u l t i c as t i ng d e nl ve l d e ap l i c ac ao
A ideia basica do multicasting no nivel de aplicac.;ao
e que os nos se organizem em uma rede de sobreposic.;ao
que entao e usada para disseminar informac.;oes para seus
membros. Uma observac.;ao importante e que os repas-
sadores da rede nao estao envolvidos na associac.;ao ao
grupo. Por consequencia, as conexoes entre nos narede de
sobreposic.;ao podem cruzar vanos enlaces ffsicos e, por
isso, 0roteamento de mensagens dentro da rede de sobre-
posic.;aopode nao ser otimo em comparac.;ao com 0que
poderia ser conseguido por roteamento no nivel de rede.
Uma questao crucial de projeto e a construc.;ao da
rede de sobreposic.;ao. Em essencia, ha duas abordagens
(El-Sayed, 2003). Na primeira, os nos podem seorganizar
diretamente em uma arvore, 0que significa que ha urn
unico caminho (de sobreposic.;ao) entre cada par de nos.
Uma abordagem altemativa e os nos se organizarem em
uma rede emmalha na qual cada no tera vanos vizinhos e,
em geral, existem vanos caminhos entre cada par de nos.
A principal diferenc.;aentre as duas eque, emgeral, aulti-
ma oferece mais robustez: se uma conexao for interrompi-
da (por exemplo, porque urn no falhou), ainda assim have-
ra uma oportunidade para propagar informac.;oes sem ter
dereorganizar imediatamente toda arede de sobreposic.;ao.
Para ficar emterreno concreto, vamos considerar urn
esquema relativamente 'simples paraconstruir uma arvore
multicast emChord, que descrevemos no Capitulo 2. Esse
esquema foi proposto originalmente pelo Scribe (Castro
et aI., 2002), que e urn esquema de multicasting no nivel
de aplicac.;aoconstruido em cima do Pastry (RowstrQn e
- bel, 2001).0 ultimo tambem e urn sistema peer-to-
baseado emDHT.
uponha que urn no queira iniciar uma sessao multi-
- Com essa finalidade, ele simplesmente gera urn iden-
or multicast, digamos, mid, que eapenas uma chave
~~60bits escolhida aleatoriamente. Emseguida, ele con-
succ(mid), que e 0no responsavel por aquela chave,
_ _romove, transformando-o emraiz da arvore multicast
__ sera usada para enviar dados a nos interessados. Para
tar it arvore, urn no P simplesmente executa aopera-
OOKUP (m i d). Apos essa opera<;ao, uma mensagem
oonsulta munida da requisi<;ao para sejuntar ao grupo
ticast mid sera roteada dePate succ(mid). Como men-
os antes, 0algoritmo de roteamento em si sera
Iicado com detalhes no Capftulo 5.
Emseu caminho atearaiz, uma requisi<;aodeassocia-
- ao grupo passara por VaDOSnos. Suponha que ela che-
= primeiro ao no Q. Se Q nunca tiver visto uma requisi-
- de associa<;aopara mid antes, ele setomara urnrepas-
or para aquele grupo. Nesse ponto, P se tomara urn
- - deQ, enquanto 0ultimo continuara arepassar arequi-
- de associa<;aoate araiz. Se0no seguinte no carninho
~ raiz, digamos, R, tambem nao for ainda urn repassador,
~setomara urn eregistrara Q como seu filho, bemcomo
rinuara aenviar arequisi<;aode associa<;ao.
Por outro lado, se Q (ou R) ja for urnrepassador para
.. ele tambem registrara 0remetente anterior como seu
o (isto e, P ou Q, respectivamente), porem nao havera
- necessidade de enviar uma requisi<;ao de associa<;ao
...:..0. araiz, porque Q (ou R) ja sera urn membro da arvo-
~ do multicast.
as como P, que requisitaram explicitamente a
ocia<;ao it arvore multicast, sao, por defini<;ao, tam-
_'m repassadores. 0 resultado desse esquema e que
:0 trufmos uma arvore multicast de urn lado a outro da
:<rlede sobreposi<;ao com dois tipos de nos: repassadores
;: os que agem como ajudantes e nos que tambem saG
:-cpassadores, mas requisitaram explicitamente aassocia-
~o it arvore. Agora, 0multicasting e simples: urn no
_ yia uma mensagem multicast em dire<;ao it raiz da
.:...'ore simplesmente executando mais uma vez a opera-
- 0LOOKUP (m i d), apos a qual a mensagem pode ser
uYiada ao longo da arvore.
Observamos que essa descri<;ao de alto nfvel de mul-
. asting em Scribe nao faz justi<;aa seu projeto original.
Portanto, incentivamos 0leitor interessado a dar uma
olbada nos detalhes, que podem ser encontrados em
Castro et al. (2002).
o n stru c a o d a so brepo si c a o
Pela descri<;ao de alto nfvel que acabamos de fazer,
deve estar claro que, embora construir uma arvore nao
eja em si tao diffcil, uma vez que tenhamos organizado
o nos em sobreposi<;ao, construir uma arvore eficiente
pode ser uma histori a bem diferente. Observe que, ate
esse ponto de nossa descri<;ao, asele<;aode nos que parti-
cipam da arvore nao leva em conta nenhuma metrica de
desempenho: ela e puramente baseada no roteamento
(logico) de mensagens pela rede de sobreposi<;ao.
Para entender 0problema que temos em maos,
observe a Figura 4 .26, que mostra urn pequeno conjunto
de quatro nos organizados em uma rede' de sobreposi<;ao
simples, na qual 0no A forma araiz de uma arvore mul-
ticast. Os custos para atravessar urn enlace ffsico tambem
saG mostrados. Agora, sempre que A fizer multicast de
uma mensagem para os outros nos, vemos que a mensa-
gem atravessara cadaurn dos enlaces, <B, Rb>, <Ra, Rb>,
<Rc, Rd> e <D, Rd>, duas vezes. A rede de sobreposi<;ao
teria sido mais eficiente se nao tivessemos construfdo urn
enlace de sobreposi<;ao deB para D, mas simdeA para C.
Tal configura<;ao teria poupado a dupla travessia pelos
enlaces <Ra, Rb> e <Rc, Rd>.
Figuril 4 .26 Rela <;a o en tre en la c es em u m a rede de so brepo si <;a o
e a s ro ta s rea i s n o n i vel de rede.
A qualidade de uma arvore multicast de nfvel de
aplica<;ao em geral e medida por tres parametros de
medi<;ao diferentes: estresse de enlace, alongamento e
custo da arvore. Estresse de enlace e definido por enla-
ce econta quantas vezes urn pacote cruza 0mesmo enla-
ce (Chu et aI., 2002). Urn estresse de enlace maior do
que 1resulta do fato de que, embora em urn nfvellogi-
co urn pacote possa ser repassado ao longo de duas
conex6es diferentes, parte dessas conex6es pode, na ver-
dade, corresponder ao mesmo enlace fisico, como mos-
tramos na Figura 4 .26.
oalongamento ou penalidade de atraso relativo
(Relative Delay Penalty - RDP) mede a razao entre 0
atraso entre dois nos na sobreposi<;ao e 0atraso que esses
dois nos sofreriam na rede subjacente. Por exemplo, na
rede de sobreposi<;ao, mensagens de B a C seguem arota
B ~ Rb ~ Ra ~ Rc ~ C, com urn custo total de 59 uni-
dades. Entretanto, na rede subjacente, as mensagens
teriam sido roteadas ao longo do caminho B ~ Rb ~ Rd
~ Rc ~ C, com urn c\J sto total de 4 7 unidades, 0que
resulta em urn alongamento de 1,255. E obvio que, ao
construir a rede de sobreposi<;ao, a meta e minimizar 0
alongamento agregado ou, de modo semelhante, a RDP
media medida entre todos os pares de nos.
Por fim, 0custo da arvore eurn parametro de medi-
~ao global, relacionado com a rrtinirrtiza~ao dos custos
agregados de enlaces. POl' exemplo, se 0custo de urn
enlace for considerado como 0atraso entre dois nos
finais, otimizar 0custo da arvore se resume a achar a
spanning tree minima na qual 0tempo total para dissemi-
nar informa~6es para todos os nos e mini mo.
Para simplificar urn pouco as coisas, suponha que
urn grupo multicast tenha urn no associado e bem conhe-
cido que monitora os nos que se associaram a arvore.
Quando urn no emite uma requisi~ao de associa~ao, ele
contata esse no de encontro para obter uma lista (poten-
cialmente parcial) de membros. 0objetivo e selecionar 0
melhor membro que pode funcionar como 0pai do novo
no na arvore. Qual ele deve selecionar? Ha muitas alter-
nativas, e propostas diferentes freqyentemente seguem
solu~6es muito diferentes.
Considere, por exemplo, urngrupo multicast comuma
unica fonte. Nesse caso, asele~ao do melhor no eobvia: ele
deve ser a fonte porque, com isso, podemos estar seguros
de que 0alongamento sera igual a 1. Contudo, sefizermos
isso, introduziriamos uma topologia emestrela comafonte
no meio. Embora simples, nao e dificil imaginar que seria
facil a fonte ficar sobrecarregada. Em outras palavras, a
sele~ao de urn no geralmente sera restringida de modo tal
que somente poderao ser escolhidos os nos que tiverem k
ou menos vizinhos, sendo k urnparametro deprojeto. Essa
restri~ao complica seriamente 0algoritmo de estabeleci-
mento de arvore, porque uma boa solu~ao pode exigir que
parte da arvore existente seja reconfigurada.
Tan et al. (2003) apresentam uma visao geral eavalia-
~ao extensa de varias solu~6es para esse problema. Como
ilustra~ao, vamos exarrtinar mais de perto uma fann1ia
espedfica, conhecida como arvores de troca (Helder e
J amin, 2002). A ideia basica e simples. Suponha que ja
temos uma arvore multicast com uma unica fonte como
raiz. Nessa arvore, urn no P pode trocar de pais descartan-
do 0enlace com seu pai atual emfavor de urn enlace com
urn outro no. As unicas restri~6es impostas a troca deenla-
ces eque 0novo pai nunca pode ser urn membro da subar-
yorecomraiz emP - porque issorepartiria aarvore ecria-
ria urn la~o isolado - e que 0novo pai nao tera muitos
filhos imediatos. Essa ultima restri~ao e necessaria para
lirrtitar acarga de repasse de mensagens de urn unico no.
Ha diferentes criterios para decidir a troca de pais.
Urn simples e otimizar a rota ate a fonte, minimizando
efetivamente 0atraso quando uma mensagem deve ser
propagada pOl' multicast. Com essa finalidade, cada no
recebe informa~6es periodicas sobre outros nos (logo
adiante explicaremos urn modo espedfico para fazer isso.
Nesse ponto, 0no pode avaliar se urn outro no seria urn
pai melhor em termos do atraso ao longo da rota ate a
fonte e, caso seja, iniciar uma troca.
Urn outro crite110poderia ser se 0atraso ate outro pai
potencial for menor do que 0atraso ate0pai atual. Se todo
no adotar esse criterio, entao os atrasos agregados da arvore
resultante seriam idealmente rninimos. Em outras palavras.
esse e urn exemplo de otirrtiza~ao do custo da arvore como
explicamos antes. Contudo, seria preciso mais informa~ao
para construir uma arvore dessas, mas averdade e que esse
esquema simples e uma heurlstica razoavel que resulta em
uma boa aproxima~ao de uma spanning tree minima.
Como exemplo, considere 0caso em que urn no P
recebe informa~6es sobre os vizinhos de seu pai. Note
que os vizinhos consistem no avo de P junto com os
outros irmaos gerados pelo pai de P. Entao, 0no P pode
avaliar os atrasos para cada urn desses nos e, na sequen-
cia, escolher como seu novo pai aquele que tenha 0
menor atraso, digamos, Q. Com essa finalidade, ele
envia uma requisi~ao de troca a Q. Para evitar a forma-
~ao de la~os por causa de requisi~6es de troca concor-
rentes, urn no que tenha uma requisi~ao de troca em
aberto simplesmente se recusara a processar quaisquer
requisi~6es que cheguem. Na verdade, isso resulta em
uma situa~ao em que so trocas completamente indepen-
dentes podem ser executadas simultaneamente. AMmdo
mais, P fornecera a Q informa~6es suficientespara per-
mitir que 0ultimo conclua que ambos os nos tern 0
mesmo pai, ou que Q e 0avo.
Urn problema importante que ainda nao atacamos e
afalha do no. No caso de arvores de troca, eproposta uma
solu~ao simples: sempre que urn no percebel' que seu pai
falhou, ele simplesmente se liga a raiz. Nesse ponto, 0
protocolo de otimiza~ao pode continuar como sempre e, a
certa altura, colocara 0no em urn born ponto na arvore
multicast. Experimentos descritos em Helder e J amin
(2002) mostram que a arvore resultante e, de fato, proxi-
ma a uma spanning tree minima.
4 . 5 . 2 D i s s e m i nac ao d e d ad os b as e ad a e m g os s i p i ng
Uma tecnica cada vez mais importante para dissemi-
nar informa~6es e confiar em urn comportamento epide-
mico. Observando como enferrnidades se espalham entre
as pessoas, ha muito tempo pesquisadores investigam se
seria possivel desenvolver tecnicas simples para espalhar
informa~6es em sistemas distribuidos de escala muito
grande. 0objetivo principal dos protocolos epidemicos e
propagar informa~6es rapidamente entre urn grande con-
junto de nos usando somente informa~6es locais. Em
outras palavras, nao ha nenhum componente central que
coordena adissemina~ao de informa~6es.
Para explicar os principios gerais desses algoritmos,
adotamos como prerrtissa que todas as atualiza~6es para urn
item de dado especifico sao iniciadas em urn unico no.
Desse modo, simplesment~ evitamos conflitos de escrita. A
apresenta~ao que fazemos a seguir e baseada no classico
artigo deDemers et al. (1987) sobre algoritrnos epidemicos.
Uma visao geral recente de disserrtina~ao epiderrtica de
informa~6es pode ser encontrada emEugster et al. (2004).
Como 0nome sugere, algoritmos epidemic os sao
- dos na teoria das epidemias, que estuda a propaga-
_~ de doen<;asinfecciosas. No caso de sistemas distribui-
~- de grande escala, em vez de propagar doen<;as, eles
: pagam informa<;6es. A pesquisa sobre epidemias para
mas distribuidos tambem visa aurn objetivo comple-
ente diferente: enquanto as organiza<;6es de saude
- -00maximo possivel para impedir que doen<;asinfec-
se propaguem por grandes grupos de pessoas, os
: ~etistas de algoritmos epidemicos para sistemas distri-
'dos tentarao 'infectar' todos os nos comas novas infor-
.6es 0mais rapidamente possive!.
Usando a terminologia das epidemias, urn no que e
: e de urn sistema distribuido e denominado infectado
~ ontiver dados que esta dispostoa espalhar para os
o nos. Urn no que ainda nao tenha visto esses dados
= enominado suscetivel. Por fim, urn no atualizado que
- esta disposto ou capacitado para propagar os dados e
ominado removido. Observe que consideramos que
emos distinguir dados novos de dados antigos, por
emplo, porque receberam uma marca de tempo ou estao
outra versao. Sob essa luz, diz-se tambem que nos
_~pagam atualiza<;6es.
Urn modelo popular depropaga<;ao e0da antientro-
__ esse modelo, urn no P escolhe aleatoriamente urn
no Q e, na sequencia, troca atualiza<;6es com Q. Ha
" abordagens para a troca de atualiza<;6es:
1. P so envia suas proprias atualiza<;6es a Q
2. P so recebe novas atualiza<;6es de Q
3. P e Q enviam atualiza<;6es urn ao outro, isto e,
uma abordagem enviar-receber
Quando setrata depropagar atualiza<;6es rapidamen-
apenas enviar atualiza<;6es se revela uma ma ideia.
rnitivamente, isso pode ser entendido como segue. Em
~eiro lugar, note que, emuma abordagem enviar pura,
aliza<;6es podem ser propagadas somente por nos
ectados. Contudo, se muitos nos forem infectados, a
probabilidade de cada urn selecionar urn no suscetivel e
relativamente pequena. Por consequencia, a probabilida-
de maior e que determinado no permane<;a suscetivel por
urn longo periodo simplesmente porque nao foi seleciona-
do por urn no infectado.
Por compara<;ao, a abordagem baseada no recebi-
mento funciona muito melhor quando muitos nos sao
infectados. Nesse caso, apropaga<;ao de atualiza<;6es e,
em essencia, disparada por nos suscetfveis. Sao gran-
des as chances de que tal no contatara urn infectado
para, na sequencia, buscar as atualiza<;6es e tambem
tornar-se infectado.
Pode-se demonstrar que, seso urnno for infectado, as
atualiza<;6es sepropagarao rapidamente para todos os nos
usando qualquer uma das formas de anti entropia, embora
enviar-receber continue sendo amelhor estrategia (J elasity
et aI., 2005a). Definimos que uma rodada abrange urn
periodo no qual todo no tera tornado, no minimo uma vez,
a iniciativa de trocar atualiza<;6es com urn outro no esco-
lhido aleatoriamente. Portanto, pode-se mostrar que 0
numero de rodadas para propagar uma unica atualiza<;ao
para todos os nos leva O(log(N)) rodadas, onde N e 0
numero de nos no sistema. Isso indica, de fato, que propa-
gar atualiza<;6es erapido; porem, acima detudo, escalavel.
Uma variante especifica dessa abordagem eapropa-
gal;ao de boato, ou apenas gossiping. Funciona da
seguinte maneira: se 0no P acabou de ser atualizado com
o item de dado x, ele contata urn outro no arbitrario Q e
tenta enviar a atualiza<;ao a Q. Contudo, epossivel que Q
ja tenha sido atualizado por urn outro no. Nesse caso, P
pode perder 0interesse emlevar adiante apropaga<;ao da
atualiza<;ao, digamos, com aprobabilidade 11k. Em outras
palavras, ele se torna removido.
Gossiping e completamente analogo a vida real.
Quando Bob tern alguma noticia quente que quer espa-
lhar, ele pode telefonar para sua amiga Alice e the contar
tudo. Alice, como Bob, ficara muito animada e tambem
espalhara 0boato para suas amigas. Contudo, ela ficara
desapontada setelefonar para urn amigo, digamos Chuck,
k - -
2 3 4 5 6 7 8 9 10 11 12 13 14 15
- 2,5
- 5,0
- 7,5
- 10,0
In (s)
t
- 12,5
- 15,0
Fi gu ra 4.27 Rela c ;:a o en tre a fra c ;:a o 5 de n 6s i gn o ra n tes da s a tu a li za c ;:o ese 0pa ra m etro k em go ssi pi n g pu ro .
o gra fi c o m o stra In(sjcomo u m a fu n c ;:a o de k.
e este lhe disser que anotfcia ja chegou aele. A probabi-
lidade e que Alice nao telefonara mais, porque de que
. adiantaria, se eles ja sabem?
Gossiping mostrou ser urn modo excelente de espa-
lhar notfcias rapidamente. Contudo, ele nao pode garantir
que todos os nos realmente serao atualizados (Demers et
aI., 1987). Pode-se mostrar que, quando ha urn grande
numero de nos que participam da epidemia, a frac;aos de
nos que continuam ignorantes em relac;ao a uma atualiza-
c;ao,isto e, que permanecem suscetfveis, satisfaz aequac;ao:
A Figura 4 .27 mostra In(s) como uma func;ao de k.
Por exemplo, se k = 4 , In(s) = -4 ,97, de modo que s e
menor do que 0,007, 0que significa qu~menos de 0,7%
dos nos permanece suscetfve1. Ainda assim, sao necessa-
rias medidas especiais para garantir que esses nos tam-
bem serao atualizados. Combinar antientropia com gos-
siping resolvera 0problema.
Uma das principais vantagens de algoritmos epide-
micos e sua escalabilidade devido ao fato de que 0nume-
ro de sincronizac;6es entre processos e relativamente
pequeno em comparac;ao com outros metodos de propa-
gac;ao. Para sistemas de longa distancia, Lin e Marzullo
(1999) mostram que faz sentido levar emconta a topolo-
gia da rede propriamente dita para conseguir melhores
resultados. Na abordagem desses autores, nos que estao
conectados a apenas alguns outros nos sao contatados
com uma probabilidade relativamente alta. A premissa
subjacente e que tais nos formam uma ponte com outras
partes remotas darede; por conseguinte, devem ser conta-
tados tao logo seja possfve1. Essa abordagem edenomina-
da gossiping direcional e tern diferentes variantes.
Esse problema refere-se a uma importante premissa
adotada pela maioria das soluc;6es epidemic as, a saber,
que urn no pode selecionar aleatoriamente qualquer outro
no com 0qual fazer gossiping. Isso implica que, emprin-
cipio, 0conjunto completo de nos deve ser conhecido por
cada membro. Em urn sistema de grande porte, essa pre-
missa podera nunca valer.
Felizmente, nao ha nenhuma necessidade de ter tal
lista. Como explicamos no Capftulo 2, manter uma visao
parcial que e atualizada mais ou menos continuamente
organizara 0conjunto de nos emurn grafico aleatorio. Se
a visao parcial de cada no for atualizada periodicamente,
a selec;ao aleatoria deixara de ser urn problema.
R e m oc ao d e d ad os
Algoritrnos epidemicos sao extremamente bons para
propagar atualizac;6es. Contudo, eles tern urnestranho efei-
to colateral: propagar aremo~ aodeurnitemdedado ediff-
ci1. A essencia do problema encontra-se no fato de que a
remoc;ao de urn item de dado destroi todas as informac;6es
naquele item. Por consequencia, quando urn item de dado
e simplesmente removido de urn no, a certa altura esse no
recebera capias velhas do item de dado e as interpretara
como atualizac;6es de algo que ele nao tinha antes.
ojeito e gravar a remoc;ao de urn item de dados
como apenas mais uma atualizac;ao e manter urn registro
dessa remoc;ao. Desse modo, capias vel has nao serao
interpretadas como algo novo, mas tratadas como meras
vers6es que foram atualizadas por uma operac;ao deremo-
c;ao. 0registro de uma remoc;ao e feito pela propagac;ao
decertificados de 6bito.
Claro que 0problema dos certificados de abita e
que, a certa altura, sera preciso desfazer-se deles, senao
cada no acumulara gradativamente urn enorme banco de
dados local de informac;6es historicas sobre itens dedados
removidos que, quanta ao mais, nao serao usados.
Demers et a1. (1987) prop6em usar 0que denQminam cer-
tificados deobito dormentes. Cada certificado recebe uma
marca de tempo quando ecriado. Se adotarmos como pre-
missa que as atualizac;6es se propagam para todos os nos
dentro de urn perfodo fmito de tempo conhecido, entao
certificados de obito podem ser removidos apos 0termi-
no desse tempo maximo de propagac;ao.
Contudo, para dar garantia certa de que as remoc;6es
serao realmente propagadas para todos os nos, alguns
poucos nos mantern certificados de obito dormentes que
nunca sao jogados fora. Suponha que P tenha urn certifi-
cado desses para 0item de dado x. Se, por algum acaso,
uma atualizac;ao obsoleta de x chegar aP, P reagira ape-
nas propagando novamente 0certificado de obito para x.
R p l i c ac oe s
Para encerrar, vamos examinar algumas aplicac;6es
interessantes de protocolos epidemicos. J a mencionamos
apropagac;ao de atualizac;6es, que talvez seja a aplicac;ao
mais amplamente conhecida. No Capitulo 2 tambem dis-
cutimos como fornecer informac;6es sobre 0posiciona-
mento de nos pode ajudar na construc;ao de topologias
especificas. Sob amesma luz, 0gossiping pode ser usado
para descobrir nos que tenham alguns enlaces desafdapara
redes de longa distancia para, na sequencia, aplicar gos-
siping direcional, como ja mencionamos.
Uma outra area de aplicac;ao interessante e simples-
mente colher ou, na verdade, agregar informac;6es
(J elasity et aI., 2005b). Considere a seguinte troca de
informac;6es. Cada no i escolhe inicialmente urn numero
arbitrario, digamos, Xi' Quando 0no i contata 0noj, cada
urn deles atualiza seu valor como:
E obvio que, apos essa .troca, ambos, i ej, terao 0
mesmo valor. Na verdade, nao e diffcil perceber que, a
certa altura, todos os nos terao 0mesmo valor, ou seja, a
media de todos os valores iniciais. Mais uma vez, avelo-
cidade de propagac;ao e exponencia1.
Qual e a utilidade de calcular a media? Considere a
>- 0em que todos os nos i ajustaram Xi para zero,
_ 0Xl> que 0ajustou para I:
{
1 5e i = 1
Xi f- 1 5e i >1
e houver N nos, entao, a certa altura, cada no cal-
, a media, que e lIN. Por conseqtiencia, todo no i
- - ~ e. timar 0tamanho do sistema como se fosse 1lxi'
- _-sa informa<;ao ja basta para ser usada afim de ajus-
cinamicamente varios parametros. Por exemplo, 0
o da visao parcial - isto e, 0numero de vizinhos
da no monitora - deve ser dependente do numero
de nos participantes. Conhecer esse numero permi-
..:..ue urn no ajuste dinamicamente 0tamanho de sua
- parcial. Na realidade, isso pode'ser visto como uma
_ 'edade de autogerenciamento.
- Calcular a media pode ser dificil quando nos entram
= - "'ill do sistema periodicamente. Vma solu<;aopratica
~ _ e. seproblema eintroduzir epocas. Considerando que
- ' I ejaestavel, elesimplesmente inicia uma novaepoca
~'"ezem quando. Quando urn no i vir uma nova epo-
__ ~la primeira vez, ele reajustara sua propria variavel Xi
_ zero e come<;aa calcular amedia novamente.
Claro que tambem podem ser calculados outros
cltados. Por exemplo, emvez deurn no fixo (Xl) iniciar
.::aI ulo da media, podemos facilmente escolher urn no
~-orio como segue. Todo no i ajusta Xi inicialmente
_~ urn numero aleatorio pertencente ao mesmo interva-
digamos, [0,1], e tambem 0armazena permanente-
tecomo mi' Quando ocorre uma troca entre os nos i e
da urn muda seu valor para:
Cada no i para 0qual mi <Xi perdera a competi<;ao
ser 0iniciador do calculo da media. No final, havera
-' urn vencedor. Claro que, embora seja facil concluir que
no perdeu, emuito mais diffcil decidir que ele ganhou,
: .-quecontinua incerto se todos os resultados entraram.
_-" olu<;aopara esse problema e ser otimista: urn no sem-
:;;eentende que ele e 0vencedor ate que se prove 0con-
~o. Nesse ponto, ele apenas reajusta para zero avaria-
'el que esta usando a fim de calcular a media. Observe
e, a essa altura, varios calculos diferentes (em nosso
;xemplo calcular urn maximo e calcular uma media)
;xxlem estar em execu<;aoconcorrentemente.
Dispor defacilidades poderosas eflexiveis para comu-
mca<;aoentre processos e essencial para qualquer sistema
. tribufdo. Emaplica<;6estradicionais derede, acomunica-
<;aocostuma ser baseada nas primitivas de troca de mensa-
gens de baixo nfvel oferecidas pela camada de transporte.
Vma questao importante em sistemas middleware e ofere-
cer urn nfvel mais alto de abstra<;aoque facilitara expressar
comunica<;ao entre processos mais do que 0suporte ofere-
cido pela interface comacamada de transporte.
Vma das abstra<;6es mais amplamente utilizadas e a
chamada de procedimento remoto (RPC). A essencia de
uma RPC e que urn servi<;oe implementado por meio de
urn procedimento cujo corpo eexecutado emurn servidor.
o cliente recebe apenas a assinatura do procedimento,
isto e, 0nome do procedimento junto com seus parame-
tros. Quando 0cliente chama 0procedimento, a imple-
menta<;ao do lado do cliente, denominada apendice, fica
encarregada de embrulhar os val ores dos parametros em
uma mensagem e envia-Ia ao servidor. Este chama 0pro-
cedimento propriamente dito eretorna os resultados, mais
uma vez emuma mensagem. 0apendice do cliente extrai
os valores do resultado da mensagem de retorno eapassa
de volta a aplica<;ao cliente chamador.
RPCs oferecern facilidades de comunica<;ao sfncro-
na, pelas quais urn cliente ebloqueado ate que 0servidor
tenha enviado uma resposta. Embora existam varia<;6esde
qualquer urn dos mecanismos pelos quais esse modelo
sfncrono estrito e amenizado, ocorre que os modelos de
uso geral de alto nfvel orientados a mensagens muitas
vezes saDmais convenientes .
Emmodelos orientados amensagem, asquest6es giram
emtorno de seuma comunica<;aoe ou nao persistente e se
uma comunica<;aoeou nao slncrona. A essencia dacomuni-
ca<;aopersistente e que uma mensagem apresentada para
transrnissao earmazenada pelo sistema decomunica<;aopelo
tempo que for necessario para entrega-Ia. Em outras pala-
vras, nem0remetente nem0receptor precisam estar liga~os
efuncionando para que atransrnissao da mensagem ocorra.
Emcomunica<;aotransiente, nenhuma facilidade dearmaze-
namento eoferecida, demodo que 0receptor deveestar pre-
parado para aceitar amensagem quando ela for enviada.
Emcomunica<;ao assfncrona, 0remetente ternperrnis-
saDde continuar irnediatamente apos amensagem ter sido
apresentada para transrnissao, possivelmente antes mesmo
de ela ter sido enviada. Emcomunica<;ao sfncrona, 0reme-
tente e bloqueado no rnfnimo ate que uma mensagem seja
recebida. Alternativamente, 0remetente pode ser bloquea-
do ate ocorrer aentrega da mensagem ou mesmo ateque 0
receptor tenha respondido, como acontece com as RPCs.
Modelos de rniddleware orientado a mensagem em
geral oferecern comunica<;ao assfncrona persistente e saD
usados onde RPCs nao saD adequadas. Esses sistemas
costumam ser utilizados para ajudar na integra<;ao de con-
juntos de bancos de dado.s (amplamente dispersos) a sis-
temas de informa<;6es de grande escala. Entre outras apli-
ca<;6esestao e-mail efluxo de trabalho.
Vma forma muito diferente de comunica<;ao e a
comunica<;ao por fluxos, naqual aquestao eseduas men-
sagens sucessivas tern ou nao uma rela~ao temporal. Em
fluxos continuos dedados, urn atraso fim-a-fim maximo e
especificado para cada mensagem. Alem disso, tambem e
requerido que as mensagens sejam enviadas sujeitas aurn
atraso fim-a-fim minimo. Exemplos tipicos desses fluxos
continuos de dados saG fluxos de audio evideo. Em geral,
ediffcil especificar e implementar quais sao, exatamente,
as rela~6es temporais ou 0que seespera do subsistema de
comunica~ao subjacente em termos de qualidade de ser-
vi~o. Urn fator complicador e0papel da variancia de atra-
so. Ainda que 0desempenho medio seja aceitavel, varia-
~6es substanciais no tempo de entrega podem resultar em
desempenho inaceitavel.
Por fim, uma importante classe de protocolos de
comunica~ao emsistemas distribuidos e0multicasting. A
ideia basica e disseminar informa~6e,s de urn remetente
para varios receptores. Discutimos duas abordagens dife-
rentes. Na primeira, 0multicasting pode ser conseguido
com 0estabelecimento de uma arvore entre 0remetente e
os receptores. Considerando que agora ja entendemos
bem como os nos se auto-organizam emsistemas peer-to-
peer, tambem apareceram solu~6es para estabelecer arvo-
res dinamicamente de modo descentralizado.
Uma outra classe importante de solu~6es de dissemi-
na~ao utiliza protocolos epidemicos. Esses protocolos
mostraram ser muito simples, porem extremamente
robustos. Exceto a simples propaga~ao de mensagens,
protocolos epidemicos tambem podem ser utilizados com
eficiencia para agregar informa~6es por toda a extensao
de urn sistema distribuido de grande porte.
1. Em muitos protocolos de camadas, cada camada tern
seu proprio cabe~alho. Par certo seria mais eficiente
ter urn unico cabe~alho a frente de cada mensagem
que contivesse todos os controles do que ter todos
esses cabe~alhos separados. Por que isso nao e feito?
2. Por que servi~os de comunica~ao denivel de transpor-
te frequentemente saG inadequados para construir
aplica~6es distribuidas?
3. Urn servi~o multicast confiavel permite que urn reme-
tente passe mensagens confiaveis para urn conjunto de
receptores. 0melhor lugar para esse servi~o e uma
camada de middleware, ou ele deveria ser parte de
uma camada de nivel mais baixo?
4 . Considere urnprocedimento incr comdois parametros
inteiros. 0procedimento adiciona urn acada parame-
tro. Agora suponha que ele seja chamado com a
mesma variavel duas vezes, por exemplo, como incr
(i, i). Se i for inicialmente 0, qual valor ele tera depois
sefor utilizada chamada por referencia? E sefor utili-
zada chamada copiar/restaurar?
5. C tern uma constru~ao denominada Union, na qual urn
campo de urn registro, denominado Struct emC, pode
conter qualquer uma de diversas altemativas. Em
tempo de execu~ao, nao hi! nenhum modo garantido
de dizer qual delas esta naquele campo. Essa caracte-
rfstica de C tern quaisquer implica~6es para a chama-
da de procedimento remoto? Explique sua resposta.
6. Urn modo de manipular conversao de parametro em
sistemas RPC e fazer com que cada maquina envie
parametros emsua representa~ao nativa, e aoutra fa~a
atradu~ao, se necessario. 0sistema nativo poderia ser
indicado por urn codigo no primeiro byte. Contudo,
uma vez que localizar 0primeiro byte na primeira
palavra eexatamente 0problema, isso pode funcionar?
7. Considere que urn cliente chama uma RPC assincrona
para urn servidor e, na sequencia, espera ate que 0ser-
vidor retome urn resultado usando uma outra RPC
assincrona. Essa abordagem e 0mesmo que deixar 0
cliente executar uma RPC normal?
B. Em vez de deixar que urn servidor registre asi mesmo
em urn daemon como em DCE, poderfamos tambem
preferir sempre designar a ele a mesma porta.
Portanto, essa porta pode ser usada em referencias a
objetos no espa~o de endere~o do servidor. Qual e a
principal desvantagem desse esquema?
9. Seria util fazer tambem uma distin~ao entre RPCs
dinamicas e estaticas?
10. Descreva como ocorre a comunica~ao sem conexao
entre urn cliente e urn servidor usando a interface
Sockets.
11. Explique a diferen~a entre as primitivas MP I_bsen d
e M P I i sen d emMPI.
12. Suponha que voce so possa usar primitivas de comu-
nica~ao assincronas transientes, entre elas apenas uma
primitiva assincrona receive. Como voce implementa-
ria primitivas para comunica~ao transiente sfncrona?
13. Suponha que voce so possa utilizar primitivas de
comunica~ao transiente sincrona. Como voce imple-
mentaria primitivas para comunica~ao transiente
assfncrona?
14 . Faz sentido implementar comunica~ao persistente
assincrona por meio de RPCs?
15. No texto, afirmamos que, para iniciar automatic amen-
teurn processo afimde buscar mensagens de uma fila
de entrada, frequentemente e usado urn daemon que
monitora a fila de entrada. De uma implementa~ao
altemativa que nao utilize urn daemon.
16. Tabelas de roteamento no WebSphere da IBM e em
muitos outros sistemas de enfileiramento de mensa-
gens saG configuradas manualmente. Descreva urn
modo simples de fazer isso automaticamente.
IT! comunica9ao persistente, urn receptor geral-
Ie tern seu proprio buffer local no qual mensa-
;=- podem ser armazenadas quando 0receptor nao
__ - 'er em execu9ao. Para criar tal buffer, talvez seja
. 0especificar seu tamanho. Cite urn argumento
_ :... 'or e outro contra a especifica9ao do tamanho.
~ lique par que a comunica~ao transiente sfncrona
problemas inerentes de escalabilidade e como
~'_- podem ser resolvidos.
...x: urn exemplo em que multicasting tambem e util
fluxos discretos de dados.
nba que temperaturas medidas em uma rede de
~ ores nao recebam marcas de tempo pelo sensor,
ejam enviadas imediatamente ao operador. Isso
-- -asuficiente para garantir apenas urn atraso fim-a-
maximo?
o voce poderia garantir urn atraso maximo fim-a-
quando urn conjunto de computadores estiver
'zado emurn ane! (1ogico ou ffsico)?
22. Como voce poderia garantir urn atraso fim-a-fim mfni-
mo quando urn conjunto de computadores estiver
organizado emurn anel (1ogico ou ffsico)?
23. Apesar de 0multicasting ser tecnicamente viavel, ha
pouqufssimo suporte para disponibiliza-Io na Internet.
A resposta para esse problema deve ser buscada em
puros e simples modelos de negocios: na realidade,
ninguem sabe como ganhar dinheiro com 0multicas-
ting. Voce pode inventar urn sistema?
24 . Normalmente, arvores multicast de nfvel de aplica9ao
sao otimizadas em rela9ao ao alongamento, que e
medido em termos de atraso ou contagens de saltos.
De urn exemplo em que essa metrica poderia resultar
em arvores muito ruins.
25. Quando se trata de procurar arquivos em urn sistema
peer-to-peer nao estruturado, pode ser util restringir a
busca a nos que tenham arquivos semelhantes aos
seus. Explique como 0gossiping pode ajuda-Io a
achar esses nos.