Sistemas Distribudos Algumas questes e respectivas respostas (Cap IV - aula de 29Set08)

1. P: Nas arquitecturas de protocolos baseadas em camadas, cada camada tem o seu prprio
cabealho. Seguramente que, para certas condies, seria mais eficiente ter apenas um simples cabealho frente de cada mensagem, com todo o controlo necessrio, do que todos esses cabealhos separados por camadas. Porque ser que isso no foi feito ? R:Cada camada deve ser independente das outras. A unidade de dados (data unit) passados da camada N +1 para a camada N contm ambos (o cabealho e os dados), mas a camada N no pode distinguir o que o qu. Tendo um nico cabealho (grande) que todas as camadas poderiam ler e escrever, destruiria esta transparncia e tornaria as alteraes no protocolo de uma camada visvel a todas as outras camadas. Para alm disso e no menos importante, eliminaria a independncia da funcionalidade especfica de cada camada, podendo provocar implicaes e resultados colaterais potencialmente desastrosos e seguramente caros, quando se alterasse uma delas. Ora tudo isto indesejvel.

2. P: Assuma que um cliente solicita um RPC assncrono para um Server e, subsequentemente,

espera at que o Server retorne um resultado, utilizando outro RPC assncrono. Esta aproximao a mesma como se o Cliente executasse um RPC normal ? Como seria se substitussemos os RPCs assncronos por 2 RPCs assncronos ? R: No, isto no o mesmo. Um RPC assncrono liberta o cliente aps a recepo da confirmao de que o Server recebeu o pedido, e no obriga a ficar bloqueado at receber o resultado final da operao realizada pelo Server no caso de um RPC normal. Claro que, mesmo no caso do RPC assncrono, um cliente embora liberto, pode fazer o que quiser, nomeadamente esperar pela resposta final, como no caso mas, ao contrrio de um RPC normal, ele j recebeu entretanto uma confirmao de que o Server recebeu o seu pedido. Do mesmo modo, o Servidor tambm receber a confirmao de que a sua resposta foi entregue ao cliente. No caso de 2 RPCs assncronos, eles poderiam fazer o mesmo mas, como se viu, a modalidade one-way RPC, invocada especialmente pelo Servidor, no obriga a confirmao pelo cliente logo, s se poderia considerar totalmente seguro, admitindo que a fiabilidade das comunicaes est garantida, o que no geralmente o caso.

3. P: Faz sentido implementar comunicao persistente assncrona por meio de RPCs ?

R: Sim, mas apenas numa base n-a-n, no qual um processo que gere uma fila de espera, passa uma mensagem ao prximo gestor de fila, por meio de um RPC. Efectivamente, o servio oferecido por um gestor de fila de espera a outro, o armazenamento de uma mensagem. Ao gestor de fila de espera chamante, oferecida uma implementao de interface (proxy) para a fila remota, enquanto receber, possivelmente, um feedback do estado de sucesso ou falha de cada operao. Deste modo, at mesmo os gestores de filas de espera vem apenas filas e mais nenhuma comunicao adicional logo grande transparncia, independncia e flexibilidade.

4. P: Com comunicao persistente, um receptor geralmente tem o seu prprio buffer local,
onde as mensagens so armazenadas quando o receptor no est em execuo. Para criar tal buffer, pode ser necessrio especificar o seu tamanho. D um argumento a favor e outra contra, relativamente a essa especificao ? R: Tendo o utilizador de especificar o tamanho do buffer local, torna a sua implementao e gesto mais fcil. Porm, se o buffer enche, podem ser perdidas mensagens. A alternativa ter o sistema de comunicao a gerir o tamanho do buffer, comeando com algum

tamanho por defeito, e ento, ir crescendo ou encolhendo conforme as necessidades. Este mtodo reduz a hiptese de ter que descartar mensagens por falta de espao, mas requer muito mais trabalho e complexidade na gesto do sistema.

5. P: Explique porque que uma comunicao transitria sncrona, pode ter inerentemente
problemas de escalabilidade e como que isso poder ser resolvido ? R: O problema principal aqui, tem a ver com a limitao da escalabilidade do ponto de vista geogrfico. Porque a comunicao sncrona, requer que o chamante fique bloqueado at que a sua mensagem seja recebida pelo destinatrio, isso pode levar muito tempo, antes que ele possa continuar o seu trabalho, especialmente quando o destinatrio estiver muito longe. O nico modo de resolver este problema, desenhar a aplicao de cliente por forma a que possa continuar a realizar outros trabalhos, enquanto a comunicao se realiza, estabelecendo no fundo uma forma de comunicao assncrona, em vez de sncrona.

6. P: Suponha que numa das redes de sensores que estudou, as medies de temperatura no so
registadas e carimbadas pelo sensor, mas so imediatamente enviadas para o operador. Seria suficiente garantir apenas um atraso fim-a-fim mximo ? R: Realmente no, se assumirmos que o operador ainda precisaria saber quando a medio aconteceu. Neste caso, pode ser aplicado um carimbo quando a medio recebida, mas isto no ser suficiente pois significaria que ns tambm deveramos ter garantias, para atrasos fim-a-fim mnimos.
Dario Carreira 6Out08