CAP258 - Redes de Computadores e Comunicação de Dados · tecnologia de redes Token-Ring. 2.2.2...

CAP 258 - REDES E COMUNICAÇÃO DE DADOS

Redes - PROTOCOLOS LÓGICOS DE COMUNICAÇÃO

65 04/03/01Ulisses Thadeu V Guedes

Redes - Parte II PROTOCOLOS LÓGICOS DE COMUNICAÇÃO _________________ 67

1 INTRODUÇÃO _______________________________________________________ 67

2 Protocolos NETBIOS/NetBEUI __________________________________________ 68

2.1 INTRODUÇÃO ___________________________________________________________ 68

2.2 ARQUITETURA __________________________________________________________ 69

2.2.1 Protocolo LLC _______________________________________________________________ 69

2.2.2 Protocolo NetBIOS ___________________________________________________________ 69

2.2.3 SERVIÇOS _________________________________________________________________ 70

2.2.4 SEQUENCIA DE ENCAPSULAMENTOS ________________________________________ 70

2.3 SEGMENTAÇÃO DA REDE________________________________________________ 70

2.4 IDENTIFICAÇÂO ________________________________________________________ 71

3 Protocolo IPX_________________________________________________________ 72

3.1 INTRODUÇÃO ___________________________________________________________ 72

3.2 ARQUITETURA __________________________________________________________ 72

3.2.1 PROTOCOLO IPX ___________________________________________________________ 73

3.2.2 PROTOCOLO SPX ___________________________________________________________ 73

3.2.3 PROTOCOLO PEP ___________________________________________________________ 74

3.2.4 SEQUENCIA DE ENCAPSULAMENTOS:________________________________________ 74

3.3 IDENTIFICAÇÃO ________________________________________________________ 75

3.4 SERVIÇOS_______________________________________________________________ 75

4 Protocolo TCP/IP______________________________________________________ 79

4.1 INTRODUÇÃO ___________________________________________________________ 79

4.2 ARQUITETURA __________________________________________________________ 80

4.2.1 CAMADA DE INTERFACE____________________________________________________ 82




4.2.2 CAMADA DE REDE _________________________________________________________ 84

4.2.3 CAMADA DE TRANSPORTE__________________________________________________ 84

4.2.4 CAMADA DE APLICAÇÃO ___________________________________________________ 85

4.2.5 SEQUENCIA DE ENCAPSULAMENTOS ________________________________________ 86

4.3 IDENTIFICAÇÃO ________________________________________________________ 86

4.4 SERVIÇOS_______________________________________________________________ 87

5 Encapsulamento De Protocolos __________________________________________ 87

5.1 ENCAPSULAMENTO POR-INTERFACE. ___________________________________ 87

5.2 ENCAPSULAMENTO POR SERVIÇO (APLICAÇÃO) _________________________ 88

6 Exercícios * __________________________________________________________ 89




Redes - Parte IIPROTOCOLOS LÓGICOS DE COMUNICAÇÃO

1 INTRODUÇÃO

Protocolo de Comunicação é a formalidade adotada para estabelecer a comunicaçãoentre nós de uma rede. Nestes termos, não podemos tratar um protocolo de comunicaçãode forma isolada. Devemos, sim, avaliar o conjunto de formalidades devidamenteidentificadas nas diversas camadas ou nos níveis que elas acontecem. Os protocoloslógicos são aquelas formalidades adotadas para tratar a rede lógica e os protocolos físicossão as formalidades adotadas para o meio físico correspondente.

Somente os protocolos usados na camada física podem ser insuficientes ou carentes derecursos, por exemplo, para garantir o envio e o recebimento da informação. Para estagarantia faz-se necessário a inclusão de camadas de software auxiliares, estabelecendoassim os protocolos lógicos.

Admita uma interface de rede enviando um frame para um certo destino. Como estainterface pode ter certeza que o frame foi enviado? Como ela pode ter certeza de queo frame foi recebido?

É intuitivo que o envio só será confirmado caso o destinatário e os equipamentosintermediários, se existirem, retornarem algum outro frame para o remetente informando-odo fato. Receber também não implica que a informação foi entendida ou processadacorretamente. A informação, ou o pacote que a transporta, pode ter defeitos gerados porruídos na transmissão ou na própria montagem inadequada, deteriorando seu conteúdo oumodificando um padrão adotado. Assim, o receber pode implicar numa confirmação detodas as camadas superiores ou apenas de uma camada mais baixa. Neste último caso, aconfirmação pode acontecer por camadas ou seguir um mecanismo de confirmaçãodescendente (a camada mais baixa retornará ao remetente se todas as camadas acima delaconfirmarem 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 aotratamento da informação quanto ao envio e recebimento desta nas várias camadas. Oreenvio do frame ou a confirmação de recebimento pode ocorrer após o reconhecimento ouaná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çosestabelece ou seguem modelos de comunicação, um deles denominado Paradigma Clientex Servidor. Neste modelo, o servidor executa alguma aplicação específica (com finalidadebem 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 queo "servidor" é um servidor de aplicação.

Vimos que os Sistemas Operacionais são projetados para algum tipo de tarefa e atender àsaplicações que seus fabricantes adotaram ou criaram. Junto com tais aplicações osfabricantes do SO também incluem os protocolos de comunicação. Discutiremos algunsprotocolos de comunicação dando uma ênfase superficial e o analisaremos o protocoloTCP/IP com maiores detalhes por ter sido adotado para uma grande número de aplicaçõese 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 comoum protocolo que poderia ser usado em aplicações desenvolvidas para redes, considerandoa interface do Sistema de Entrada/Saída Básico de Redes (ou, em inglês, Network BasicInput/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 quenão precisavam ser roteadas para outras sub-redes, embora aceite o roteamento quandoexplorado o roteamento Token-Ring da IBM. Inicialmente o protocolo NetBEUI é o protocolopadrão dos Sistema Operacional DOS (IBM/Microsoft). Hoje, este protocolo pode serexecutado 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çosbaseados nas seguintes interfaces de programação de aplicações (ou APIs - ApplicationProgramming 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 oprotocolo de transporte. Sua estrutura é composta por drivers (interface, protocolo LLC) quedenominamos de NBF (NetBEUI Frame), o protocolo de transporte (NETBIOS) e o protocolode aplicações. O exemplo a seguir considera uma máquina cliente executando esteprotocolo, conectada à outra que serve como gateway para uma rede local (LAN - LocalAccess 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 LLCrealizam-se códigos e protocolos voltados ao meio (hardware), endereços físicos, controlede fluxos dos frames, e transferência de dados com ou sem garantias de conexão e abrangeas camadas NetBEUI e de interface. Aqui encontramos os endereços físicos das placas derede, 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 natecnologia de redes Token-Ring.

2.2.2 Protocolo NetBIOSCorresponde às camadas de transporte e de sessão do modelo OSI. Aqui, o NetBIOSestabelece a sessão, o multiplex/demultiplex, o término da sessão, a segmentação demensagens, delimitações, montagem e reconhecimentos de envio ou recebimento dospacotes.




2.2.3 SERVIÇOS

O NETBIOS implementa um conjunto de serviços tais como: compartilhamento deperiféricos: discos, impressoras, fax/modems, áreas de trabalho (memória); envio erecebimento de mensagens, e um ilimitado número de outros serviços que podem serprogramados via RPC.

Os serviços NETBIOS também podem ser encapsulados em outros protocolos de rederoteáveis para romper a restrição de rede local, como por exemplo: NETBIOS/TCP-IP. Estetipo de encapsulamento pode ser encontrado em diversos tipos de plataforma e sistemasoperacionais. Uma destas aplicações que implementam tal encapsulamento chama-seSAMBA (distribuição gratuita), cuja implementação abrange sistemas operacionais UNIX,(Open)VMS. Os sistemas Windows já trazem este tipo de recurso sem a necessidade desoftware adicional. Alguns Sistemas Windows (NT, 9x) podem servir como "gateway" paraestes 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 daaplicação. Este, por sua vez, é evolvido pelo protocolo NETBIOS. Este "envolvimento"representa que o NETBIOS inseriu alguma forma de cabeçalho, especificando a finalidadedaquela aplicação, o nome da máquina, o grupo que pertence, o domínio... Agora afinalidade é enviar tudo isto para o meio físico, o que é preparado pelo protocolo NetBEUIe 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 adotadapara estabelecer alguma divisão de forma lógica é através de GRUPO DE TRABALHO (paracompartilhamento) 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 grupospodem ser acessadas escolhendo o grupo correspondente.

As máquinas controladoras de domínio, rodando Windows NT Server ou equivalente, usamdiretórios compartilhados para armazenar informações para todo o domínio, concebendouma administração única. Há dois tipos de controladores:

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

• Os controladores de domínio de backup (BDC - Backup Domain Controller), quemantém uma cópia do banco de dados do PDC através de mecanismos desincronizaçã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 elaspertencem. 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 viamodem).

Os nomes são propagados através de frames tipo broadcast, enviados periodicamente porcada máquina (talvez a eficiência esteja aqui!). Todas as máquinas recebem aquele frame evão, assim, atualizando suas tabelas contendo as máquinas "vivas" na rede e os recursosque 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 aoservidor de nomes NetBIOS (servidores WINS - Windows Internet Name Server)onde os nomes estão registrados e resolvidos. Este tip de nó existirá se otransporte NetBIOS estiver encapsulado (envolvido) pelo protocolo TCP/IP.

• m-node -- usam broadcast para o registro de nomes; para resolver os nomes estasmáquinas tentam os frames de broadcast (b-node), e no caso de não receberemresposta, 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 WINSsão do tipo h-node.

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

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

3 Protocolo IPX

3.1 INTRODUÇÃO

O protocolo IPX (Internetwork Packet Exchange) foi desenvolvido pela NOVELL e é oprotocolo de rede padrão para redes NETWARE. Estas redes usam uma variedade deprotocolos, sendo muitos destes desenvolvidos especialmente para redes Netware ebaseados no protocolo da Xerox, o XNS (Xerox Network System). De fato, os dois sãoquase 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 (ouInternetwork Datagram Packet). O XNS inclui protocolos para aplicações com propósitosespeciais como a manipulação de mensagens enquanto o NetWare usa, apenas, algumasfunções básicas ignorando o resto.

Neste modelo de rede, todas as transações entre máquinas são autenticadas e verificadaspela 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 é apresentadoabaixo.




3.2.1 PROTOCOLO IPX

O IPX é o protocolo freqüentemente associado com redes NetWare e restabelece a partelógica da arquitetura, proporcionando as funções de "rede". O IPX caminha nos váriossegmentos 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 derede. A parte de rede é um número hexadecimal de 32 bits representado numa cadeia decaracteres 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á estaparcela de endereçamento a partir do servidor ou do roteador, durante a fase deinicialização e a associará ao endereço de hardware existente (MAC). Se não existir umservidor Netware então o roteador alimentará a rede com esta informação, caso contrário aidentidade 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 sistemaspodem se comunicar diretamente em uma mesma rede física, sem se preocupar com oendereço de rede. Se o sistema de destino é uma máquina de uma rede remota então odado é direcionado para o roteador e este tratará do envio para o segmento de redeadequado.

OBS: O IPX não garante o envio, ou proporciona serviços de correção ou detecção deerros. Estas funções são de responsabilidade da camada de transporte (o SPX ePEP).

3.2.2 PROTOCOLO SPX

O SPX (Sequenced Packet Exchange) é um protocolo de transporte confiável que usa o IPXpara 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 umproduto de antivírus. Ao invés da aplicação cliente ler diretamente um arquivo armazenadono 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 oregistro (informação), através de comandos enviados e envolvidos pelo SPX.

O SPX trata esta conectividade como circuitos virtuais, que proporcionam conexões entreaplicaçõ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 oconjunto será retransmitido. Caso o recebimento tenha sucesso, então a máquina de origemrecebe uma confirmação de todo o conjunto. A confirmação individual dos pacotes é feitapelo protocolo PEP. O mecanismo adotado no SPX permite o fluxo de uma grandequantidade 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 qualos 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. OPEP é usado, exclusivamente, para o envio dos pacotes NCP usados para a leitura e escritade 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 umaresposta confirmando a sua chegada. Se o tempo expira, o PEP remonta e retransmite opacote e reinicializa a contagem de tempo. Este tratamento (handshake) e esperaconsomem uma grande banda de passagem da rede, mas garante, de forma absoluta, queo pacote foi enviado e recebido. Em pequenas redes locais (mesma rede física e pequenonúmero de máquinas) este tratamento passa desapercebido, mas em redes grandes oucomplexas a queda do desempenho é sensivelmente prejudicado quando envolve grandesperí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çãoou serviço (NCP, SAP, RIP, etc). Se o serviço não for o SAP, o pacote é envolvido peloprotocolo de transporte correspondente (PEP e SPX). O serviço SAP, como veremos, nãousa 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 eorígem do pacote IPX. Se o destino for uma máquina de outra rede uma função deroteameno é 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 filasde entrada do IPX que analisará o destino do pacote. Caso o pacote apresente uma redede destino diferente daquela interface recebida, estabelece-se o roteamento IPX. Nãohavendo identificação do serviço SAP, o pactote é direcinoado para a camada de SPX ouPEP que estabelecem o mecanismo de confirmação de recebimento, e automaticamentedirecionado para o serviço final. Tratando-se de um acesso a arquivo, a aplicação tratará defazê-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: aprimeira identifica a rede Netware e é composto por 24 bits (representados na formahexadecimal, e valor entre 1 e FFFFFFFF. A segunda parte contém 6 bytes ecorresponde ao endereço MAC (Media Access Control). Todos as máquinas quepertencem ao mesmo segmento lógico possuem o mesmo endereço de rede.

Endereço de

Rede

Endereço do

Host

00000001 00:5F:68:4D:2A:43

00000001:00:5F:68:4D:2A:43

3.4 SERVIÇOS




SAP

O protocolo SAP (Service Advertising Protocol) habilita os nós provedores deserviço -- tais como servidores de arquivos, servidores de impressão, servidores deroteamento, e servidores de aplicação -- anunciarem seus serviços e endereços. OSAP realiza a tarefa de adicionar e remover serviços na dinâmica entre redes.Como os servidores estão ativos, eles anunciam seus serviços usando SAP.Durante a fase de "shutdown" eles anunciam que seus serviços não estarão maisdisponíveis. Os recursos disponibilizados são, normalmente, identificados pornomes. O SAP traduz tais nomes para os endereços das máquinas que osdisponibiliza

Propagação do SAP

Através do SAP, os clientes de uma rede podem identificar quais serviços estãodisponíveis e obtém o endereço dos servidores de onde eles podem acessaraqueles serviços. Isto é uma função importante porque uma estação não podeiniciar uma sessão com um provedor de serviço sem que ela (estação) conheça oendereço físico do servidor.

Um servidor gateway, por exemplo, propagará pacotes SAP em cada 60 segundos(o período é definido para todos os servidores que anunciam via SAP) para ossegmentos de rede aos quais está conectado. O agente SAP em cada roteadordaquele segmento copia a informação contida no pacote SAP para uma tabelainterna do servidor gateway. Uma vez que em cada roteador o agente SAP mantéma informação sempre atualizada, um cliente que precise localizar um servidorgateway pode acessar o roteador mais próximo para obter o endereço IPX correto.

O SAP é realmente um protocolo da camada de aplicação, mas não usa qualquerprotocolo de transporte (nem o PEP nem o SPX.) O envio é feito diretamente noIPX. Na verdade, o SPX usa o SAP para localizar os servidores pelos seus nomesao invés de seus endereços físicos.

Quando um cliente precisa localizar um periférico (ou serviço) pelo nome, ele questiona oservidor SAP mais próximo. Estas solicitações podem ser para um servidor Netware, oupara um servidor de aplicações usando o SPX.




RIP

O protocolo de roteamento (Routing Information Protocol) facilita o intercâmbio deinformações de rotas numa rede Netware. Assim como o IPX, o protocolo RIP temorigem do XNS. Entretanto, um campo extra, "número de saltos", foi adicionado àestrutura dos pacotes para melhorar o critério de decisão quando na seleção da rotamais rápida para o destino do pacote. A inclusão deste campo proíbe umaintegração do RIP de Netware com a implementação do XNS.

Propagação RIP

A propagação de pacotes RIP permitem que:

• As estações localizarem a rota mais rápida para aquele número de rede;• Roteadores solicitem informações de outros roteadores para atualizarem suas

próprias tabelas internas;• Roteadores respondam às solicitações de estações e de outros roteadores;• Roteadores tenham certeza de que todos os roteadores estão compatíveis

com a configuração das redes envolvidas;• Roteadores detectem as modificações na configuração das redes.

Os roteadores também enviam pacotes RIP cada 60 segundos, assim em poucosminutos cada roteador da rede reconhecerá a existência de outros roteadores esobre as redes acopladas a eles. Se um roteador deixa de enviar suas tabelas deatualizações, o outro roteador assume que o primeiro está desligado e o remove detabelas de roteamento. .




NLSP

Como no tráfego do SAP, o protocolo RIP pode sobrecarregar o tráfego da redequando esta é complexa ou grande demais. Em redes pequenas ou médias, estasatualizações constantes não induzem grandes tratamentos, mas em grandes redes ,a troca constante dos mapas de roteamento pode se tornar problemáticos.

Para resolver este problema, a Novell desenvolveu um protocolo de estado deroteamento denominado NLSP (Netware Link State Protocol) que trabalha de formabem mais eficiente em grandes redes. Ao invés dos roteadores anunciarem suasinformações sobre cada rede ou roteador conhecidos, é anunciado apenas as rotasconhecidas (invés de todos os roteadores conhecidos pela rede), e somente quandoocorrer uma modificação nas rotas. Ao usar o NLSP reduz-se a quantidade debanda exigida para os serviços de roteamento e de anúncios de serviços. .

NCP

O Netware Core Protocol (NCP) define o controle da conexão e dos códigos derequisição de serviço que tornam possíveis a interação entre clientes e servidores.

O serviço NCP disponibiliza um "dicionário" de comandos de rede associados àsoperações de I/O e corresponde ao coração do sistema de arquivos de servidoresNetware. Os comandos padrões do NCP atuam para a abertura de arquivos, leiturae escrita, etc.

Se um cliente deseja abrir um arquivo no servidor, o cliente Netware intercepta ocomando de sistema e o converte para o comando equivalente NCP e o envia parao servidor. O Servidor recebe aquele comando, abre o arquivo, e envia somente ainformação desejada para o cliente. Desta forma, um cliente Netware não dependedas funções básicas do sistema operacional, e a rede pode ser otimizada para umconjunto consistente de serviços.

Reparem que nas redes NETWARE o modelo Cliente/Servidor seguido considera aexistência de um "servidor concentrado" e clinte "distribuido". Os clientes não sãoautônomos e tem uma grande dependência do "Servidor". Portanto, neste modelo de redeexiste o sentido "literal" das definições de uma máquina cliente (se prestar algum recursoeste é gerenciado completamente pelo "servidor") e o servidor, o real prestador de serviço.Apesar deste comportamento ser característico (e particular) das redes Novel, é comumdenominarmos de "servidor" algumas máquinas que usam outros protocolos que nãoseguem este modelo de rede (TCP/IP por exemplo que adota um modelo differente!)

Para mais informações sobre roteadores IPX e as funções que eles realizam numa redeNetware, vejam a documentação de redes Netware. Uma boa fonte de referencia estádisponível no site da UNOVERICA de onde foram colhidas estas informações.

http://www.unoverica.com/documentation/ucm/index.html




4 Protocolo TCP/IP

4.1 INTRODUÇÃO

Em 1969, por questões militares, o governo americano iniciava os estudos sobre umprotocolo que atendesse certos requisitos de comunicação. Dentre eles, destacam-se:

1) Grande número de conexões lógicas2) Capacidade de transferencia de mensagens de controle;3) Capacidade de execução remota em batch ou interativo;4) Transferência de arquivos, e5) Independência da Plataforma

Para atender tais requisitos foi criado um grupo de redes que plantariam a semente daInternet. O grupo: Steve Carr da Universidade de Utah, Jeff Rulifson e Bill Duvall da SRI,Steve Crocker e Gerard Deloche da Universidade da Califórnia - Los Angeles (UCLA).(rfc003)

A ARPANET, a rede do sistema de defesa americano, estava começando. Em 1970testavam o RJE e posteriormente o TELNET. Em 1973 estabeleciam os objetivos datransferência de arquivos, o FTP. Até então, existiam uma "meia dúzia de máquinas"interligando centros militares, governamentais e educacionais usando o protocolo TCP/IPainda precário. Em 1980, a ARPANET migrava todas as suas máquinas para uma novaversão do TCP/IP. A migração levou 3 anos e no final deste prazo a ARPANET era divididaem duas grandes redes: A ARPANET para pesquisas, que se tornaria a INTERNET, e aMILNET para os militares (Como será que anda a MILNET? Aderiu à InterNET ou aindapermanece nos secretos corredores de rede dos militares americanos?).

A INTERNET invadiu o mundo encontrando as portas abertas para uma tecnologia que viriaromper todas as fronteiras territoriais. Chegou às casas, escritórios, hospitais, e governos.Com a divulgação da mesma veio novos produtos e ferramentas para transferir e armazenara maior das riquezas, a informação. Surgiram vários outros grupos de estudiosos (oshackers). Uma facção dedicou à entender aquela "formosura de tecnologia". Um outro, alémde entender, buscam romper e assumir o controle das máquinas, das informações, apropriedade e em situações extremas, destruir o que, para ele não tem o mesmo valor deliberdade (os crackers). Supõe-se que tais "estudiosos", sejam hackers ou crackers, são atéfinanciados por empresas concorrentes, governos dominantes ou dominados.

Por isto hoje, o ato de ADMINISTRAR redes não se resume à instalação, configuração e usode aplicações. É preciso entender o ambiente, os protocolos, e proporcionar soluçõestambém no desenvolvimento ou migração de produtos. Configurar sem saber o porquê éabrir portas para invasões ou impedir o funcionamento de uma rede e seu uso.

Neste curso, estudaremos o conjunto de protocolos que compõem o TCP/IP, as camadas eaplicações sob o ponto de vista funcional, porém com um nível de detalhe necessáriovisando a administração e o desenvolvimento de produtos de software.

http://www.dem.inpe.br/rfc/alltxt/rfc003.txt




Um comentário para os "comodistas": Se existe alguma aplicação pronta é porque alguémfez. Usá-la, simplesmente, é tão perverso e perigoso quanto uma bomba relógio ou umaarma desconhecida onde o tiro pode sair pela culatra. Não se busca um expert, masprofissionais 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 origor das atividades das camadas do TCP/IP em relação o modelo OSI, podemos compararos dois protocolos como segue:

TCP/IP OSIAPLICAÇÃO

(NIVEL 7)APRESENTAÇÃO

(NIVEL 6)APLICAÇÃO

SERVIÇOS E CLIENTES(PING, FTP, TELNET, HTTP, DNS, ... ) SESSÃO

(NIVEL 5)

TRANSPORTE(TCP, UDP...)

TRANSPORTE(NIVEL 4)

REDE(IP)

REDE(NÍVEL 3)

ENLACE(NÍVEL 2)

INTERFACELINK (ETHERNET) +FÍSICO

(COAXIAL, PAR-TRANÇADO, FIBRA-ÓTICA...)

FÍSICA(NÍVEL 1)

Cabe, aqui, alguns comentários sobre a distribuição destas camadas. Alguns autores(Douglas E Comer - Internetworking with TCP/IP - VOL.1, e, W Richard Stevens - UnixNetworking Programming - Vol 1) tratam a camada de interface do TCP/IP correspondendoàs camadas de enlace e física do modelo OSI (Níveis 1 e 2), embora nem todas as funçõesdestas camadas possam ser encontradas na camada de interface (tratamento de problemasde hardware tipo colisão ou de envio). Por outro lado, existe um tratamento na camada derede (via ICMP, por exemplo), o que implicaria numa pequena expansão da camada de rededo modelo TCP/IP em direção ao nível de enlace (modelo seguido por Tanembaumm eoutros). A razão pela qual os primeiros autores citados consideram a camada de Interfaceapenas a junção das camadas de enlace e física está no fato de que o acesso aos pacotesdiretamente na camada de interface permite estabelecer um controle mais eficiente atravésde bibliotecas especiais. Uma dessas é a biblioteca libpcap, que implementa o DLPI - DATALINK PROVIDER INTERFACE - usado para aplicações tipo TCPDUMP em diversos

ftp://ftp.ee.lbl.gov/libpcap.tar.gz




sistemas operacionais. O DLPI é um protocolo de interface desenvolvido pela AT&T quefornece os recursos da camada de enlace e não é, oficialmente, integrante do TCP/IP, masacompanha alguns sistemas operacionais.

A STD5A (INTERNET PROTOCOL - DARPA INTERNET PROGRAM - PROTOCOLSPECIFICATION - RFC 791), não compara o TCP/IP com o modelo de referencia OSI.

Numa mesma rede física, a troca de mensagens, datagramas, pacotes e frames entre osnós estabelecem conexões entre os vários níveis (ou camadas), deixando-a transparecerconexões entre as camadas lógicas num nível mais alto. A figura abaixo mostra estasconexõ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 deframes.

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 paraa camada de rede, o datagrama é extraído do frame, analisado, o cabeçalho para identificara rede de destino (e não a máquina). Uma vez conhecida a interface de destino, é montadoum novo datagrama e enviado à ela. Esta, por sua vez, monta o frame adequado para onovo meio físico usando o endereço físico do roteador.

http://www.dem.inpe.br/rfc/std/std5a.txt




O tratamento do TCP/IP em camadas facilita sua implementação, mas complica naotimização dos procedimentos. Uma boa explicação está no conhecimento dos tamanhosdos dados envolvidos nas passagens entre as camadas. O tamanho de uma mensagem, porexemplo, poderá acarretar em fragmentação desta, considerando o tamanho do frameusado por aquele meio físico. Este tipo de problema foi resolvido na versão mais nova do IP,conhecida como IPv6 ou IPng (New Generation).

4.2.1 CAMADA DE INTERFACE

Adotaremos que a camada de interface englobe funções das camadas de enlace e física deum modelo OSI.

A camada Física (ou nível Físico) prepara o datagrama para o meio na qual a informaçãotrafegará. Ex.: Cabo coaxial, fibra ótica, par trançado, rádio, linhas privativas, etc, o modelode empacotamento dos frames em função deste meio.

E o que notamos neste meio quanto aos sinais que ali circulam?

Notamos sinais de sincronismo, modulações em fase e dados que correspondem aos níveissuperiores. Ou seja, notamos sinais elétricos que excitam os dispositivos ou equipamentos.Não é raro a necessidade de conectarmos um meio físico a outro ou mesmo unir váriosmeios físicos. Os equipamentos que prestam este serviço, sem se preocupar com ainformação transmitida, são os transceivers, repetidores e hubs.

Na parte correspondente à camada de enlace já se observa alguma identificação dasmáquinas e/ou equipamentos envolvidos. Esta identificação é o endereço Ethernet, queconsiste em um conjunto de 6 bytes: os 3 bytes menos significativos identificam o número




da interface da máquina e os 3 bytes mais significativos identificam o fabricante daquelainterface.

00:40:C7:29:4C:F600:40:C7 29:4C:F6FABR. INTERF.

Todas as máquinas com TCP/IP mantém em memória um banco de dados que associa oeste endereço físico ao endereço lógico IP (Tabela ARP). Uma vez que as máquinas nãosinalizam suas presenças na rede, como acontece com os protocolos IPX e NetBEUI, equando um datagrama IP deve ser enviado (Endereço IP fornecido pela aplicação), osoftware TCP/IP prepara um frame de broadcast, ou seja, um endereço "coringa". Oexemplo de um endereço Ethernet: 0A:00:1B:7F:8A:CC . O endereço "coringa" éFF:FF:FF:FF:FF:FF. Quando um frame circula pela rede, todas as máquinas verificam seaquele frame contém o endereço de sua interface. A operação é feita usando umasequencia de operações aritméticas e lógicas entre o endereço de sua interface e oendereço de destino contido naquele frame, ou através de uma comparação, que considerao endereço coringa como um valor válido. Se o resultado for satisfatório então aquele frameé transferido para as filas das camadas superiores.

Por que o endereço FF:FF:FF:FF:FF:FF é coringa?

Sejam A e B dois números quaisquer entre 0 e 255. Tome o B como sendo seu valor dereferencia (qualquer que seja ele!). Calcule a diferença entre eles (em bits). Calcule a funçãoNOT da diferença. Somente o A=255 (0xFF) resulta no próprio valor de B. Teste! O valor0xFF é especial, não?

Por que uma operação tão complicada e não uma mera comparação, ou algo maissimples?

A forma de implementação fica aos cuidados do fabricante. Apenas provamos que o valor255 é muito especial.

Esta camada é a responsável pelo envio dos pacotes para os nós da rede local. Um pacotecom destino para uma outra rede é enviado para o roteador IP, cujo endereço Ethernet ébem identificado e começa com o primeiro byte igual a 0x08. Enviando um frame para08:FF:FF:FF:FF:FF é suficiente para que todos os roteadores da rede local recebam aqueleframe. Para evitar redundâncias e propagação desnecessária de um mesmo frame, oTCP/IP envia um frame tipo broadcast em datagrama IP para o endereço fornecido como"endereço do gateway" requsitando o endereço Ethernet associado à aquele IP. Conseguidoo endereço Ethernet do roteador, já não há um datagrama com endereço IP destinado aoroteador, mas um frame destinado especificamente ao roteador, com o endereço IP do nóde destino.

Toda interface é, para o TCP/IP, como uma fila (ou um buffer) onde será depositado o frameethernet.




4.2.2 CAMADA DE REDE

No protocolo TCP/IP, esta camada de rede trata os datagramas de entrada e saídaseparadamente, logo o IP considera duas partes. A comunicação entre estes procedimentosdenominamos de roteamento (Routing), e é implementado através de um procedimento(mecanismo) de roteamento. No cabeçalho dos datagramas IP identificamos a origem e odestino destes e o tipo de protocolo usado pela camada superior (transporte).

As máquinas são identificadas pelo seu Número IP ou endereço IP. Este número tem umtamanho de 32 bits e é representado, normalmente, na forma decimal byte-a-byte separadopor um "." (ponto). Existem outras notações.

Por exemplo: 192.168.45.10 é a representação de um número IP na forma decimal byte-a-byte. Na forma binária, este número é: 11000000 10101000 00101101 00001010, querepresenta o número decimal: 3232247050 ! As notações em negrito são aceitas pelagrande maioria das aplicações.

A capacidade de roteamento completa não está disponível em todas as implementações doTCP/IP. Quando disponível, estamos, na verdade, empregando a comunicação entre astarefas que analisam os datagramas de entrada e saída. No roteamento, a tarefa IP analisao endereço IP da rede através de operação de uma máscara e não exclusivamente oendereço IP do nó.

Para um datagrama que chega, após a analise de roteamento - se existir - testa-se se oendereço IP do nó de destino coincide com aquele nó. Caso seja confirmado, o datagrama éenviado para a camada do protocolo de transporte correspondente. Caso contrário, odatagrama pode ser descartado ou, na presença de mecanismos de roteamento entreinterfaces, o datagrama é enviado para aquela interface informada pelo mecanismo deroteamento.

4.2.3 CAMADA DE TRANSPORTE

O protocolo IP não disponibiliza qualquer forma de controle. Este controle pode ser realizadoatravés da camada de transporte. Esta camada, portanto, define a forma que os pacotesserão enviados quanto ao controle destes através dos protocolos de transporte. Osprotocolos de transporte podem ser classificados em orientados ou não à conexão. Emboraa tradução "ao pé da letra" seja "orientado" (de connection oriented e connectionless - talvez"desorientada" (:)) ) a idéia passada é "com garantias de conexão ou com controle daconexão" e "sem garantias de conexão ou sem controle de conexão".

Um protocolo é dito "sem garantia" ou "não orientado à conexão" quando o pedido deconexão de uma máquina para a outra pode ser aceito, estabelecido e a transferencia dainformação realizada, contudo, não há mecanismo que sinalize o recebimento,estabelecimento ou transferência da informação. Para este tipo de comportamento foramdefinidos vários protocolos. Exemplo: UDP (User Datagram Protocol), e RIP (RoutingInternet Protocol). O próprio IP (protocolo de rede ou Internet Protocol) não garante queaquele pacote chegará ou se foi recebido pelo destinatário.




O protocolo dito "orientado" ou "com garantia" quando o envio do pacote de uma máquinapara a outra é verificado se foi aceito e estabelecido, e se a transferencia da informação foirealizada com sucesso. Ou seja, há confirmação quanto ao recebimento da informação e daconexão propriamente dita. Para este tipo de conexão utilizamos o protocolo TCP(Transmission Control Protocol) que implementa um conjunto de controle: tempo, seqüência,urgência, etc.O "como" será visto oportunamente.

Esta camada implementa uma interface com a camada de aplicação onde se define umprotocolo de portas. Tais portas são usadas como um sistema de identificação da aplicaçãode origem e destino.

4.2.4 CAMADA DE APLICAÇÃO

Nesta camada estão as aplicações. Estas são identificadas por portas e estão intimamenterelacionadas com o protocolo de transporte utilizado.

O protocolo de Rede TCP/IP implementa o paradigma cliente/servidor. Ou seja, umaaplicação é composta por um software cliente e outro, compatível, denominado softwareservidor. A despeito de outros protocolos, não há uma máquina servidora, mas umamáquina que executa uma aplicação de serviço e, assim, uma conexão se dá entreaplicações e não entre máquinas. Isto implica que uma mesma máquina pode ser usuária(ou cliente) e servidora simultaneamente quando executa o software cliente e servidorconcorrentemente. Uma máquina que executa uma aplicação servidora pode ser cliente deuma outra máquina que executa aquele mesmo tipo de aplicação. Assim não tem muitosentido dizer que a máquina é a "máquina servidora" num sentido genérico ou exclusivocomo no protocolo IPX.

Um software servidor aguarda uma conexão (portanto é executado primeiro) e o clienteinicia esta conexão. O protocolo TCP/IP não possue uma camada de sessão. Assim, acamada de aplicação é responsável por:

• inicio e término das conexões,• estabelecer a lógica ou finalidade daquela aplicação• preparar o ambiente para o protocolo de transporte• tratar das representações (apresentação)• chamar funções de tradução de nomes, e• adequar a ordem dos bytes quando na transferencia binária.

Todas estas atividades seguem um algoritmo bem conhecido e que será estudadoposteriormente.

As aplicações também estabelecem um protocolo de diálogo. Ou seja, para que se exploreos recursos disponibilizados por um software de um serviço é necessário um softwarecliente associado que fale, ou permita que se emule, o diálogo do serviço. O serviço TCP/IPmais popular é o HTTP (Hiper Text Transfer Protocol) (ou WWW, como é "carinhosamente"conhecido). O "diálogo" (ou protocolo HTTP) apresenta poucas opções. Eis algumas delas:PUT, DELETE, GET, UNLINK.




Sim. Um outro serviço muito utilizado (e nem sempre notado) é o de ICMP (Internet ControlMessage Protocol) embora não seja considerado nem um serviço nem um protocolo detransporte. Uma grande maioria das implementações do TCP/IP não apresentam uma formade controle sobre este serviço. Ele é utilizado automaticamente pela camada de rede (IP) epode ser usado para o reconhecimento de máscaras, rotas, etc. A aplicação clienteparcialmente controlável é o PING. Os Sistemas Windows, por exemplo, utilizam somentedo ICMP para o traçado do caminho dos datagramas, conhecido como TRACEROUTE, maseste mesmo serviço pode ser através do protocolo UDP (sistemas UNIX).

4.2.5 SEQUENCIA DE ENCAPSULAMENTOS

No TCP/IP o protocolo de IP (Internet Protocol) sempre estará presente em qualquerdatagrama, (execto nos protocolos ARP e RARP. Cada camada apresenta seu "carimbo" oucabeçalho., como veremos nos capítulos seguintes. Assim como no IPX, há certos serviços(sim, não deixam de ser servços) que não querem um protocolo de transporte. É o caso doprotocolo ICMP (Internet Control Message Protocol).

No envio o DADO (resposta ou solicitação que define a mensagem propriamente dita: onome do usuário, sua senha, o nome de um arquivo, etc). Este dado está associado aoprotocolo da aplicação padronizado. Esta aplicação ou serviço dependerá de algumprotocolo de transporte e este do protocolo de rede, para prováveis roteamentos e,certamente, a identificação dos canais de saída (interface).

4.3 IDENTIFICAÇÃO

A identificação das máquinas é através do endereço IP, como visto na camada de Rede. Asredes lógicas são identificadas através da aplicação da máscara utilizada. Uma vez que arede é identificavel (mesmo que implicita no endereço IP), isto significa que o protocolo éroteável. Estaremos vendo mais detalhes relacionados à identificação no próximo capítulo.




4.4 SERVIÇOS

Os serviços do protocolo TCP/IP estão associados não exclusivamente aos protocolos detransporte mas, também, ao que denominamos de protocolo de portas. As aplicaçõesservidoras são identificadas pela tripla: endereço IP, protocolo de transporte e porta. Algunsprotocolos (roteamento, por exemplo) não usam portas específicas. O protocolo ICMPimplementa um protocolo de identificação de finalidade que se assemelha ao protocolo deportas, como veremos adiante.

5 Encapsulamento De Protocolos

Denominamos de encapsulamento a condição de envolver um protocolo em outro. Osencapsulamentos estão presentes em todas as arquiteturas de protocolos quando oprotocolo de uma camada superior é encapsulado pelo protocolo da camada inferior. Emcertas camadas podemos ter a ocorrência de mais de um encapsulamento.

O mecanismo de encapsulamento de protocolos lógicos pode se basear em:

a) Uso de serviço que tratará da montagem e desmontagem do protocolo interno;b) Uso das interfaces de camadas, criando uma espécie de canal lógico entre máquinas;

Da mesma forma que o TCP é montado sobre o IP, podemos ter, teoricamente, IPX sobreIP, IPX sobre TCP, ou NetBEUI sobre TCP, ou mesmo IP sobre IPX, DECnet sobre TCP,DECnet sobre UDP, IP sobre DECnet, etc.

Este leque de possibilidades permite transportar o protocolo existente numa rede local paraoutras redes remotas usando o protocolo básico que interliga estas suas redes. Desta idéiasurgiram os conceitos de VPN (Virtual Private Network), PPTP (Point-to-Point TunnelingProtocol) dentre outras denominações. De qualquer forma todas elas baseiam-se no fato detransportar um protocolo como dado usando algum outro protocolo como transportador. Asmáquinas que executam ais encapsulamentos são consideradas gateways locais.

OBS: Os exemplos de encapsulamentos citados tem efeito puramente didático e temo objetivo de mostrar as técnicas de encapsulamento e não a existência delas.

5.1 ENCAPSULAMENTO POR-INTERFACE.

No encapsulamento por interface, por exemplo IP sobre IP, um datagrama de uma redelógica IP privativa é encapsulada no protocolo IP de uma rede lógica pública, estabelecendouma espécie de roteamento em túnel IP e aproveitando a interface entre camadas. Nestecaso, um novo cabeçalho IP é criado com destino à máquina remota específica e tendocomo origem o endereço publico da máquina que está "funcionando" como um túnel. Afunção de roteamento é adaptada para criar uma interface lógica (pseudo interface,semelhante à de loopback). Esta interface tem o papel de embutir o datagrama IP original(rede privativa) num datagrama IP com destino à máquina remota. O novo datagrama criado




retorna para o sistema de roteamento IP e segue para a interface necessária. No outro lado,lado da máquina remota, quando a interface recebe o datagrama IP com a origemespecificada, a função de roteamento de por túnel direciona para uma interface tambémespecial, que tratará de remover o datagrama IP interno e devolve-lo para o sistema deroteamento normal. Reparem que neste caso, não encapsulamos um protocolod e redesobre um protocolo de transporte. Alguém poderia explicar o por quê[U1]?

Na figura abaixo, temos uma forma de encapsulamento por interface de IPX sobre IP.

Neste caso, e embora o IP não possua garantias de envio ou recebimento, a interface deprotocolos pode explorar os recursos de controle do protocolo de transporte do IPX (PEP ouSPX), e a Interface de protocolos se comportaria como uma pseudo interface de umhardware para o lado IPX e um pseudo-protocolo de transporte para o IP.

Esta interface de protocolos pode se deslocar até a camada de aplicação do IP.

5.2 ENCAPSULAMENTO POR SERVIÇO (APLICAÇÃO)

No encapsulamento por serviço, as aplicações são projetadas para servir como o elo deligação entre os protocolos. Explorando o caso IPX sobre IP, uma aplicação do IPX seriatambém uma aplicação IP, extraindo a mensagem de um protocolo e transferindo-a para ooutro.




Especial atenção deve ser dada ao NETBIOS sobre TCP. Neste caso a aplicaçãoimplementa os serviços propriamente ditos como uma aplicação normal não havendoqualquer transferencia ou roteamento de qualquer espécie.

6 Exercícios *

1. Vimos alguns protocolos de comunicação. Descreva os motivos pelos quais umequipamento que adote um protocolo físico e um certo protocolo lógico não é capaz dese comunicar com outra máquina configurada para usar um mesmo protocolo físicoporém com um protocolo lógico diferente.

2. Para confirmar sua resposta na questão anterior, considere duas máquinas A e B querodam de exclusivamente os protocolos NetBEUI e TCP/IP, respectivamente. Definepara esta última o endereço IP 192.168.10.20. Anote o endereço ethernet da máquina"A" que usa o protocolo NetBEUI. Na máquina com o TCP/IP, máquina B, carregue atabela ARP com o endereço físico da de "A" associando o endereço IP 192.168.10.30para a máquina "A". Usando um comando PING (ping 192.168.10.30) envie um frameethernet para a máquina não TCP. Com a ajuda de um software de captura de frames(TCPDUMP, SNOOP ou MS-Network Monitor) verifique se o datagrama IP foi enviadopara a rede. A máquina "A" reconheceu o pacote? A máquina com NetBEUI vê a deTCP/IP no ambiente de rede?

3. Repita o mesmo com a máquina A e B rodando somente o TCP/IP e com os endereçoscitados. E agora? Houve a transmissão e recebimento do datagrama?

4. Repita com o NetBEUI nas duas máquinas. As máquinas se vêem mutuamente? Porquê? Experimente modificar a identificação do grupo de trabalho. Elas continuam sevendo?

Page: 88[U1]Se temos IP sobre IP, já estamos encapsulando o protocolo de transporte entre as duasmáquinas. O protocolo de transporte mais interno em uso implementa o controle da conexão.

CAP258 - Redes de Computadores e Comunicação de Dados · tecnologia de redes Token-Ring. 2.2.2...

Documents

Transcript of CAP258 - Redes de Computadores e Comunicação de Dados · tecnologia de redes Token-Ring. 2.2.2...