7/31/2019 Per e Resp SDs 29Set08

1/2

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 prpriocabealho. Seguramente que, para certas condies, seria mais eficiente ter apenas um

simples cabealho frente de cada mensagem, com todo o controlo necessrio, do quetodos 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 dacamada N +1 para a camada N contm ambos (o cabealho e os dados), mas a camada Nno pode distinguir o que o qu. Tendo um nico cabealho (grande) que todas ascamadas 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 menosimportante, eliminaria a independncia da funcionalidade especfica de cada camada,

podendo provocar implicaes e resultados colaterais potencialmente desastrosos eseguramente 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. Estaaproximao 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 daconfirmao de que o Server recebeu o pedido, e no obriga a ficar bloqueado at receber oresultado 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 RPCnormal, 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 foientregue ao cliente.

No caso de 2 RPCs assncronos, eles poderiam fazer o mesmo mas, como se viu, amodalidade one-way RPC, invocada especialmente pelo Servidor, no obriga aconfirmao pelo cliente logo, s se poderia considerar totalmente seguro, admitindo que afiabilidade 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, oservio 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 oufalha de cada operao. Deste modo, at mesmo os gestores de filas de espera vemapenas 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 criartal buffer, pode ser necessrio especificar o seu tamanho. D um argumento a favor eoutra contra, relativamente a essa especificao ?

R: Tendo o utilizador de especificar o tamanho do buffer local, torna a sua implementao egesto 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

7/31/2019 Per e Resp SDs 29Set08

2/2

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

5. P: Explique porque que uma comunicao transitria sncrona, pode ter inerentementeproblemas 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 vistageogrfico. Porque a comunicao sncrona, requer que o chamante fique bloqueado atque a sua mensagem seja recebida pelo destinatrio, isso pode levar muito tempo, antes queele possa continuar o seu trabalho, especialmente quando o destinatrio estiver muitolonge. O nico modo de resolver este problema, desenhar a aplicao de cliente porforma 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 soregistadas 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 medioaconteceu. Neste caso, pode ser aplicado um carimbo quando a medio recebida, masisto no ser suficiente pois significaria que ns tambm deveramos ter garantias, paraatrasos fim-a-fim mnimos.

Dario Carreira

6Out08