Don't like ads? PRO users don't see any ads ;-)
Public Pastes
Guest

Untitled

By: a guest on May 8th, 2012  |  syntax: None  |  size: 7.33 KB  |  hits: 11  |  expires: Never
download  |  raw  |  embed  |  report abuse  |  print
This paste has a previous version, view the difference. Text below is selected. Please press Ctrl+C to copy to your clipboard. (⌘+C on Mac)
  1. O uso de fluxos TCP para implementar o protocolo de solicitação-resposta • Seção 4.2.3 mencionou que muitas vezes é difícil decidir em um tamanho apropriado para o buffer no qual para receber datagramas. No protocolo de solicitação-resposta, isto se aplica para os buffers usados ​​pelo servidor para receber mensagens de solicitação e pelo cliente para receber respostas. O comprimento limitado de datagramas (geralmente 8 kilobytes) não pode ser considerado adequado para utilização em sistemas de RMI transparente ou RPC, uma vez que os argumentos ou os resultados dos procedimentos podem ser de qualquer tamanho.
  2. O desejo de evitar a implementação de protocolos multipacket é uma das razões para a escolha de implementar protocolos de solicitação-resposta em cima de fluxos TCP, permitindo que os argumentos e resultados de todo o tamanho a ser transmitido. Em particular, Java serialização de objetos é um protocolo de fluxo que permite que os argumentos e os resultados a serem enviados em cima de fluxos entre o cliente eo servidor, tornando possível para as coleções de objetos de qualquer tamanho a ser transmitidas de forma confiável. Se o protocolo TCP é usado, ele garante que as mensagens de solicitação e resposta são entregues de forma confiável, então não há necessidade de o protocolo de solicitação-resposta para lidar com a retransmissão de mensagens e filtragem de duplicatas ou com histórias. Além disso, o mecanismo de controle de fluxo permite que os argumentos de grande porte e resultados a serem passados ​​sem tomar medidas especiais para evitar sobrecarregar o destinatário. Assim, o protocolo TCP é escolhida para o pedido de resposta de protocolos porque pode simplificar a sua aplicação. Se os pedidos sucessivos e respostas entre o par cliente-servidor mesmo são enviados através da mesma corrente, a sobrecarga da conexão não é aplicável a cada invocação remota. Além disso, a sobrecarga devido às mensagens de reconhecimento TCP é reduzida quando uma mensagem de resposta segue logo após uma mensagem de solicitação.
  3. Howeever, se o aplicativo não exige que todas as facilidades oferecidas pelo TCP, um protocolo mais eficiente, especialmente adaptada pode ser implementado sobre UDP. Por exemplo, a Sun NFS não requer suporte para mensagens de tamanho ilimitado, desde que transmite os blocos de tamanho fixo de arquivos entre cliente e servidor. Além disso, as suas operações são concebidos para ser idempotente, de modo que não importa se as operações são realizadas mais do que uma vez, a fim de retransmitir mensagens de resposta perdidos, tornando desnecessário para manter uma história.
  4. HTTP: Um exemplo de um protocolo de solicitação-resposta • Capítulo 1 introduziu o HyperText Transfer Protocol (HTTP) usado por clientes de navegador da Web para fazer pedidos a servidores web e de receber respostas a partir deles. Para recapitular, servidores web gerir os recursos implementados de diferentes maneiras:
  5. • como dados - por exemplo, o texto de uma página HTML, uma imagem ou a classe de um applet;
  6. • como um programa - por exemplo, servlets [java.sun.com III], ou PHP ou Python programas que são executados no servidor web.
  7. As solicitações do cliente especificar uma URL que inclui o nome de host DNS de um servidor web e um número de porta opcional no servidor web, assim como o identificador de um recurso no servidor.
  8. HTTP é um protocolo que especifica as mensagens envolvidas em uma troca de solicitação-resposta, os métodos, argumentos e resultados, e as regras para a representação (de triagem) deles nas mensagens. Ele suporta um conjunto fixo de métodos (GET, PUT, POST, etc) que são aplicáveis ​​a todos os recursos do servidor. É ao contrário dos protocolos anteriormente descritos, em que cada serviço tem o seu próprio conjunto de operações. Além de invocar métodos em recursos da Web, o protocolo permite a negociação de conteúdo e estilo de senha de autenticação:
  9. Negociação de conteúdo: pedidos dos clientes pode incluir informações sobre o que representações de dados que pode aceitar (por exemplo, idioma ou tipo de mídia), que permite ao servidor escolher a representação que é o mais apropriado para o usuário.
  10. Autenticação: Credenciais e os desafios são utilizados para apoiar senha estilo de autenticação. Na primeira tentativa de acessar uma área protegida por senha, a resposta do servidor contém um desafio aplicável ao recurso. Capítulo 11 explica desafios. Quando um cliente recebe um desafio, torna-se o usuário digite um nome e senha e envia as credenciais associadas com solicitações subseqüentes.
  11. HTTP é implementado sobre TCP. Na versão original do protocolo, cada interação cliente-servidor consistiu das seguintes etapas:
  12. • As solicitações de clientes eo servidor aceita uma conexão na porta padrão do servidor ou em uma porta especificada na URL.
  13. • O cliente envia uma mensagem de solicitação para o servidor.
  14. • O servidor envia uma mensagem de resposta ao cliente.
  15. • A conexão é fechada.
  16. No entanto, estabelecer e fechar uma conexão para cada troca de solicitação-resposta é caro, sobrecarregando o servidor e fazendo com que muitas mensagens a serem enviadas pela rede. Tendo em mente que os navegadores fazem geralmente vários pedidos para o mesmo servidor - por exemplo, para obter as imagens em uma página apenas fornecida - uma versão mais recente do protocolo (HTTP 1.1, consulte RFC 2616 [. Fielding et al 1999]) usa persistente conexões - as conexões que permanecem em aberto sobre uma série de pedido de resposta de trocas entre o cliente eo servidor. A conexão persistente pode ser fechada pelo cliente ou servidor a qualquer momento através do envio de uma indicação para o outro participante. Servidores vão fechar uma conexão persistente quando estiver ociosa por um período de tempo. É possível que um cliente pode receber uma mensagem do servidor dizendo que a ligação está fechada enquanto ele está no meio de envio de um outro pedido ou pedidos. Nesses casos, o navegador irá reenviar os pedidos, sem a participação do usuário, desde que as operações envolvidas são idempotentes. Por exemplo, o método descrito abaixo GET é idempotente. Onde não-idempotentes operações estão envolvidos, o navegador deve consultar o usuário sobre o que fazer a seguir.
  17. Os pedidos e as respostas são codificados em mensagens como cadeias de texto ASCII, mas os recursos podem ser representados como seqüências de bytes e pode ser compactado. O uso do texto na representação de dados externa simplificou o uso de HTTP para programadores de aplicativos que trabalham diretamente com o protocolo. Neste contexto, uma representação textual não adiciona muito ao comprimento das mensagens.
  18. Recursos de dados são fornecidos como MIME-estruturas semelhantes em argumentos e resultados. Multipurpose Internet Mail Extensions (MIME), especificados na RFC 2045 [Freed e Borenstein 1996], é um padrão para envio de dados de várias partes contendo, por exemplo, textos, imagens e sons em mensagens de e-mail. Os dados são prefixados com o seu tipo de MIME para que o destinatário saberá como lidar com isso. Um tipo MIME especifica um tipo e um subtipo, por exemplo, text / plain, text / html, image / gif ou image / jpeg. Os clientes também podem especificar os tipos MIME que eles estão dispostos a aceitar.
create a new version of this paste RAW Paste Data