1. Protocolos de comunicação estabelecem formalidades para comunicação entre nós de rede, avaliando-se conjuntos de formalidades em diversas camadas. Protocolos lógicos tratam da rede lógica e protocolos físicos do meio físico. 2. Protocolos nas camadas físicas podem ser insuficientes, necessitando camadas de software auxiliares que estabelecem protocolos lógicos para garantir envio e recebimento de informação. 3. Protocolos tratam do envio e recebimento de informação nas v

1. 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

2. 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.

3. 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.

4. 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).

5. 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

6. 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.

7. 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.

8. 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

9. 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

10. 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".

11. 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.

12. 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.