Programação de aplicações com UDP
Aprendemos na seção anterior que, quando dois processos se comunicam por TCP, é como se houvesse uma tubulação entre eles, que permanece ativa até que um dos dois processos a feche. Quando um dos processos quer enviar alguns bytes para o outro processo, simplesmente insere os bytes na tubulação. O processo de envio não tem de acrescentar um endereço de destino aos bytes porque a tubulação está ligada logicamente ao destino. Além disso, a tubulação provê um canal confiável de cadeia de bytes — a sequência de bytes recebida pelo processo receptor é exatamente a mesma que o remetente inseriu na tubulação.
O UDP também permite que dois (ou mais) processos que rodam em hospedeiros diferentes se comuniquem. Contudo, é diferente do TCP de muitas maneiras fundamentais. Primeiramente, é um serviço não orientado para conexão — não há uma fase inicial de apresentação, durante a qual é estabelecida uma tubulação entre os dois processos. Como o UDP não tem uma tubulação, quando um processo quer enviar um conjunto de bytes a outro, o processo remetente deve anexar o endereço do processo destinatário ao conjunto de bytes. E isso precisa ser feito para cada conjunto de bytes que o processo remetente enviar. Como analogia, considere um grupo de 20 pessoas que toma cinco táxis para um mesmo destino; quando cada um dos grupos entra em um carro, tem de informar separadamente ao motorista o endereço de destino. Assim, o UDP é semelhante a um serviço de táxi. O endereço de destino é uma tupla que consiste no endereço IP do hospedeiro destinatário e no número de porta do processo destinatário. Vamos nos referir ao conjunto de bytes de informação, juntamente com o endereço IP do destinatário e o número de porta, como ‘pacote’. O UDP provê um modelo de serviço não confiável orientado para mensagem, no sentido de que faz o melhor esforço para entregar o conjunto de bytes ao destino. Esses conjuntos são bytes enviados em uma única operação na parte remetente, e serão entregues como um conjunto na parte destinatária; isso contrasta com o sentido da cadeia de bytes do TCP. O serviço UDP faz o melhor esforço já que o UDP não garante que o conjunto de bytes será realmente entregue. O serviço UDP contrasta acentuadamente (em vários aspectos) com o modelo de serviço confiável de cadeia de bytes do TCP.
Após ter criado um pacote, o processo remetente empurra-o para dentro da rede através de um socket. Continuando com nossa analogia do táxi, do outro lado do socket remetente há um táxi esperando pelo pacote. Esse táxi, então, leva o pacote até seu endereço de destino. Contudo, não garante que finalmente entregará o pacote no seu destino final, pois pode quebrar ou sofrer algum outro problema não previsto no caminho. Em outras palavras, o UDP provê serviço não confiável de transporte a seus processos de comunicação — não dá nenhuma garantia de que um datagrama (‘pacote’) alcançará seu destino final.
Nesta seção, ilustraremos programação de socket desenvolvendo novamente a mesma aplicação da seção anterior, mas, dessa vez, com UDP. Veremos que a codificação para UDP é diferente da codificação para TCP de muitas maneiras importantes. Em particular, (1) não há apresentação inicial entre os dois processos e, portanto, não há necessidade de um socket de entrada, (2) não há cadeias ligadas aos sockets, (3) os hospedeiros remetentes criam pacotes anexando o endereço IP do destinatário e o número de porta a cada conjunto de bytes que enviam e (4) o processo destinatário deve desmontar cada pacote recebido para obter os bytes de informação do pacote.
Lembre-se, mais uma vez, da nossa aplicação simples:
1. Um cliente lê uma linha a partir de sua entrada padrão (teclado) e a envia através de seu socket para o servidor.
2. O servidor lê uma linha a partir de seu socket.
3. O servidor converte a linha para letras maiúsculas.
4. O servidor envia a linha modificada através de seu socket ao cliente.
5. O cliente lê a linha modificada através de seu socket e apresenta a linha em sua saída padrão (monitor).
O programa UDPClient.java constrói uma cadeia e um socket, como mostra a Figura 2.33. O socket é denominado clientSocket e é do tipo DatagramSocket. Note que o UDP usa, no cliente, um tipo de socket diferente do usado no TCP. Em particular, com UDP nosso cliente usa um DatagramSocket, enquanto com TCP ele usou um Socket. A cadeia inFromUser é uma cadeia de entrada para o programa; está ligada à entrada padrão, isto é, ao teclado. Tínhamos uma cadeia equivalente em nossa versão TCP do programa. Quando o usuário digita caracteres no teclado, esses caracteres fluem para dentro da cadeia inFromUser. Porém, ao contrário do TCP, não há cadeias (de entrada e de saída) ligadas ao socket. Em vez de alimentar bytes à cadeia ligada a um objeto Socket, o UDP transmite pacotes individuais por meio do objeto DatagramSocket.
Comentários
Postar um comentário