PROTOCOLOS LÓGICOS DE COMUNICAÇÃO 1 INTRODUÇÃO Protocolo de Comunicação é a formalidade adotada para estabelecer a comunicação entre nós de uma rede. Nestes termos, não podemos tratar um protocolo de comunicação de forma isolada. Devemos, sim, avaliar o conjunto de formalidades devidamente identificadas nas diversas camadas ou nos níveis que elas acontecem. Os protocolos lógicos são aquelas formalidades adotadas para tratar a rede lógica e os protocolos físicos são as formalidades adotadas para o meio físico correspondente. Somente os protocolos usados na camada física podem ser insuficientes ou carentes de recursos, por exemplo, para garantir o envio e o recebimento da informação. Para esta garantia faz-se necessário a inclusão de camadas de software auxiliares, estabelecendo assim os protocolos lógicos. Admita uma interface de rede enviando um frame para um certo destino. Como esta interface pode ter certeza que o frame foi enviado? Como ela pode ter certeza de que o frame foi recebido? É intuitivo que o envio só será confirmado caso o destinatário e os equipamentos intermediários, se existirem, retornarem algum outro frame para o remetente informando-o do fato. Receber também não implica que a informação foi entendida ou processada corretamente. A informação, ou o pacote que a transporta, pode ter defeitos gerados por ruídos na transmissão ou na própria montagem inadequada, deteriorando seu conteúdo ou modificando um padrão adotado. Assim, o receber pode implicar numa confirmação de todas as camadas superiores ou apenas de uma camada mais baixa. Neste último caso, a confirmação pode acontecer por camadas ou seguir um mecanismo de confirmação descendente (a camada mais baixa retornará ao remetente se todas as camadas acima dela confirmarem o recebimento de forma correta ou vice-versa). Como o remetente deve proceder caso não receba uma confirmação do recebimento? Reenvia o mesmo frame, continua enviando novos frames? Este tratamento é aplicável tanto às redes físicas (caso o hardware disponibilize recursos) quanto às lógicas (implementado por software). Temos, então, protocolos destinados ao tratamento da informação quanto ao envio e recebimento desta nas várias camadas. O reenvio do frame ou a confirmação de recebimento pode ocorrer após o reconhecimento ou análise feita por alguma camada superior. Além disto, tem-se protocolos correspondentes (ou associados) à prestação de serviços em camadas mais altas. A prestação de serviços estabelece ou seguem modelos de comunicação, um deles denominado Paradigma Cliente x Servidor. Neste modelo, o servidor executa alguma aplicação específica (com finalidade bem definida) e esta prepara o sistema para atender

solicitações ou "request" de uma aplicação cliente compatível. Assim, o cliente inicia a comunicação. Devemos observar que o "servidor" é um servidor de aplicação. Vimos que os Sistemas Operacionais são projetados para algum tipo de tarefa e atender às aplicações que seus fabricantes adotaram ou criaram. Junto com tais aplicações os fabricantes do SO também incluem os protocolos de comunicação. Discutiremos alguns protocolos de comunicação dando uma ênfase superficial e o analisaremos o protocolo TCP/IP com maiores detalhes por ter sido adotado para uma grande número de aplicações e apresentar código aberto. Assim, veremos os seguintes protocolos:

• NETBIOS/NetBEUI • SAP/IPX • TCP/IP

2 Protocolos NETBIOS/NetBEUI 2.1 INTRODUÇÃO Em 1985, a IBM (e não a Microsoft como muita gente pensa!!!) introduziu o NetBEUI como um protocolo que poderia ser usado em aplicações desenvolvidas para redes, considerando a interface do Sistema de Entrada/Saída Básico de Redes (ou, em inglês, Network Basic Input/Output System - NETBIOS). O NetBEUI foi projetado como um pequeno e eficiente protocolo (sob algum ponto de vista) para uso em redes departamentais (locais) contendo entre 20 e 200 computadores, e que não precisavam ser roteadas para outras sub-redes, embora aceite o roteamento quando explorado o roteamento Token-Ring da IBM. Inicialmente o protocolo NetBEUI é o protocolo padrão dos Sistema Operacional DOS (IBM/Microsoft). Hoje, este protocolo pode ser executado em diversos sistemas operacionais, onde citamos: DOS + LAN Manager, Windows (todos), Unix assim como IBM PCLAN, OS/2 (LAN Server), etc. O NetBEUI pode ser usado com programas que implementam uma variedade se serviços baseados nas seguintes interfaces de programação de aplicações (ou APIs - Application Programming Interface) e interfaces de programação NETBIOS

• Named Pipes • Mailslot • Network DDE (dynamic data exchange) • Remote Procedure Call (RPC) sobre NetBIOS • RPC sobre Named Pipes.

2.2 ARQUITETURA O NetBEUI é um veículo de transporte. É um protocolo de rede e de enlace e não o protocolo de transporte. Sua estrutura é composta por drivers (interface, protocolo LLC) que denominamos de NBF (NetBEUI Frame), o protocolo de transporte (NETBIOS) e o protocolo de aplicações. O exemplo a seguir considera uma máquina cliente executando este protocolo, conectada à outra que serve como gateway para uma rede local (LAN – Local Access Network) através de um acesso Dial-up. Fonte: Microsoft Windows NT Resource Kit. Arquivo network.hlp 2.2.1 Protocolo LLC + Driver = NETBEUI Corresponde a camada de Controle de Link Lógico (LLC) do modelo OSI. No protocolo LLC realizam-se códigos e protocolos voltados ao meio (hardware), endereços físicos, controle de fluxos dos frames, e transferência de dados com ou sem garantias de conexão e abrange as camadas NetBEUI e de interface. Aqui encontramos os endereços físicos das placas de rede, e os protocolos usados para transmitir os frames. OBS: Reparem que não existe uma camada de rede definida. Apesar disto, o NetBEUI (também conhecido como NBF) permite um roteamento em gateway baseado na tecnologia de redes Token-Ring. 2.2.2 Protocolo NetBIOS Corresponde às camadas de transporte e de sessão do modelo OSI. Aqui, o NetBIOS estabelece a sessão, o multiplex/demultiplex, o término da sessão, a segmentação de mensagens, delimitações, montagem e reconhecimentos de envio ou recebimento dos pacotes.

2.2.3 SERVIÇOS O NETBIOS implementa um conjunto de serviços tais como: compartilhamento de periféricos: discos, impressoras, fax/modems, áreas de trabalho (memória); envio e recebimento de mensagens, e um ilimitado número de outros serviços que podem ser programados via RPC. Os serviços NETBIOS também podem ser encapsulados em outros protocolos de rede roteáveis para romper a restrição de rede local, como por exemplo: NETBIOS/TCP-IP. Este tipo de encapsulamento pode ser encontrado em diversos tipos de plataforma e sistemas operacionais. Uma destas aplicações que implementam tal encapsulamento chama-se SAMBA (distribuição gratuita), cuja implementação abrange sistemas operacionais UNIX, (Open)VMS. Os sistemas Windows já trazem este tipo de recurso sem a necessidade de software adicional. Alguns Sistemas Windows (NT, 9x) podem servir como "gateway" para estes protocolos nas conexões de redes DIALUP e ETHERNET. 2.2.4 SEQUENCIA DE ENCAPSULAMENTOS O DADO é a informação (requisição ou resposta) que será envolvida pelo protocolo da aplicação. Este, por sua vez, é evolvido pelo protocolo NETBIOS. Este "envolvimento" representa que o NETBIOS inseriu alguma forma de cabeçalho, especificando a finalidade daquela aplicação, o nome da máquina, o grupo que pertence, o domínio... Agora a finalidade é enviar tudo isto para o meio físico, o que é preparado pelo protocolo NetBEUI e enviado para o meio físico (tamanho do frame, forma, tipo do meio, etc).

2.3 SEGMENTAÇÃO DA REDE Uma vez que o NetBEUI é NÃO-ROTEÁVEL por roteadores "normais", a solução adotada para estabelecer alguma divisão de forma lógica é através de GRUPO DE TRABALHO (para compartilhamento) e DOMÍNIO, usado para AUTENTICAÇÃO. Nos GRUPOS DE TRABALHO (ou WORGROUP), uma máquina pertencente ao grupo vê as outras máquinas do mesmo grupo num primeiro plano. As máquinas de outros grupos podem ser acessadas escolhendo o grupo correspondente. As máquinas controladoras de domínio, rodando Windows NT Server ou equivalente, usam diretórios compartilhados para armazenar informações para todo o domínio, concebendo uma administração única. Há dois tipos de controladores:

• Os controladores de domínio primários (PDC - Primary Domain Controller), que mantém as modificações feitas nas contas do domínio e armazenam as informações num banco de dados. Um domínio tem um PDC.

• Os controladores de domínio de backup (BDC - Backup Domain Controller), que mantém uma cópia do banco de dados do PDC através de mecanismos de sincronização. Um domínio pode ter múltiplos BDCs. 2.4 IDENTIFICAÇÂO As máquinas são identificadas através de nomes únicos independente de grupo no qual elas pertencem. Estes nomes estão associados aos Endereços Ethernet de forma direta (MAC - Media Access Control), que podem ser simulados de forma lógica (Ex. conexões PPP via modem). Os nomes são propagados através de frames tipo broadcast, enviados periodicamente por cada máquina (talvez a eficiência esteja aqui!). Todas as máquinas recebem aquele frame e vão, assim, atualizando suas tabelas contendo as máquinas "vivas" na rede e os recursos que elas disponibilizam. Cada máquina mantém sua própria tabela de nomes, atualizando-as periodicamente. A resolução de nomes depende do tipo de configuração e do nó empregado em cada computador. São aceitos os seguintes tipos de nós:

• b-node -- usam broadcast para o registro e resolução de nomes.

• p-node -- usam solicitações de nomes em conexões ponto-a-ponto feitas ao servidor de nomes NetBIOS (servidores WINS - Windows Internet Name Server) onde os nomes estão registrados e resolvidos. Este tip de nó existirá se o transporte NetBIOS estiver encapsulado (envolvido) pelo protocolo TCP/IP.

• m-node -- usam broadcast para o registro de nomes; para resolver os nomes estas máquinas tentam os frames de broadcast (b-node), e no caso de não receberem

resposta, comutam para a forma p-node.

• h-node -- usam um servidor de nomes NetBIOS para o registro e tradução; entretanto, se o servidor de nomes não está disponível (não pode ser localizado), um h-node tenta a forma de um b-node. A busca por um servidor de nomes é contínua, e um h-node comutará para a forma p-node tão logo encontre um servidor de nomes disponível. Equipamentos configurados como clientes WINS são do tipo h-node.

• Microsoft-enhanced -- Usam os arquivos locais LMHOSTS ou proxies WINS mais a chamada de funções de Socket gethostbyname() ( chamadas a DNS ou arquivos HOSTS) além dos tipos de node citados anteriormente. Este caso é aplicável quando consideramos o encapsulamento NETBIOS/TCP.

Informações complementares podem ser encontradas no arquivo network.hlp do Windows NT Resouce Kit.

3 Protocolo IPX 3.1 INTRODUÇÃO O protocolo IPX (Internetwork Packet Exchange) foi desenvolvido pela NOVELL e é o protocolo de rede padrão para redes NETWARE. Estas redes usam uma variedade de protocolos, sendo muitos destes desenvolvidos especialmente para redes Netware e baseados no protocolo da Xerox, o XNS (Xerox Network System). De fato, os dois são quase idênticos, exceto por uma pequena diferença em alguns sub-protocolos. Por exemplo, o IPX da Novell (ou Internetwork Packet Exchange) é baseado no IDP da XEROX (ou Internetwork Datagram Packet). O XNS inclui protocolos para aplicações com propósitos especiais como a manipulação de mensagens enquanto o NetWare usa, apenas, algumas funções básicas ignorando o resto. Neste modelo de rede, todas as transações entre máquinas são autenticadas e verificadas pela máquina servidora Netware, mesmo que a informação esteja em outra máquina cliente. Ou seja, a servidora Netware tem controle total sobre as ações de seus clientes.

3.2 ARQUITETURA A arquitetura do conjunto IPX em relação ao modelo de referencia OSI é apresentado abaixo. 3.2.1 PROTOCOLO IPX O IPX é o protocolo freqüentemente associado com redes NetWare e restabelece a parte lógica da arquitetura, proporcionando as funções de "rede". O IPX caminha nos vários segmentos de rede disponíveis e trata do envio dos dados. O endereço IPX é uma combinação de um endereço de rede e do endereço da placa de rede. A parte de rede é um número hexadecimal de 32 bits representado numa cadeia de caracteres de 64 bits (ver identificação). Na maioria das vezes, a parte de rede está associada ao servidor Netware ou roteador. Uma máquina cliente Netware obterá esta parcela de endereçamento a partir do servidor ou do roteador, durante a fase de inicialização e a associará ao endereço de hardware existente (MAC). Se não existir um servidor Netware então o roteador alimentará a rede com esta informação, caso contrário a identidade IPX ficará limitada à rede local através do endereço físico. Uma vez que o endereço de um nó IPX de tem seu endereço de hardware, os sistemas podem se comunicar diretamente em uma mesma rede física, sem se preocupar com o endereço de rede. Se o sistema de destino é uma máquina de uma rede remota então o dado é direcionado para o roteador e este tratará do envio para o segmento de rede adequado.

OBS: O IPX não garante o envio, ou proporciona serviços de correção ou detecção de erros. Estas funções são de responsabilidade da camada de transporte (o SPX e PEP). 3.2.2 PROTOCOLO SPX O SPX (Sequenced Packet Exchange) é um protocolo de transporte confiável que usa o IPX para o envio. Uma vez que o IPX (o protocolo de rede) não oferece qualquer confiabilidade, as aplicações que usam a rede devem ter algum protocolo confiável, no caso, disponibilizada pelo SPX. Exemplos destas aplicações podemos incluir, um cliente-servidor de banco de dados, ou um produto de antivírus. Ao invés da aplicação cliente ler diretamente um arquivo armazenado no servidor, como acontece com o NetBIOS/NETBEUI, a aplicação cliente solicita a informação desejada à aplicação no servidor e esta faz o acesso ao arquivo e envia o registro (informação), através de comandos enviados e envolvidos pelo SPX. O SPX trata esta conectividade como circuitos virtuais, que proporcionam conexões entre aplicações através do IPX. O tratamento de erros e de reenvio é feito por janelas. Ou seja, ao enviar um conjunto de pacotes e se um deles apresentar algum erro, então todo o conjunto será retransmitido. Caso o recebimento tenha sucesso, então a máquina de origem recebe uma confirmação de todo o conjunto. A confirmação individual dos pacotes é feita pelo protocolo PEP. O mecanismo adotado no SPX permite o fluxo de uma grande quantidade de dados de forma rápida com um pequeno risco de dados serem corrompidos. (Será que isto é tanto assim? E no caso da rede apresentar colisões? Eis o motivo pelo qual os servidores IPX travam sob algum problema de rede! Por outro lado, quando a rede está bem dimensionada o desempenho é alto!) 3.2.3 PROTOCOLO PEP O PEP (Packet Exchange Protocol) é um outro protocolo de transporte similar ao SPX. O PEP é usado, exclusivamente, para o envio dos pacotes NCP usados para a leitura e escrita de arquivos nos servidores Netware, e proporciona grande confiabilidade. Quando

o pacote é enviado usando o PEP, cada pacote é verificado independentemente, e neste caso é disparado um relógio. Nenhum outro pacote será enviado até que a origem receba uma resposta confirmando a sua chegada. Se o tempo expira, o PEP remonta e retransmite o pacote e reinicializa a contagem de tempo. Este tratamento (handshake) e espera consomem uma grande banda de passagem da rede, mas garante, de forma absoluta, que o pacote foi enviado e recebido. Em pequenas redes locais (mesma rede física e pequeno número de máquinas) este tratamento passa desapercebido, mas em redes grandes ou complexas a queda do desempenho é sensivelmente prejudicado quando envolve grandes períodos de espera. 3.2.4 SEQUENCIA DE ENCAPSULAMENTOS: No envio, a solicitação, resposta, a informação, ou seja o DADO é envolvido pela aplicação ou serviço (NCP, SAP, RIP, etc). Se o serviço não for o SAP, o pacote é envolvido pelo protocolo de transporte correspondente (PEP e SPX). O serviço SAP, como veremos, não usa qualquer protocolo de transporte. Quase pronto para o meio físico, o conjunto é envolvido pelo protocolo de rede (IPX) que identificará a rede+máquina de destino e orígem do pacote IPX. Se o destino for uma máquina de outra rede uma função de roteameno é executada, e, finalmente, o pacote IPX é depositado na fila da interface de rede (ou canal de saída) correspondente e envolvido pelo frame físico. No recebimento, o frame identificado pela interface e endereço do nó e depositado nas filas de entrada do IPX que analisará o destino do pacote. Caso o pacote apresente uma rede de destino diferente interface recebida, estabelece-se o roteamento IPX. Não havendo identificação do serviço SAP, o pactote é direcinoado para a camada de SPX ou PEP que estabelecem o mecanismo de confirmação de recebimento, e automaticamente direcionado para o serviço final. Tratando-se de um acesso a arquivo, a aplicação tratará de fazê-lo e retornará o registro solicitado

3.3 IDENTIFICAÇÃO A identificação dos nós lógicos no protocolo IPX é composto por duas partes: a primeira identifica a rede Netware e é composto por 24 bits (representados na forma hexadecimal, e valor entre 1 e FFFFFFFF. A segunda parte contém 6 bytes e corresponde ao endereço MAC (Media Access Control). Todos as máquinas que pertencem ao mesmo segmento lógico possuem o mesmo endereço de rede 4 Protocolo TCP/IP 4.1 INTRODUÇÃO Em 1969, por questões militares, o governo americano iniciava os estudos sobre um protocolo que atendesse certos requisitos de comunicação. Dentre eles, destacam-se: 1) Grande número de conexões lógicas 2) Capacidade de transferencia de mensagens de controle; 3) Capacidade de execução remota em batch ou interativo; 4) Transferência de arquivos, e 5) Independência da Plataforma Neste curso, estudaremos o conjunto de protocolos que compõem o TCP/IP, as camadas e aplicações sob o ponto de vista funcional, porém com um nível de detalhe necessário visando a administração e o desenvolvimento de produtos de software. Um comentário para os "comodistas": Se existe alguma aplicação pronta é porque alguém fez. Usá-la, simplesmente, é tão perverso e perigoso quanto uma bomba relógio ou uma arma desconhecida onde o tiro pode sair pela culatra. Não se busca um expert, mas profissionais sem inocência. Para justificar este ponto de vista busque informações sobre "cavalos de Tróia".

4.2 ARQUITETURA Comparado ao OSI, o modelo TCP/IP é muito mais simples e consta de apenas 4 níveis (camadas), podendo englobar um ou mais níveis do modelo OSI. Não considerando todo o rigor das atividades das camadas do TCP/IP em relação o modelo OSI, podemos comparar os dois protocolos como segue: Numa mesma rede física, a troca de mensagens, datagramas, pacotes e frames entre os nós estabelecem conexões entre os vários níveis (ou camadas), deixando-a transparecer conexões entre as camadas lógicas num nível mais alto. A figura abaixo mostra estas conexões considerando uma mesma rede física. Ou seja, a mensagem enviada por um nó é idêntica aquela recebida pelo outro nó. Neste caso, a igualdade se estende até a camada de frames.

Na próxima figura, temos a presença de roteador. Neste caso, a igualdade só é satisfeita até os pacotes. Ao receber o frame na interface de entrada do roteador, este é transferido para a camada de rede, o datagrama é extraído do frame, analisado, o cabeçalho para identificar a rede de destino (e não a máquina). Uma vez conhecida a interface de destino, é montado um novo datagrama e enviado à ela. Esta, por sua vez, monta o frame adequado para o novo meio físico usando o endereço físico do roteador.