Programação e desenvolvimento de aplicações com TCP

Agora que já examinamos várias importantes aplicações de rede, vamos explorar como são escritos programas de aplicação de rede. Nesta seção escreveremos programas de aplicações que usam TCP; na seção seguinte, escreveremos programas que usam UDP.

Lembre-se de que na Seção 2.1 dissemos que muitas aplicações de rede consistem em um par de programas — um programa cliente e um programa servidor — que residem em dois sistemas finais diferentes. Quando esses programas são executados, criam-se um processo cliente e um processo servidor, que se comunicam entre si lendo de seus sockets e escrevendo através deles. Ao criar uma aplicação de rede, a tarefa principal do programador é escrever o código tanto para o programa cliente como para o programa servidor.

Há dois tipos de aplicações de rede. Um deles é uma implementação de um protocolo padrão definido, por exemplo, em um RFC. Para essa implementação, os programas, cliente e servidor, devem obedecer às regras ditadas pelo RFC. Por exemplo, o programa cliente poderia ser uma implementação do lado do cliente do protocolo FTP descrito na Seção 2.3 e definido explicitamente no RFC 959 e o programa servidor, uma implementação do protocolo de servidor FTP também descrito explicitamente no RFC 959. Se um programador escrever codificação para o programa cliente e um outro programador independente escrever uma codificação para o programa servidor e ambos seguirem cuidadosamente as regras do RFC, então os dois programas poderão interagir. Realmente, muitas das aplicações de rede de hoje envolvem comunicação entre programas cliente e servidor que foram criados por programadores diferentes — por exemplo, um browser Netscape que se comunica com um servidor Web Apache, ou um cliente FTP em um PC que carrega um arquivo em um servidor FTP UNIX. Quando um programa, cliente ou servidor, implementa um protocolo definido em um RFC, deve usar o número de porta associado com o protocolo. (Números de portas foram discutidos brevemente na Seção 2.1. Serão examinados mais detalhadamente no Capítulo 3.)

O outro tipo de aplicação cliente-servidor é uma aplicação proprietária. Nesse caso, o protocolo de camada de aplicação utilizado pelos programas cliente e servidor não obedecem necessariamente a nenhum RFC existente. Um único programador (ou equipe de desenvolvimento) cria ambos os programas cliente e servidor, e tem completo controle sobre o que entra no código. Mas, como a codificação não implementa um protocolo de domínio público, outros programadores independentes não poderão desenvolver programas que interajam com a aplicação. Ao desenvolver uma aplicação proprietária, o programador deve ter o cuidado de não usar um dos números de porta bem conhecidos, definidos em RFCs.

Nesta seção e na próxima, examinaremos as questões fundamentais do desenvolvimento de uma aplicação cliente-servidor proprietária. Durante a fase de desenvolvimento, uma das primeiras decisões que o programador deve tomar é se a aplicação rodará em TCP ou UDP. Lembre-se de que o TCP é orientado para conexão e provê um canal confiável de cadeia de bytes, pelo qual fluem dados entre dois sistemas finais. O UDP não é orientado para conexão e envia pacotes de dados independentes de um sistema final ao outro, sem nenhuma garantia de entrega.

Nesta seção, desenvolveremos uma aplicação cliente simples que roda em TCP; na seção seguinte, desenvolveremos uma aplicação cliente simples que roda em UDP. Apresentaremos essas aplicações TCP e UDP simples em Java. Poderíamos escrevê-las em linguagem C ou C++, mas optamos por Java por diversas razões. Em primeiro lugar, o código das aplicações é mais elegante e mais limpo em Java. Com Java, há menos linhas de codificação e cada uma delas pode ser explicada a programadores iniciantes sem muita dificuldade. Mas não precisa ficar assustado se não estiver familiarizado com a linguagem Java. Você conseguirá acompanhar a codificação se tiver experiência de programação em outra linguagem.

Para leitores interessados em programação cliente-servidor em linguagem C, há várias boas referências à disposição [Donahoo, 2001; Stevens, 1997; Frost, 1994; Kurose, 1996].  

ATIVIDADE FIXAÇÃO

Comentários

Postar um comentário

Postagens mais visitadas deste blog

Wi-Fi: LANs sem fio 802.11

Imagem
Presentes no local de trabalho, em casa, em instituições educacionais, em cafés, aeroportos e esquinas, as LANs sem fio agora são uma das mais importantes tecnologias de rede de acesso na Internet de hoje. Embora muitas tecnologias e padrões para LANs sem fio tenham sido desenvolvidos na década de 1990, uma classe particular de padrões surgiu claramente como a vencedora: a LAN sem fio IEEE 802.11, também conhecida como Wi-Fi. Nesta seção estudaremos mais detalhadamente as LANs sem fio 802.11, examinando a estrutura do quadro 802.11, o protocolo 802.11 de acesso ao meio e a interconexão de LANs 802.11 com LANs Ethernet cabeadas. Há diversos padrões 802.11 para tecnologia de LAN sem fio, entre eles 802.11b, 802.11a e 802.11g. A Tabela 6.1 apresenta um resumo das principais características desses padrões. Na época em que escrevíamos este livro (primeiro semestre de 2009), mais mecanismos 802.11g eram oferecidos por pontos de acesso e por fornecedores de placas LAN. Estão também disponívei...
Saiba mais »

Caches Web

Imagem
Um cache Web — também denominado servidor proxy — é uma entidade da rede que atende requisições HTTP em nome de um servidor Web de origem. O cache Web tem seu próprio disco de armazenagem e mantém, dentro dele, cópias de objetos recentemente requisitados. Como ilustrado na Figura 2.11, o browser de um usuário pode ser configurado de modo que todas as suas requisições HTTP sejam dirigidas primeiramente ao cache Web. Uma vez que esteja configurado um browser, cada uma das requisições de um objeto que o browser faz é primeiramente dirigida ao cache Web. Como exemplo, suponha que um browser esteja requisitando o objeto http://www.someschool.edu/campus.gif . Eis o que acontece: 1. O browser estabelece uma conexão TCP com o cache Web e envia a ele uma requisição HTTP para um objeto.  2. O cache Web verifica se tem uma cópia do objeto armazenada localmente. Se tiver, envia o objeto ao browser do cliente, dentro de uma mensagem de resposta HTTP.   3. Se não tiver o objeto, o cach...
Saiba mais »

Acesso celular à Internet

Na aula anterior, vimos como um hospedeiro da Internet pode acessá-la quando está dentro de um hotspot Wi-Fi, isto é, nas vizinhanças de um ponto de acesso 802.11. Mas a área de cobertura da maioria dos hotspots Wi-Fi é pequena, entre 10 e 100 metros de diâmetro. O que fazer, então, quando precisamos desesperadamente de um acesso sem fio à Internet e não podemos acessar nenhum hotspot Wi-Fi? Dado que a telefonia celular está presente por toda a parte, em muitas áreas no mundo inteiro, uma estratégia natural é estender as redes celulares de modo que suportem não somente a telefonia de voz, mas também o acesso sem fio à Internet. Idealmente, esse acesso à Internet teria uma velocidade razoavelmente alta e proveria mobilidade imperceptível e ininterrupta, permitindo que os usuários mantivessem suas sessões TCP enquanto em trânsito, por exemplo, em um ônibus ou em um trem. Com taxas de bits suficientemente altas, o usuário poderia até mesmo manter sessões de videoconferência em alta defini...
Saiba mais »