Você está na página 1de 3

1. EXEMPLO DE protocolo de solicitação / resposta no mundo real.

R: A Conversa pode ser um protocolo Resquest/Reply, o emissor que sera o client e o


receptro que sera o servidor que vai dar a resposta;

2. Um Resquest/Reply é síncrona quando o processo do cliente é bloqueado até que a


resposta chegue do servidor.

request-reply assíncrona é uma alternativa que pode ser útil em situações em que os
clientes podem recuperar respostas posteriormente.

3. Um RequestID é necessario quando temos um request/reply sincrona;

4. Elementos de Um Mensagem

Uma mensagem de request-reply deve ter:


messageType - indica se a mensagem é uma solicitação ou uma mensagem de resposta.
requestID - contém um identificador de mensagem.
remoteReference - é uma referência remota.
operationID - é um identificador para a operação a ser chamada.
arguments -

5. UDP - Já o UDP é mais leve, porém essa leveza vem do fato que ele tolera perdas
de pacotes. Deve ser usado em situações onde isso não seja um grande problema, como
jogos online, streaming de vídeo e de voz.
As trocas entre cliente e servidor estão descritas nos parágrafos a seguir, em
termos
das operações send e receive na API Java para datagramas UDP, embora muitas
implementações
atuais usem TCP. Um protocolo construído sobre datagramas evita sobrecargas
desnecessárias associadas ao protocolo TCP.

UDP

Se o protocolo TCP for usado, isso garantirá que as


mensagens de requisição e de resposta sejam entregues de modo confiável; portanto,
não
há necessidade de o protocolo de requisição-resposta tratar da retransmissão de
mensagens,
filtrar duplicatas ou lidar com históricos. Além disso, o mecanismo de controle
de fluxo permite que argumentos e resultados grandes sejam passados, sem se tomar
medidas especiais para não sobrecarregar o destinatário. Assim, a escolha do
protocolo
TCP simplifica a implementação de protocolos de requisição-resposta. Se sucessivas
requisições e respostas entre o mesmo par cliente-servidor são enviadas por um
mesmo
fluxo, a sobrecarga de conexão necessária não se aplica a toda invocação remota.
Além
disso, a sobrecarga em razão das mensagens de confirmação TCP é reduzida quando uma
mensagem de resposta é gerada logo após a mensagem de requisição.

6. Sim depende de circunstancias adicionais;

7. O protocolo de requisição-resposta • O protocolo que descrevemos aqui é baseado


em
um trio de primitivas de comunicação: doOperation, getRequest e sendReply, como
mostrado na Figura 5.2. Esse protocolo de requisição-resposta combina pedidos com
respostas. Ele pode ser projetado para fornecer certas garantias de entrega. Se
forem
usados datagramas UDP, as garantias de entrega deverão ser fornecidas pelo
protocolo de
requisição-resposta, o qual pode usar a mensagem de resposta do servidor como
confirmação
da mensagem de requisição do cliente. A Figura 5.3 descreve, em linhas gerais, as
três primitivas de comunicação.

8.
Sofrerão de falhas por omissão.
• Não há garantias de entrega das mensagens na ordem do envio.
o protocolo pode sofrer uma falha de processos

9. Para levar em conta as ocasiões em que um servidor falhou ou que uma mensagem
de requisição ou resposta é perdida, doOperation usa um tempo limite (timeout)
quando
está esperando receber a mensagem de resposta do servidor. A ação executada quando
ocorre um tempo limite depende das garantias de entrega oferecidas.

Tempos limite (timeouts) • Existem várias opções para o que doOperation deva fazer
após esgotar um tempo limite (timeout). A opção mais simples é retornar
imediatamente
de doOperation, com uma indicação para o cliente de que doOperation falhou. Essa
não
é a estratégia mais comum – o tempo limite pode ter esgotado devido à perda da
mensagem
de requisição ou de resposta e, neste último caso, a operação foi executada. Para
levar
em conta a possibilidade de mensagens perdidas, doOperation envia a mensagem de
requisição repetidamente, até receber uma resposta ou estar razoavelmente seguro de
que
o atraso se deve à falta de resposta do servidor e não à perda de mensagens.
Finalmente,
quando doOperation retornar, indicará isso para o cliente por meio de uma exceção,
dizendo
que nenhum resultado foi recebido.

10.Semântica talvez: com a semântica talvez, a chamada de procedimento remoto pode


ser
executada uma vez ou não ser executada. A semântica talvez surge quando nenhuma das
medidas de tolerância a falhas é aplicada e pode sofrer os seguintes tipos de
falha:
• falhas por omissão, se a mensagem de requisição ou de resultado for perdida;
• falhas por colapso, quando o servidor que contém a operação remota falha.

11. Semântica pelo menos uma vez: com a semântica pelo menos uma vez, o invocador
recebe
um resultado (no caso em que sabe que o procedimento foi executado pelo menos uma
vez) ou recebe uma exceção, informando-o de que nenhum resultado foi recebido. A
semântica
pelo menos uma vez pode ser obtida pela retransmissão das mensagens de requisição,
o que mascara as falhas por omissão da mensagem de requisição ou de resultado.

12. Maybe - Se a mensagem de resultado não tiver sido recebida após um tempo limite
e não houver
novas tentativas, não haverá certeza se o procedimento foi executado. Se a mensagem
de requisição foi perdida, então o procedimento não foi executado. Por outro lado,
o
procedimento pode ter sido executado e a mensagem de resultado, perdida. Uma falha
por colapso pode ocorrer antes ou depois do procedimento ser executado. Além disso,
em um sistema assíncrono, o resultado da execução do procedimento pode chegar após
o tempo limite. A semântica talvez é útil apenas para aplicações nas quais são
aceitáveis
chamadas mal-sucedidas ocasionais.

Semântica pelo menos uma vez: com a semântica pelo menos uma vez, o invocador
recebe
um resultado (no caso em que sabe que o procedimento foi executado pelo menos uma
vez) ou recebe uma exceção, informando-o de que nenhum resultado foi recebido. A
semântica
pelo menos uma vez pode ser obtida pela retransmissão das mensagens de requisição,
o que mascara as falhas por omissão da mensagem de requisição ou de resultado.

Semântica no máximo uma vez: com a semântica no máximo uma vez, ou o chamador
recebe
um resultado – no caso em que o chamador sabe que o pr ocedimento foi executado
exatamente uma vez – ou recebe uma exceção informando-o de que nenhum resultado foi
recebido – no caso em que o procedimento terá sido executado uma vez ou não terá
sido
executado.

14. Nao faz diferenca pois o servideor executa as operacoes que recebe na
solicitacao e o numero de vezes que estas foram solicitadas.

Você também pode gostar