You are on page 1of 89

Coordenadoria do Curso de Ci encia da Computa c ao Universidade Estadual de Mato Grosso do Sul

Implementa c ao de Protocolos da Pilha TCP/IP

Grasielly Mayumi Suguimoto Luana Kaku Aguiar

Prof. Dr. Fabr cio S ergio de Paula(Orientador)

Dezembro de 2011

Implementa c ao de Protocolos da Pilha TCP/IP

Grasielly Mayumi Suguimoto Luana Kaku Aguiar

Este exemplar corresponde a ` reda ca o nal da monograa da disciplina Projeto Final de Curso devidamente corrigida e defendida por Grasielly Mayumi Suguimoto Luana Kaku Aguiar e aprovada pela Banca Examinadora, como parte dos requisitos para a obten ca o do t tulo de Bacharel em Ci encia da Computa c ao.

Dourados, 12 de dezembro de 2011.

Prof. Dr. Fabr cio S ergio de Paula (Orientador)

ii

Coordenadoria do Curso de Ci encia da Computa c ao Universidade Estadual de Mato Grosso do Sul

Implementa c ao de Protocolos da Pilha TCP/IP

Grasielly Mayumi Suguimoto Luana Kaku Aguiar


Dezembro de 2011

Banca Examinadora: Prof. Dr. Fabr cio S ergio de Paula (Orientador) Prof. Dr. Nilton C ezar de Paula Prof. Msc. Delair Osvaldo Martinelli J unior

iii

Resumo
A pilha de protocolos TCP/IP e considerada um padr ao mundial para interconex ao de rede, podendo ser executada em in umeros dispositivos tecnol ogicos ligados a esta rede. Apesar de serem amplamente difundidos, poucos conhecem os detalhes que d ao suporte a uma conex ao de rede, tornando o entendimento abstrato. Visando a necessidade de entender os detalhes do funcionamento da pilha TCP/IP, este projeto realizou o estudo detalhado dos protocolos IP, TCP e UDP, para que se pudesse ter o conhecimento necess ario para a sua implementa c ao, demonstrando o seu funcionamento em um ambiente simulado. A implementa c ao foi realizada em um sistema operacional Windows, na linguagem C/C++, utilizando pthreads para representar as m aquinas. Foram criados procedimentos espec cos para simular o envio e recebimento de mensagens na rede atrav es dos protocolos, sendo que apenas partes das funcionalidades destes protocolos foram desenvolvidas neste projeto. Palavras-chave: TCP, IP, protocolos.

iv

Abstract
The protocol stack TCP/IP is considered a worldwide standard for the interconnection network, this stack can be executed in numerous technological devices connected to this network. Although widely distributed, few know the details that support a network connection, making the abstract understanding. Aiming the need to understand the details of the operation of TCP/IP stack, this project conducted a detailed study of IP, TCP and UDP protocols, so we could have the knowledge necessary for its implementation, demonstrating its operation in a simulated environment . The implementation was performed on a Windows operating system, in C/C++ language, using pthreads to represent the machines. Specic procedures were developed to simulate the sending and receiving messages through the network protocols, and only parts of the functionality of these protocols were developed in this project. Keywords: TCP, IP, protocol.

Agradecimentos
Eu agrade co primeiramente a Deus, por estar do meu lado nos momentos mais dif ceis, ter me dado for ca e a chance de completar mais essa etapa. A minha fam lia, principalmente aos meus pais, Aurea e Sigueo, por sempre conar e acreditar na naliza ca o dessa fase com sucesso. Aos meus professores, principalmente ao professor-orientador Fabr cio S ergio de Paula, pela orienta ca o sempre dispon vel, no qual foi de suma import ancia para a conclus ao desse projeto. Aos meus amigos presentes no meu dia-a-dia, em especial a Franciely, por sempre ter me dado apoio e palavras de conforto nas horas dif ceis e de tens ao. Aos meus amigos da faculdade, presentes todos esses anos, Luana, Aline, Tiago e Luiz Augusto, por compartilharem todos os momentos felizes e tristes. Grasielly Mayumi Suguimoto Agrade co primeiramente a Deus, que sempre me deu mais do que precisei e que mais uma vez me ajudou a superar obst aculos e a conseguir encerrar esta etapa de minha vida. Aos meus pais, Vando e Angela, pela fam lia maravilhosa que constru ram que e meu pilar. Por lutarem e fazerem sacrif cios para que eu pudesse concluir a faculdade, pelo apoio incondicional, por acreditarem e me incentivarem. Por escutarem minhas reclama co es, mesmo quando tinham verdadeiros motivos para reclamarem. Por nunca reclamarem. Pelo amor que sempre recebi. E por todas as outras raz oes que me fazem am a-los. ` A Aline e ao Fernando, por me fazerem rir, por me apoiarem, por demostrarem orgulho por mim e por simplesmente serem meus irm aos que amo muito. Aos meus av os, Mikivo, Leopoldina e Lindolfo, pelo carinho que sempre mostraram, pelo incentivo e apoio. Aos amigos como Aline, Amanda, Ca, Danny, Fl avia, Graciela, Grasi, Grasy, K a, Mary, Pri, Si, Thaty e Tiago, que me ajudaram a n ao enlouquecer durante esta fase. Ao meu orientador, professor Fabr cio S ergio de Paula, que apoiou a Grasy e a mim, teve paci encia e bondade ao nos ensinar, nos incentivou a continuar e a sempre melhorar e que se dedicou mais do que sua obriga ca o exigia para que assim pud essemos conseguir. Luana Kaku Aguiar vi

Sum ario
Resumo Abstract Agradecimentos 1 Introdu c ao 1.1 Objetivo . . . . . . . . . . . 1.1.1 Objetivo Geral . . . 1.1.2 Objetivos Espec cos 1.2 Justicativa e Motiva ca o . . 1.3 Metodologia . . . . . . . . . 1.4 Organiza ca o do Texto . . . 2 Arquitetura de Rede 2.1 Modelo OSI . . . . . . 2.2 Modelo TCP/IP . . . . 2.2.1 Protocolo IP . . 2.2.2 Protocolo UDP 2.2.3 Protocolo TCP iv v vi 2 3 3 3 3 4 4 6 6 7 9 16 18 27 27 28 29 30 31 32 33 33

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

3 Processos e Threads 3.1 Processos . . . . . . . . . . . . . . . . . 3.1.1 Escalonamento de processos . . . 3.1.2 Cria ca o e termina ca o de processos 3.1.3 Processos cooperativos . . . . . . 3.1.4 Sincroniza ca o de processos . . . . 3.2 Threads . . . . . . . . . . . . . . . . . . 3.2.1 Sincroniza ca o de threads . . . . . 3.2.2 Pthread . . . . . . . . . . . . . . vii

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

4 Prot otipo 4.1 Estrutura de dados . . . . . . . . . . . . . . 4.1.1 Estrutura My socket . . . . . . . . . 4.1.2 Estrutura do protocolo da camada de 4.1.3 Estrutura do protocolo da camada de 4.2 Fun c oes para comunica c ao . . . . . . . . . .

. . . . . . . . . . . . transporte rede . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

35 35 36 36 37 37

5 Testes do prot otipo 43 5.1 Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 5.1.1 Teste 1: Dados sem fragmenta ca o . . . . . . . . . . . . . . . . . . . 43 5.1.2 Teste 2: Dados com fragmenta c ao . . . . . . . . . . . . . . . . . . . 46 6 Considera c oes Finais A Principais fun c oes implementadas 55 57

viii

Lista de Tabelas
2.1 Os estados usados na m aquina de estado. Fonte: Tanenbaum (2003) . . . . 25

ix

Lista de Figuras
2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 Modelo OSI. Fonte: Forouzan (2000) . . . . . . . . . . . . . . . . . . . . . Modelo TCP/IP. Fonte: Forouzan (2000) . . . . . . . . . . . . . . . . . . . Transmiss ao usando modelo da Internet. Fonte: Forouzan (2000) . . . . . . Formato de um datagrama IPv4. Fonte: Forouzan (2000) . . . . . . . . . . Cabe calho IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (a) 4 redes e 3 roteadores; (b) tabela de roteamento em R. Fonte: Comer (2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formato de mensagem ICMP. Fonte: Forouzan (2000) . . . . . . . . . . . . Mensagem ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formato do cabe calho UDP. Fonte: Forouzan (2000) . . . . . . . . . . . . . Pseudo-cabe calho do checksum. Fonte: Forouzan (2000) . . . . . . . . . . Cabe calho UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . (a) Janela deslizante do protocolo com oito pacotes; (b) Ao receber a conrma ca o do pacote 1, a janela deslizante envia at e o pacote 9. Fonte: Comer (2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Formato do segmento TCP. Fonte: Forouzan (2000) . . . . . . . . . . . . . Cabe calho TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Estabelecimento de conex ao. Fonte: Comer (2006) . . . . . . . . . . . . . . Encerrando conex ao. Fonte: Comer (2006) . . . . . . . . . . . . . . . . . . M aquina de estados nitos usada no gerenciamento de uma conex ao TCP. Fonte: Tanenbaum (2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . (a) Rede r apida alimentando um receptor de pequena capacidade. (b) Rede lenta alimentando um receptor de grande capacidade. Fonte: Tanenbaum (2003) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8 9 10 12 13 14 15 16 17 17

2.13 2.14 2.15 2.16 2.17 2.18

19 20 21 22 23 24

26

3.1 3.2 4.1 4.2

Bloco de controle de processo. Fonte: Siberschatz (2004) . . . . . . . . . . 27 Opera co es wait e signal. Fonte Siberschatz (2004) . . . . . . . . . . . . . . 31 Estrutura de dados My socket . . . . . . . . . . . . . . . . . . . . . . . . . 36 Estrutura de dados do protocolo UDP . . . . . . . . . . . . . . . . . . . . 36 x

4.3 4.4 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10

Estrutura de dados do protocolo TCP . . . . . . . . . . . . . . . . . . . . . 37 Estrutura de dados do protocolo IP . . . . . . . . . . . . . . . . . . . . . . 38 Dados enviados a ` camada de transporte (UDP) . . . Dados enviados a ` camada de rede (IP) . . . . . . . . Dados enviados a ` camada enlace . . . . . . . . . . . . Dados enviados a ` camada de transporte (UDP) . . . Fragmento 1: Dados enviados a ` camada de rede (IP) Fragmento 2: Dados enviados a ` camada de rede (IP) Fragmento 3: Dados enviados a ` camada de rede (IP) Fragmento 1: Dados enviados a ` camada de enlace . . Fragmento 2: Dados enviados a ` camada de enlace . . Fragmento 3: Dados enviados a ` camada de enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 44 45 49 49 50 50 50 50 50

xi

Lista de Siglas e Abreviaturas

ACK API CPU DF FCFS FIN HLEN ICMP IP IPC ISO KLT MF MTU IP OSI PAR PCB PSH RR RST SJF SO SYN TCP UDP ULT URG

Acknowledgement number Application Programming Interface Central Processing Unit Dont Fragment First Come, First Served Finalize Header Length Internet Control Message Protocol Internet Protocol Inter Process Communication International Standards Organization Kernel-Level Thread More Fragment Maximum Transfer Unit do Internet Protocol Open System Interconnection Positive Acknowledgement with Retransmition Process Control Block Push Round-Robin Reset Shortest Job First System Operation Synchronie Transport Controll Protocol User Datagram Protocol User-Level Thread Urgent Pointer

Cap tulo 1 Introdu c ao


A import ancia das redes de computadores comumente chamadas de Internet aumentou drasticamente desde sua cria ca o em meados dos anos 70. O que era para ser apenas uma forma segura de comunica ca o, para o governo norte-americano durante a Guerra-Fria, expandiu e tornou-se o meio mais utilizado de comunica ca o, de busca de informa c ao e de transfer encia de dados. Um aspecto relevante que proporcionou a amplia ca o da rede de computadores, foi o avan co tecnol ogico do hardware, que facilitou as pessoas obterem o computador pessoal (Desktop), j a que este estava mais barato e menor. Devido a estes fatores, mais pessoas se conectavam atrav es desta rede. Atualmente, a Internet e parte fundamental da vida das pessoas, pois a diversidade nela encontrada cont em in umeros tipos de informa co es como not cias, esportes, economia, pol tica, etc. A sua utiliza c ao inuenciou uma nova forma de pensar para a sociedade em geral, gra cas a ` interconex ao de rede, a dist ancia j a n ao e mais a mesma, assim como a forma de trabalho, estudo, armazenamento de dados e demais aspectos tamb em n ao os s ao, ou seja, a Internet moldou-se as necessidades do mundo globalizado. N ao h a d uvida que ela est a inserida no cotidiano das pessoas e que hoje em dia n ao se vive sem Internet. Desde o come co da utiliza c ao da Internet, a comunica ca o entre os computadores era feita por protocolos comuns, em redes homog eneas ou heterog eneas, no qual, estes protocolos garantiam o envio dos pacotes. Ao longo dos anos, v arios protocolos foram desenvolvidos, e para a interliga ca o na rede mundial, foi utilizada a pilha de protocolos universalmente padronizada para acesso, o Transmission Control Protocol/ Internet Protocol (TCP/IP). Segundo Comer (2006), a tecnologia TCP/IP e interessante porque ela forma a tecnologia b asica da Internet global, que conecta mais de 650 milh oes de indiv duos em lares, escolas, corpora co es e laborat orios do governo em praticamente todas as areas povoadas. Um sucesso fant astico, a Internet demonstra viabilidade da tecnologia TCP/IP e mostra 2

1.1. Objetivo

como ela pode acomodar uma grande variedade de tecnologias de hardware b asicas.

1.1
1.1.1

Objetivo
Objetivo Geral

Este projeto tem como objetivo principal a implementa ca o de alguns protocolos da pilha TCP/IP, para simular um ambiente de comunica ca o, demonstrando o seu funcionamento, como o envio e recebimento dos pacotes feitos atrav es da rede e como estes protocolos sabem para qual computador enviar os dados. Embora n ao haja nenhuma melhoria ou inova c ao na comunica c ao em rede, este projeto possibilita um melhor entendimento nos conceitos e funcionalidades de uma rede. A implementa ca o exemplicada e para ns did aticos.

1.1.2

Objetivos Espec cos

Para tanto, e necess ario conhecer sobre a especica ca o e funcionamento desses protocolos, bem como as ferramentas utilizadas no processo de desenvolvimento. Para alcan car o objetivo principal, ser ao desenvolvidas as seguintes atividade: Pesquisa sobre arquitetura TCP/IP; Estudo aprofundado dos protocolos IP, UDP, TCP; Deni ca o de um ambiente de implementa c ao e simula ca o de comunica ca o; Implementa ca o dos protocolos de comunica c ao estudados; Testes em um ambiente simulado.

1.2

Justicativa e Motiva c ao

Como citado anteriormente, os protocolos da pilha TCP/IP s ao os mais utilizados para promover a comunica c ao na rede. Por esta raz ao, foram escolhidos os protocolos IP, UDP e TCP, para simular um ambiente de comunica c ao. Tamb em foi pensando em auxiliar o estudo did atico da disciplina de Redes de Computadores, mostrando o funcionamento dos protocolos de uma forma pr atica para melhor entendimento.

1.3. Metodologia

1.3

Metodologia

Este projeto contou com o acesso aos recursos computacionais da Universidade Estadual de Mato Grosso do Sul (UEMS). Foram utilizadas ferramentas/bibliotecas de software livre, que s ao distribu das gratuitamente na Internet e podem ser adaptadas de acordo com os requisitos da pesquisa. As fontes de refer encias bibliogr acas incluem artigos dispon veis na Internet, e o acesso a `s bibliotecas da UEMS e UFGD. Foram realizadas reuni oes peri odicas, visando apresentar e discutir os estudos realizados e o progresso alcan cado. Para a implementa c ao foi realizada no sistema operacional Windows, na linguagem C/C++.

1.4

Organiza c ao do Texto

O texto do projeto est a organizado em um u nico volume, contendo neste cap tulo a introdu ca o, a apresenta ca o dos objetivos, a juticativa e motiva c ao e metodologia. Al em desse cap tulo, o volume e organizado em outros 5 cap tulos e o ap endice A, cujos conte udos s ao sumarizados a seguir. Cap tulo 2

Arquitetura de Rede
No Cap tulo 2 e feito uma introdu c ao dos conceitos dos dois principais modelos de arquitetura de rede, o modelo de refer encia OSI, que e dado uma breve explica ca o e o modelo de refer encia TCP/IP, que e mais enfatizado, explicando a pilha de protocolos TCP/IP, contendo as suas deni c oes, formatos e funcionalidades. Cap tulo 3

Processos e Threads
No Cap tulo 3 e feita uma explana ca o sobre processos e threads. A import ancia deste cap tulo deve-se ao fato de serem utilizados threads para a implementa c ao do programa em desenvolvimento, e apresenta as caracter sticas e benef cios do seu uso. Cap tulo 4

Prot otipo
No Cap tulo 4 e apresentada as estruturas de dados dos protocolos de transporte e rede, e as fun c oes que simulam a comunica c ao dos protocolos em uma rede.

1.4. Organiza ca o do Texto

Cap tulo 5

Testes do prot otipo


No cap tulo 5 e apresentado os testes do algoritmo desenvolvido neste projeto. Cap tulo 6

Considera co es Finais
O cap tulo 6 e nalizado com a conclus ao do projeto e sugest oes para trabalhos futuros. Ap endice A

Principais fun c oes implementadas


O ap endice A apresenta o c odigo-fonte das principais fun co es que realiza a comunica ca o entre as m aquinas.

Cap tulo 2 Arquitetura de Rede


Segundo Tanenbaum (2003), a maioria das redes e organizada como uma pilha de camadas ou n veis, colocadas umas sobre as outras. No entanto, em todas as redes o objetivo de cada camada e oferecer determinados servi cos ` as camadas superiores, isolando essas camadas dos detalhes de implementa ca o desses recursos. Um conjunto de camadas e protocolos e chamado arquitetura de rede. A especica c ao de uma arquitetura deve conter informa co es sucientes para permitir que um implementador desenvolva o programa ou construa o hardware de cada camada, de forma que ela obede ca corretamente ao protocolo adequado. Os dois principais modelos de arquitetura de rede s ao: o modelo de refer encia OSI (Open System Interconnection) e o modelo de refer encia TCP/IP (Transmission Control Protocol/ Internet Protocol). Esses modelos ser ao explicados neste cap tulo, mas este projeto se basear a apenas no modelo TCP/IP.

2.1

Modelo OSI

O modelo de refer encia OSI, de acordo com Forouzan (2000), foi desenvolvido pela ISO (International Standards Organization), com o intuito de padronizar a comunica c ao na rede de sistemas abertos, ou seja, sistemas com arquiteturas diferentes, que n ao requer modica c oes l ogicas, tanto do ponto de vista do hardware quanto do software. Este modelo, como mostra a gura 2.1, possui sete camadas, onde cada camada possui suas fun c oes a serem executadas: Camada F sica: trata do meio f sico espec co a ser utilizado, onde sua fun ca o principal e a transmiss ao de sequ encias de bits pelo meio f sico; Camada de Enlace de Dados: converte os dados n ao con aveis oriundos da camada f sica e prov e meio de transmiss ao con avel ` a camada de rede e tem a fun ca o de 6

2.2. Modelo TCP/IP

Figura 2.1: Modelo OSI. Fonte: Forouzan (2000) detectar e opcionalmente corrigir esses erros; Camada de Rede: prov e o roteamento dos pacotes da origem ao destino, independente do n umero de redes; Camada de Transporte: trata da transfer encia de dados transparentes, isolando as camadas superiores dos detalhes de transmiss ao da rede e da sub-rede; Camada de Sess ao: estabelece e mant em o sincronismo da intera c ao entre sistemas de comunica ca o; Camada de Apresenta c ao: cuida da transpar encia da sintaxe e sem antica das informa co es trocadas entre dois sistemas; Camada de Aplica c ao: desempenha as fun co es especicas de utiliza ca o dos sistemas, tais como e-mail, acesso e transfer encia de arquivos, log-in remoto e assim por diante.

2.2

Modelo TCP/IP

O modelo TCP/IP, foi desenvolvido com o objetivo de conectar v arias redes uniformemente, independente da congura c ao do hardware usado nos computadores. Para realizar a divis ao em camadas, como acontece no modelo TCP/IP, os projetistas vericaram quais fun c oes da rede possu am algum correlacionamento e as dividiram em cinco grupos. Cada grupo possui caracter sticas diferentes dos demais.

2.2. Modelo TCP/IP

O TCP/IP e ex vel e suporta erros, como a perda de hardware em suas sub-redes. Atrav es dos protocolos, a comunica ca o entre dois ou mais sistemas e feita. Estas camadas da pilha TCP/IP est ao divididas em camada f sica, de enlace de dados, de rede, de transporte, e por m na camada de aplica ca o, como mostra a gura 2.2.

Figura 2.2: Modelo TCP/IP. Fonte: Forouzan (2000) Conforme Forouzan (2000), as camadas do modelo TCP/IP possuem as seguintes funcionalidades: Camada F sica: coordena a transmiss ao de bits em um meio f sico espec co, tamb em determina as especica co es el etricas e mec anicas de uma interface e do meio de transmiss ao; Camada de Enlace de Dados: converte os dados brutos e n ao con aveis recebidos da camada f sica, para poder transmitir sem erros ` a camada de rede. Aqui tamb em e realizada a convers ao dos bits recebidos da camada de rede em unidades de dados gerenci aveis chamadas de frames ou quadros; Camada de Rede: move os pacotes da m aquina de origem a ` m aquina destino. Caso seja necess ario, faz o roteamento dos pacotes em redes distintas; Camada de Transporte: garante a entrega de toda mensagem aos usu arios nais. Os protocolos dessa camada podem ser ou n ao orientados a conex ao; Camada de Aplica c ao: possui os protocolos de n vel mais alto, que fornecem servi cos ao sistema ou ao usu ario. As camadas utilizam servi cos de suas camadas inferiores e prestam servi cos para as camadas superiores. A comunica c ao entre as camadas e realizada por regras, onde cada regras s ao denominadas protocolos.

2.2. Modelo TCP/IP

A gura 2.3, oferece uma vis ao de como ocorre a comunica ca o entre as camadas e a transmiss ao dos dados na rede.

Figura 2.3: Transmiss ao usando modelo da Internet. Fonte: Forouzan (2000) O pacote na camada de aplica ca o, L5, representa o encapsulamento de dados desta camada, j a L4, pacotes na camada de transporte, representa o encapsulamento de dados na camada quatro e assim por diante. Em cada camada, um cabe calho (Header) e adicionado. Assim, os dados de L4 cont em os dados L5 mais o cabe calho H5, por sua vez, os dados de L3 cont em os dados L4 mais o seu cabe calho H4 e assim segue. A camada de enlace de dados, L2, ainda pode adicionar um campo, T2, que tem a fun ca o de controlar/detectar erros nos quadros de dados manipulados por esta camada. Ao chegar a ` camada f sica, L1, os bits dos dados s ao enviados ao meio de transmiss ao. O meio de transmiss ao encaminha para a m aquina receptora, onde a camada f sica far aa recep c ao dos bits e encaminhar a para a camada superior. A camada de enlace de dados, L2, retirar a o cabe calho adicionado neste mesmo n vel no lado do transmissor tomando decis oes necess arias e enviando ao n vel superior, isto ocorre at e que os dados cheguem ao n vel de aplica c ao.

2.2.1

Protocolo IP

De acordo com Comer (2006), o IP (Internet Protocol) e o protocolo da camada de rede. Ele tem como objetivo a interliga ca o de redes, ou seja, e o respons avel em transportar datagramas da origem para o destino entre diversas m aquinas em uma rede, dentro da

2.2. Modelo TCP/IP

10

internet. Uma de suas caracter sticas e o transporte da melhor forma poss vel desses datagramas, por em sem conabilidade, sem garantia de entrega e sem conex ao. Nesse tipo de servi co o pacote pode ser perdido, duplicado, estar fora de ordem ou adiado. O que acontece nesse tipo de servi co e que cada pacote e tratado independente um dos outros, isto e, se a mensagem a ser enviada ao destinat ario possuir um tamanho maior do que a capacidade m axima de cada pacote, ent ao essa mensagem ser a dividida em v arios pacotes, cada pacote e chamado de fragmento, e como s ao independentes, eles podem seguir por rotas diferentes, atrasar ou n ao ser entregues. A vers ao do protocolo IP atualmente e a vers ao 6 (IPv6), que est a sendo implantado gradativamente na internet, portanto, neste projeto, ser a estudado apenas a vers ao 4, o IPv4. O datagrama IP ou simplesmente datagrama e dividido em a reas de cabe calho e dados. Onde o cabe calho e uma parte xa de 20 bytes e uma parte opcional de tamanho vari avel, que cont em os endere cos de origem, destino e a identica ca o do conte udo do datagrama. A gura 2.4 demonstra um exemplo do formato IPv4.

Figura 2.4: Formato de um datagrama IPv4. Fonte: Forouzan (2000) VER: de 4 bits, e a vers ao do protocolo IP usado para criar o datagrama. Nesse campo e vericada a vers ao do protocolo ao processar o datagrama, combinando com o formato que o software espera, caso a vers ao seja diferente do esperado, o datagrama pode ser interpretado de forma errada ou descartado; HLEN: 4 bits, d a o tamanho do cabe calho do datagrama, medindo em palavras de 32 bits; Servi co: 8 bits, e destinado para acomodar um conjunto de servi cos diferenciados, onde os 6 primeiros bits s ao usados para indicar a que classe de servi co pertence cada pacote;

2.2. Modelo TCP/IP

11

Comprimento total: especica o tamanho, em bytes, do pacote, incluindo o cabe calho e dados, caso seja um pacote fragmentado, este campo indicar a o tamanho do fragmento; Identica c ao: cont em um inteiro exclusivo que identica o pacote. Este campo permite que o host de destino identique a qual pacote pertence o fragmento rec em chegado, pois cada fragmento do pacote recebe no campo identica c ao o mesmo valor exclusivo; Flags: de 3 bits, controla a fragmenta ca o. O primeiro bit n ao e utilizado. O segundo bit e denominado N ao fragmentar (DF), que signica que o datagrama n ao pode ser fragmentado, porque a aplica c ao que receber a o datagrama pode ser u til somente se for inteiro ou o host de destino e incapaz de remontar os fragmentos novamente. Nesses casos, o bit N ao fragmentar deve ser marcado. O bit de baixa ordem do campo ags e o Mais fragmentos (MF), todos os fragmentos, exceto o u ltimo, e marcado com esse bit, que signica que enquanto os fragmentos que v ao chegando ao destino estiverem marcados com o bit Mais fragmentos, este n ao eou ltimo; Oset de fragmenta c ao: possui a posi ca o em que cada fragmento ocupa no datagrama original. O destino ao remontar o datagrama precisa de todos os fragmentos, que n ao chegam, necessariamente, em ordem; Tempo de vida: limita o tempo de vida do pacote. Este campo dene um tempo m aximo que o datagrama deve sobreviver, esse tempo come ca a ser decrementado a partir do momento que o datagrama e enviado ao destino, se o tempo expirar, este pacote e descartado; Protocolo: indica qual ser a o protocolo da camada superior, a camada de transporte (TCP ou UDP), que receber a o datagrama que j a est a remontado e completo; Cheksum do cabe calho: garante a integridade dos valores do cabe calho; Endere co IP de origem e endere co IP de destino: identicam o endere co IP, de 32 bits, do emissor e do destinat ario, respectivamente; Op c oes: esse campo possui tamanho vari avel e e uma s erie de op co es que o datagrama pode selecionar, como op c ao de registro de rota, op c oes de rota de origem, op c ao de estampa de tempo, entre outras. Para monstrar um cabe calho IPv4 na pr atica e como e especicado cada campo, foi feito a captura de pacotes usando a ferramenta WireShark (Gerald Combs). E o cabe calho desse pacote capturado e mostra na gura 2.5.

2.2. Modelo TCP/IP

12

Figura 2.5: Cabe calho IPv4 Note que e um cabe calho IP da vers ao 4, com o tamanho do cabe calho (Header lenght) de 20 bytes, o campo de servi co (Dierentiated services eld) e 0x00, destinado para acomodar um conjunto de servi cos, o comprimento total (Total length) do pacote e de 1440 octetos, tem a identica ca o (Identication) 0x60b1, na qual todos os fragmentos de um pacote recebe um valor exclusivo, nas ags, o segundo bit e marcado para n ao fragmentar (Dont fragment), e como n ao e fragmentado, ent ao, o campo oset de fragmenta ca o (Fragment oset) e 0, o tempo de vida (Time to live) do pacote e 128 segundos, o protocolo na qual ser a enviado o pacote e o TCP, o checksum do cabe calho (Header checksum) e vericado e est a tudo correto, e nalmente, o endere co IP de origem (Source) 192.168.1.3 e o endere co IP de destino (Destination) 74.125.234.22. Encaminhamento de datagramas IP Encaminhamento IP e o processo de escolha do caminho por onde o pacote dever a ser enviado. J a o roteador e o sistema que faz essa escolha, ele interconecta v arias redes f sicas e possui conex oes diretas com duas ou mais redes. Cada host e cada roteador possui um endere co IP, que eu nico e exclusivo. E este endere co e dividido em um prexo que identica a rede e um suxo que identica o host. Esse encaminhamento ocorre de duas formas: entrega direta e entrega indireta. A entrega direta ocorre quando a m aquina emissora est a na mesma rede da m aquina receptora. A identica ca o da rede e feita atrav es da extra c ao de parte do endere co IP do destino e comparado com parte do endere co IP do emissor, a correspond encia signica que o datagrama pode ser enviado diretamente. A entrega indireta ocorre quando emissor e receptor n ao est ao na mesma rede. O datagrama e enviado para um roteador mais pr oximo, que envia para a rede de destino. Para auxiliar a comunica c ao entre os hosts e os roteadores, e usada uma tabela de roteamento IP. Assim, quando um host ou um roteador necessita enviar um datagrama,

2.2. Modelo TCP/IP

13

ele consulta a tabela de roteamento, a m de decidir qual rota o datagrama deve seguir. Como as op c oes de destino s ao in umeras, as tabelas teriam muitas informa c oes e cariam muito extensas, para solucionar o problema e usado o princ pio de esconder informa co es e permitir que as m aquinas tomem decis oes de encaminhamento com o m nimo de informa ca o. Normalmente, as tabelas de roteamento cont em pares (N, R), onde N e o endere co IP da rede de destino, e R e o endere co IP do roteador mais pr oximo do caminho at ea rede N. Este roteador R e chamado de pr oximo salto, e ele s o especica uma etapa do caminho, pois o roteador n ao conhece o caminho completo at e o destino. Cada entrada na tabela de roteamento aponta somente para o roteador que pode ser alcan cado por uma rede diretamente. A gura 2.6 ilustra um exemplo de tabela de roteamento, que consiste em quatro redes e tr es roteadores. A tabela corresponde a ` tabela de roteamento para o roteador R, que e conectado diretamente ` as redes 20.0.0.0 e 30.0.0.0, ent ao e feita a entrega direta para um host em uma dessas redes. Agora, para enviar um datagrama para um host na rede 40.0.0.0, o roteador R roteia para o endere co do roteador S, onde e feito a entrega diretamente.

Figura 2.6: (a) 4 redes e 3 roteadores; (b) tabela de roteamento em R. Fonte: Comer (2006) Segundo Comer (2006), no algoritmo original usado para encaminhar datagramas IP,

2.2. Modelo TCP/IP

14

e dado um datagrama e uma tabela de roteamento. Depois de executado o algoritmo de encaminhamento, o IP passa o datagrama e o endere co do pr oximo salto ao software de interface de rede a qual o datagrama precisa ser enviado. Esse software vincula o endere co do pr oximo salto a um endere co f sico, que forma um frame, o datagrama e colocado na parte de dados do frame e o resultado e enviado. O datagrama ao chegar ao host de destino, e entregue ao m odulo IP para processa vericado o endere mento. E co de destino e o endere co IP do host, se forem correspondentes, o datagrama e passado para a camada de n vel superior para processamento. Caso contr ario, o datagrama e descartado pelo host. Mensagem de erro e controle (ICMP) Todo sistema de comunica ca o n ao est a livre de ocorr encia de erros. Podem ocorrer falhas no envio do datagrama, como hosts desligados ao receber os pacotes, contador de tempo de vida expirado, roteadores congestionados, etc. O ICMP (Internet Control Message Protocol) e o protocolo respons avel pela comunica ca o de mensagens desses erros/controle e de outras situa co es adversas. Um datagrama ao ser enviado, percorre de roteador em roteador at e chegar ao host de destino. Se, durante esse percurso, houver algum problema que inviabilize a viagem do datagrama, o roteador que tomou a a ca o de descarte envia uma mensagem ICMP indicando a causa do problema ao host de origem, para que esse tome as provid encias necess arias. Este protocolo n ao serve para troca de mensagem de erro entre roteadores, porque essas mensagens s ao diretamente encapsuladas dentro de um datagrama. Cada tipo de mensagem ICMP possui um formato espec co, por em, todas elas come cam com os mesmos tr es campos, como a gura 2.7 ilustra.

Figura 2.7: Formato de mensagem ICMP. Fonte: Forouzan (2000)

Type: 8 bits, identica a mensagem; Code: 8 bits, oferece mais informa co es sobre o tipo de mensagem;

2.2. Modelo TCP/IP

15

Checksum: 16 bits, executa um checksum somente sobre a a rea de dados da mensagem; Restante do cabe calho: depende do tipo de cada mensagem. Como demonstrado na se ca o 2.2.1, foi capturado pacotes do protocolo ICMP, para mostrar o formato da mensagem, como mostra a gura 2.8. Observe que o campo Type igual a 8, refere-se a requisi c ao de eco (echo request), o campo Code igual a 0, signica que n ao h a mais informa co es sobre o tipo da mensagem, o checksum informa que est a tudo correto na a rea de dados, e o campo identicador (Identier) e o campo n umero de seq u encia (Sequence number) s ao usados pelo emissor para combinar com as respostas da requisi ca o. O valor no campo Type especica se a mensagem e uma requisi c ao (8) ou uma resposta (0).

Figura 2.8: Mensagem ICMP As principais mensagens ICMP s ao descritas a seguir: Echo resquest e Echo reply: usada para vericar se o host est a ativo. Um host recebe uma mesnsagem Echo resquest, e este responde com uma mensagem Echo reply; Destination unreacheble: envia uma mensagem ao remetente informando que o datagrama enviado anteriormente n ao chegou ao destino. Isso acontece porque o host de destino pode estar inativo, ou porque o datagrama e maior que o tamanho suportado pela rede, ou porque n ao h a nenhuma aplica ca o capaz de processar aquele datagrama, entre outros motivos; Time exceeded: envia uma mensagem quando um pacote e descartado, porque seu TTL atingiu zero; Redirect: e usada por roteadores para indicar a rota correta do pacote; Parameter problem: indica que um valor do cabe calho e inv alido.

2.2. Modelo TCP/IP

16

2.2.2

Protocolo UDP

O protocolo UDP (User Datagram Protocol), assim como o IP, se trata de um protocolo sem conex ao e n ao con avel, pois n ao garante a entrega e a ordem de chegada dos dados, assim como tamb em, n ao garante o controle de erros e retransmiss ao dos dados. Pode-se dizer que o principal componente do cabe calho UDP e a porta de destino, pois e devido a ela que o UDP consegue identicar para qual protocolo de aplica ca o os dados s ao enviados. Cada mensagem UDP e dividida em duas partes: um cabe calho e uma a rea de dados. A gura 2.9 mostra o formato do cabe calho UDP.

Figura 2.9: Formato do cabe calho UDP. Fonte: Forouzan (2000) N umero da porta de origem: de 16 bits, e opcional, cont em o n umero da porta de origem e e usado em caso que seja necess ario a devolu c ao de uma resposta. Se a resposta n ao for necess ario o valor zero e atribu do a ela; N umero da porta de destino: de 16 bits, e o n umero da porta para onde os pacotes ser ao enviados; Comprimento total: de 16 bits, e o tamanho, em octetos, do datagrama, nele est a inclu do o cabe calho e os dados; Checksum: o uso desse campo e opcional e suas informa co es s ao organizadas em blocos de 16 bits, tem como fun ca o a verica c ao de erros na transmiss ao dos datagramas. Para a checagem do checksum e utilizado o cabe calho, os dados e tamb em o PseudoCabecalho, que e, conceitualmente, um prexo do cabe calho UDP, que oferece informa ca o para prote c ao contra erros na entrega dos datagramas, como cita Postel (1980). A gura 2.10 mostra o formato de um pseudo-cabecalho: Endere co IP de origem de 32 bits e Endere co IP de destino de 32 bits: cont em os endere cos IP de origem e destino, respectivamente, que ser ao usados no envio da mensagem UDP; Todos 0s: serve apenas para complementar a estrutura do pseudo-cabe calho;

2.2. Modelo TCP/IP

17

Figura 2.10: Pseudo-cabe calho do checksum. Fonte: Forouzan (2000) Protocolo de 8 bits: cont em o c odigo do tipo do protocolo IP; Comprimento total UDP de 16 bits: cont em o tamanho do datagrama UDP. Caso o checksum n ao seja utilizado, todos os 16 bits s ao complementados com zero. Caso contr ario, e feito um c alculo do checksum e se o resultado for igual a zero, a entrega dos pacotes foi realizada com sucesso, entretanto, se o c alculo do checksum for diferente de zero, houve erro na entrega dos datagramas e estes s ao descartados. Seguindo o exemplo da se ca o 2.2.1, a gura 2.11 mostra, de acordo com as fun co es descritas, o cabe calho UDP. Veja que e especicado o n umero da porta de origem (Source port) e o n umero da porta de destino (Destination port) que e o mesmo, 6646, o comprimento total (Length) do datagrama, 178 octetos, e o campo checksum, como e opcional, tem a valida ca o desabilitada (validation disable).

Figura 2.11: Cabe calho UDP

Interface IP Segundo Postel (1980), o protocolo UDP deve ser capaz de determinar os endere cos IP de origem e destino e tamb em determinar o campo de cabe calho do protocolo IP. Uma poss vel interface UDP/IP voltaria todo o pacote IP, incluindo seu cabe calho, como uma resposta de conrma ca o de recebimento de pacote. O protocolo UDP, ao receber os dados da camada de aplica ca o, coloca-os no campo de dados do datagrama UDP, que gra cas a interface UDP/IP, e transmitido ao protocolo IP sem a necessidade de ser fragmentado.

2.2. Modelo TCP/IP

18

2.2.3

Protocolo TCP

O TCP (Transmission Control Protocol) e um protocolo da camada de Transporte, que garante a seguran ca na entrega de pacotes, possuindo algumas caracter sticas que diferenciam e que levam o TCP ser mais difundido que o UDP. O TCP permite a recupera ca o de pacotes perdidos e dados corrompidos, a elimina c ao de pacotes duplicados e garante a entrega dos pacotes, entre outras caracter sticas. Segundo James F. Kurose (2006), o TCP e orientado para conex ao porque, antes que um processo de aplica c ao possa come car a enviar dados a outro, os dois processos precisam primeiramente se "apresentar", isto e, devem enviar alguns segmentos preliminares um ao outro para estabelecer os par ametros da transfer encia de dados em quest ao. O TCP encapsula os dados do processo de aplica c ao e passa para a camada IP, estes dados s ao mandados para os computadores de destino, ao chegar a ` m aquina, o protocolo TCP faz a demultiplexa ca o, que e a entrega do pacote ` a porta correta. E e da responsabilidade do TCP garantir a entrega correta e con avel dos pacotes. No entanto, e exatamente a entrega con avel dos pacotes um dos maiores problemas em uma rede de computadores, pois apesar da camada de transporte fornecer um canal con avel, a camada abaixo, rede, pode n ao ser con avel. De acordo com Comer (2006), a interface entre programas aplicativos e o servi co TCP/IP de transmiss ao con avel pode ser representado por cinco caracter sticas: Orienta c ao de uxo: o servi co de entrega de uxo na m aquina de destino passa exatamente a seq u encia que o transmissor passa para ele na m aquina de origem; Conex ao de circuito virtual: a transfer encia de uxo e parecida com uma chamada telef onica, ou seja, os sistemas operacionais das m aquinas envolvidas trocam informa c oes para saber se a transfer encia e autorizada de ambos os lados. E assim, durante toda a transfer encia as m aquinas continuam a trocar mensagens, garantindo assim que n ao haja falhas no envio; Transfer encia de buer: durante a transmiss ao de dados, cada aplicativo usa qualquer tamanho que seja adequado, e no m da recep ca o, o protocolo entrega os uxos exatamente na ordem que foram enviadas; Fluxo n ao-estruturado: o recurso de uxo TCP/IP n ao reconhece os uxos de dados estruturados; Conex ao full duplex: as conex oes fornecidas pelo servi co de uxo de dados TCP/IP, permitem transmiss oes em ambas as dire co es paralelamente.

2.2. Modelo TCP/IP

19

Para garantir a consist encia dos dados, o protocolo TCP usa uma t ecnica conhecida como conrma c ao positiva com retransmiss ao (PAR), que requer que o destinat ario envie uma mensagem de conrma c ao (ACK) ao emissor. Ao enviar um pacote, o emissor inicia um timer e espera a conrma ca o de recebimento antes de enviar o pr oximo pacote. Se a conrma c ao n ao chegar antes do timer expirar, o pacote e retransmitido. Por em, ao esperar essa conrma ca o a rede pode car ociosa, devido a atrasos na usada, ent resposta. E ao, janelas deslizantes, uma t ecnica que permite a transfer encia de v arios pacotes, antes de esperar uma conrma ca o. Os pacotes dentro de uma janela, de tamanho xo, s ao transmitidos. Conforme os pacotes v ao sendo conrmados, a janela vai deslizando para os pr oximos pacotes. Como mostra a gura 2.12.

Figura 2.12: (a) Janela deslizante do protocolo com oito pacotes; (b) Ao receber a conrma ca o do pacote 1, a janela deslizante envia at e o pacote 9. Fonte: Comer (2006) A gura 2.13 ilustra o formato de um segmento TCP. Um segmento e uma unidade de transfer encia entre o TCP nas duas m aquinas. Cada segmento e dividido em um cabe calho e uma parte de dados. O cabe calho TCP e representado da seguinte forma: Endere co da porta de origem e Endere co da porta de destino: s ao os pontos terminais da conex ao, que identicam a conex ao; N umero de sequ encia: identica em qual posi ca o do uxo de dados, transmitido pela origem, se encontra nesse segmento; N umero de conrma c ao: especica o pr oximo byte esperado; HLEN: informa o tamanho do cabe calho deste segmento, incluindo as op co es, caso existam;

2.2. Modelo TCP/IP

20

Figura 2.13: Formato do segmento TCP. Fonte: Forouzan (2000) Reservado: de 6 bits, n ao e utilizado. Ele est a no cabe calho, pois protocolos menores precisavam dele no projeto original do TCP; URG: de 1 bit, indica se o campo urgente e v alido; ACK: de 1 bit, indica se a conrma ca o e v alida; PSH: de 1 bit, solicita a entrega imediata ` a aplica c ao destino; RST, de 1 bit, e utilizado para reinicializar a conex ao; SYN, de 1 bit, sincroniza n umeros de sequ encia. E a ag FIN e usado quando o emissor encerrou suas transmiss oes; FIN, de 1 bit, indica que o emissor alcan cou o nal do seu uxo de bytes; Tamanho da janela: indica quantos bytes podem ser enviados a partir do byte conrmado; Checksum: e similar ao do protocolo UDP, j a descrito anteriormente; Urgent Pointer: quando v alido, aponta para o nal dos dados urgentes que o segmento carrega, indicando que esses dados devem se entregues imediatamente a ` aplica ca o de destino. Os dados indicados por este ponteiro t em prioridade no envio e recebimento; Op c oes: foi desenvolvido para imprevistos que ocorram no cabe calho, como negocia ca o para o tamanho m aximo de um segmento em uma conex ao, caso eles n ao determinem, o valor padr ao de 536 bytes ser a o tamanho dos pacotes.

2.2. Modelo TCP/IP

21

E para mostrar um exemplo pr atico, como na se ca o 2.2.1, a gura 2.14 mostra um cabe calho TCP de um pacote capturado.

Figura 2.14: Cabe calho TCP Perceba que o campo do endere co da porta de origem (Source port) e 59297, o endere co da porta de destino e https, o n umero de seq u encia (Sequence number) e 11578, o n umero da conrma c ao (Acknowledgment number) esperado e 1044185 octeto, o tamanho do cabe calho (Header lenght) deste segmento e 20 bytes, a ag marcada e apenas o ACK (Acknowledgement), que signica que est a sendo conrmada uma conex ao, o tamanho da janela (Window size value) que pode ser enviada e 33600 bytes, o campo checksum, assim como no UDP, tem a valida ca o desabilitada (validation disabled). Pode-se dizer que os campos mais importantes do cabe calho TCP s ao N umero de sequ encia e o campo N umero de conrma c ao, pois de acordo com James F. Kurose (2006), o TCP v e os dados como uma cadeia de bytes n ao estruturada, mas ordenada. O uso que o TCP faz dos n umeros de sequ encia reete essa vis ao, pois esses n umeros s ao aplicados sobre a cadeia de bytes transmitidos, e n ao sobre a s erie de segmentos transmitidos. J a o N umero de conrma c ao, conforme James F. Kurose (2006), e um pouco mais complicados que o n umero de sequ encia. J a que o TCP e full-duplex, portanto, um hospedeiro A pode estar recebendo dados do hospedeiro B enquanto envia dados ao hospedeiro B. O n umero de conrma ca o que o hospedeiro A atribuiu a seu segmento e o n umero de sequ encia do pr oximo byte que ele estiver aguardando do hospedeiro. Um exemplo e, o hospedeiro A recebeu do hospedeiro B, dados at e o byte 31, logo ele coloca o byte 32 no campo de conrma ca o e envia ao hospedeiro B, assim ele informa que est a esperando pelo byte 32 e por todos os bytes seguintes.

2.2. Modelo TCP/IP

22

Supondo, baseado no exemplo anterior, que o hospedeiro A ainda n ao tenha recebido o segundo segmento do pacote, que varia do byte 32 ao 63, mas j a tenha recebido o terceiro segmento, byte 64 a 95, a decis ao do que fazer com o terceiro segmento que chegou fora da ordem e da responsabilidade do programador, visto que os RFCs do TCP n ao ditam uma regra, podendo haver duas solu co es para este caso, ou o destinat ario descarta o segmento fora da ordem, ou o destinat ario aguarda a chegada dos bytes que est ao faltando, n ao descartando assim os bytes que chegaram fora da ordem. Estabelendo e encerrando uma conex ao TCP Para estabelecer uma conex ao TCP, e usado um handshke de tr es vias, que e o processo pelo qual dois hosts armam um a outro que o reconheceu e est a pronto para iniciar a comunica ca o, como demonstra a gura 2.15.

Figura 2.15: Estabelecimento de conex ao. Fonte: Comer (2006) Segundo Tanenbaum (2003), o host 1 manda uma primitiva CONNECT, especicando o IP e a porta com quem deseja se comunicar, o tamanho m aximo que consegue aceitar e dados de usu arios, mandando o SYN ativado, o host 1 ca esperando a resposta. Caso a primitiva LISTEN do campo de destino n ao tenha sido executado, o host 2 envia uma mensagem com o campo RST, do cabe calho TCP, ativado, negando assim a conex ao. As primitivas do protocolo TCP s ao explicadas na tabela 2.1. O host 1 ao mandar um segmento e este chegar de forma correta ao destino, o host 2 retornar a uma mensagem com os campos ACK e SYN, do cabe calho TCP, marcados, assim, o host 1 tamb em retornar a uma conrma c ao ao host 2 de que ambos os lados concordam em estabelecer conex ao. E para encerrar uma comunica ca o, qualquer um dos hosts pode encerrar, para isto, usa um handshke de tr es vias modicado. Primeiro o host 1 envia um segmento com o bit

2.2. Modelo TCP/IP

23

FIN ativado, o que signica que n ao h a mais dados a serem transmitidos. Em seguida, o host 2 envia uma conrma ca o da chegada do segmento. Ent ao, o host 2 envia outro segmento ao host 1, informando a requisi c ao para o encerramento com o bit FIN marcado, e nalmente, o host 1, responde a mensagem, um ACK, como mostra a gura 2.16.

Figura 2.16: Encerrando conex ao. Fonte: Comer (2006) Para o estabelecimento e encerramento de uma conex ao, e necess ario v arias etapas, que pode ser representada por uma m aquina de estados nitos com 11 estados, onde esses estados e mostrado na tabela 2.1. Cada conex ao come ca no estado CLOSED, onde sai desse estado se tiver uma execu c ao passiva (LISTEN) ou ativa (CONNECT). Se o outro lado executar a primitiva oposta, a conex ao ser a estabelecida e o estado passar a a ser ESTABLISHED, como mostra a gura 2.17. Na gura 2.17, a linha cont nua mais escura representa o caminho normal de um cliente. A linha tracejada mais escura representa o caminho normal de um servidor. As linhas mais nas representam eventos incomuns. Cada transi ca o e identicada pelo evento que a provoca e pela a ca o resultante dela, separados por uma barra. Gerenciamento de tempo Para controlar segmentos perdidos, o protocolo TCP utiliza o gerenciamento de timers. Conforme Tanenbaum (2003), o mais importante deles e o timer de retransmiss ao. Quando um segmento e enviado, um timer de retransmiss ao e ativado. Se o segmento for conrmado antes de o timer expirar, o timer e interrompido, mas se expirar antes da chegada

2.2. Modelo TCP/IP

24

Figura 2.17: M aquina de estados nitos usada no gerenciamento de uma conex ao TCP. Fonte: Tanenbaum (2003)

2.2. Modelo TCP/IP

25

Estado CLOSED LISTEN SYN RCVD SYN SENT ESTABLISHED FIN WAIT FIN WAIT TIMED WAIT CLOSING CLOSE WAIT LAST ACK

Descri c ao Nenhuma conex ao est a ativa ou pendente O servidor est a esperando pela chegada de uma chamada Uma solicita ca o de conex ao chegou; espera por ACK A aplica c ao comecou a abrir uma conex ao O estado normal para a transfer encia de dados 1 a aplica ca o informou que acabou de transmitir 2 o outro lado concordou em encerrar Aguarda a entrega de todos os pacotes Ambos os lados tentaram encerrar a transmiss ao simultaneamente O outro lado deu in cio a um encerramento Aguarda a entrega de todos os pacotes

Tabela 2.1: Os estados usados na m aquina de estado. Fonte: Tanenbaum (2003)

de conrma c ao, este segmento e retransmitido e o timer disparado novamente. Assim, e necess ario calcular o timeout (tempo limite) desses segmentos, que n ao pode ser muito curto, ocorrendo a retransmiss ao desnecess aria e sobrecarregando a Internet com pacotes in uteis, e nem longo demais, que pode causar retardo na retransmiss ao se caso um pacote se perder. A solu c ao e utilizar um algoritmo que ajusta constantemente o intervalo de timeout, criado por Jacobson (1988), que funciona da seguinte forma: cada conex ao TCP, e mantida uma vari avel RTT, que e uma estimativa para o percurso de ida e volta ao destino. Ao enviar um segmento, o timer e disparado, n ao s o para vericar quanto tempo a conrma ca o leva para chegar, mas tamb em, para acionar uma retransmiss ao, caso a conrma ca o demore demais para chegar. Se a conrma c ao voltar antes de o timer expirar, o TCP medir a o tempo necess ario, Amostra_de_ida_volta, em seguida, o TCP atualiza a vari avel RTT, de acordo com a f ormula: RT T = RT T + ((1 ) Amostra de ida volta) Controle de congestionamento A camada de transporte e a principal respons avel pelo gerenciamento do congestionamento na rede, que acontece devido ` a carga oferecida a ` rede ser maior que sua capacidade. A solu ca o para esse congestionamento e diminuir essa taxa de transmiss ao de dados. Para gerenciar o congestionamento, de acordo com Tanenbaum (2003), primeiramente, e preciso detect a-lo. Como a perda de pacotes na rede com erros de transmiss ao e relativamente rara, uma das causas dessa perda pode ser o timeout dos pacotes na rede devido a congestionamento.

2.2. Modelo TCP/IP

26

H a dois problemas potenciais que causam congestionamento, como mostra a gura 2.18, e a capacidade do receptor (a) e a capacidade da rede (b).

Figura 2.18: (a) Rede r apida alimentando um receptor de pequena capacidade. (b) Rede lenta alimentando um receptor de grande capacidade. Fonte: Tanenbaum (2003) A solu ca o para esses problemas e, cada transmissor mant em duas janelas, uma janela do receptor e uma janela de congestionamento, onde cada janela reete o n umero de bytes que o transmissor pode enviar. Esse n umero de bytes que pode ser enviado e o valor m nimo entre as duas janelas, janela permitida = min (janela receptora, janela congestionamento). Assim, se o receptor pedir "Envie 8 KB", e o transmissor souber que qualquer valor acima de 4 KB congestiona a rede, ent ao ser a enviado apenas 4 KB. Mas se o receptor pedir "Envie 8 KB", e o transmissor souber que at e 32 KB passam pela rede sem problemas, ent ao e enviado os 8 KB solicitados.

Cap tulo 3 Processos e Threads


3.1 Processos

Como explica Siberschatz (2004), um programa em execu ca o e chamado de processo. Logo, em um sistema operacional (SO) os diversos processos sendo executados, concorrem pela CPU (Central Processing Unit). O controle de cada processo e feito pelo bloco de controle de processo (PCB - Process Control Block), que cont em as informa c oes dos processos, como: em que estado se encontra o processo, o contador de programa, registradores de CPU, informa c ao de escalonamento da CPU, informa ca o de gerenciamento da mem oria, informa ca o de contabiliza c ao e informa ca o de E/S. Um exemplo de PCB, e mostrado na gura 3.1.

Figura 3.1: Bloco de controle de processo. Fonte: Siberschatz (2004) O estado de um processo e denido em parte pela sua atividade em curso, que ao longo da sua execu ca o varia, podendo ser novo, em execu c ao, em espera, pronto e terminado. 27

3.1. Processos

28

De acordo com Siberschatz (2004), o modelo de processo traz impl cita a id eia de que um processo e um programa que est a executando uma de suas linhas de a ca o, ou thread. Uma u nica linha de controle permite ao processo executar somente uma tarefa de cada vez.

3.1.1

Escalonamento de processos

Para que se maximize a utiliza c ao de uma CPU, sempre dever a ter um processo executando. Normalmente, SOs multiprogramados possuem v arios processos que competem para entrar na CPU ao mesmo tempo. A m de decidir qual dos processos executar a, o SO utilizar a escalonadores. Segundo Tanenbaum (2003), al em de escolher o processo certo para executar, o escalonador tamb em deve se preocupar em fazer uso eciente da CPU, pois alternar processos e muito caro. Os processos residentes na mem oria principal que est ao prontos para entrar em execu ca o, de acordo com Siberschatz (2004), s ao levados para uma lista chamada la de pronto. O sistema operacional tem ainda outras las, como a la de dispositivos, la de E/S. O tempo que um processo passa executando na CPU e chamado de pico de CPU e o tempo que a CPU aguarda esperando por novas E/S e chamado de pico de E/S. Um processo e composto por diversos picos de CPU, como tamb em, de diversos picos de E/S. Como explica Tanenbaum (2003), um algoritmo de escalonamento, deve ter objetivos como, dar a cada processo uma por ca o justa da CPU, vericar se a pol tica estabelecida e cumprida e manter ocupadas todas as partes do sistema. H a dois tipos de algoritmos de escalonamento, o n ao preemptivo e o preemptivo. O primeiro tipo de algoritmo escalona um processo e n ao o retira enquanto ele estiver dentro de seu pico de CPU. J a o segundo tipo de algoritmo, preemptivo, escolhe um processo e o deixa executando na CPU, por em, este processo pode ser retirado antes de seu t ermino, para que a CPU seja entregue a outro processo. Dependendo de qual algoritmo de escalonamento preemptivo est a sendo executado, a troca de processo na CPU ocorrer a, ou seja, o algoritmo pode determinar que o processo que um tempo x executando, ou que o processo que ser a completado em menor tempo ganhar a a CPU, ou simplesmente, o algoritmo pode usar outros padr oes de escolha para realizar a preemp c ao. Conforme Siberschatz (2004) explica, os diferentes tipos de algoritmos de escalonamento podem favorecer a um tipo de processo. Para comparar os algoritmos e determinar qual o melhor tipo para a solu c ao de um problema, s ao utilizados crit erios referentes a ` utiliza ca o da CPU, throughput, tempo de turnaround, tempo de espera e tempo de resposta.

3.1. Processos

29

Alguns dos principais algoritmos de escalonamento ser ao explicados abaixo. First Come, First Served (FCFS): este algoritmo e extremamente simples, onde o primeiro processo a chegar, ser a o primeiro a ser atendido na CPU. O algoritmo FCFS n ao e preemptivo, n ao sendo uma boa escolha para sistemas de tempo compartilhado, pois, se o pico de um processo que est a na CPU for longo, o processo a ocupar a at e ser liberado; Shortest Job First (SJF): diferente do primeiro algoritmo a ser explicado, o SJF, al em de poder ser preemptivo, analisa os tamanhos do pico de CPU de cada processo que est a na sua la de processos prontos, assim ele executa primeiramente o processo com menor pico de CPU. Este e considerado um algoritmo otimo, j a que ele garante um tempo de espera m nimo para um grupo de processo; Escalonamento Round-Robin (RR): o algoritmo round-robin e semelhante ao algoritmo FCFS, por em, ele usa a preemp ca o para fazer a comuta ca o entre processos, sendo adequado para os sistemas de tempo compartilhado. Este algoritmo possui duas propriedades, primeira, a la de pronto e tratada como uma la circular e, segunda, uma unidade de tempo pequena, chamada de quantum de tempo, que varia entre 10 e 100 milissegundos denida, conforme Siberschatz (2004) explica.

3.1.2

Cria c ao e termina c ao de processos

A chamada de sistema create-process permite que um processo de origem a novos processos durante sua execu ca o. O processo que deu origem aos subprocesso e chamado de processo pai e os gerados s ao chamados de processos lhos. Os processos necessitam de recursos como tempo de CPU, mem oria, arquivos, entre outros para executar a sua atividade, ao criar subprocessos, estes podem obter recursos do SO ou de uma parte dos recursos do pai. Conforme explica Siberschatz (2004), h a duas possibilidades de execu ca o ao se criar um subprocesso, ou o pai continua a executar concorrentemente com seus lhos, ou o pai aguarda que um de seus lhos ou todos tenham terminado. A chamada de sistema fork permite a cria ca o de um novo processo, que possui o mesmo endere co do processo original, isto permite que o processo pai se comunique mais facilmente com o processo lho. J a a chamada execlp, segundo Siberschatz (2004), e normalmente usada ap os uma chamada fork, por um dos processos, para realocar o espa co de mem oria do processo a um novo programa, esta chamada carrega um arquivo bin ario na mem oria, e inicia a sua execu c ao. Um processo termina quando executa o seu u ltimo comando e faz a chamada de sistema exit. Neste momento, caso seja necess ario o processo lho retorna dados de sa da para o

3.1. Processos

30

processo pai atrav es da chamada de sistema wait. No t ermino do processo todos os seus recursos s ao desalocados pelo SO. Outro meio de haver o t ermino de um subprocesso e quando o processo pai faz a chamada de sistema abort.

3.1.3

Processos cooperativos

Os processos concorrentes podem ser independentes ou cooperativos, independentes quando estes processos n ao podem afetar outros processos que est ao executando, e cooperativos quando podem afetar a execu c ao de outros processos, como explica Siberschatz (2004). Um ambiente cooperativo pode ser desej avel, pois permite o compartilhamento de informa c ao, processamento mais r apido, modularidade e comodidade. Os processos cooperativos podem se comunicar no ambiente de mem oria compartilhada, para isto os processos necessitam compartilhar uma cadeia de buers comuns e que o c odigo para implementa c ao do buer seja escrito pelo programador da aplica c ao. Outra forma de se fazer a comunica c ao entre processos cooperativos e atrav es do recurso do sistema operacional IPC (Inter Process Communication). Atrav es do uso do IPC a comunica c ao e feita sem a necessidade do compartilhamento do mesmo espa co de endere camento. O IPC e mais utilizado por um sistema de transmiss ao de mensagem, que permite a comunica ca o entre processos sem a utiliza ca o de dados compartilhados. O IPC fornece as opera co es send e receive para as mensagens, mas para que haja a troca de mensagens, os processos devem ter um meio de se referenciarem e possu rem um link de comunica ca o. Conforme Siberschatz (2004), a forma de envio de mensagem de um processo pode ocorrer de duas formas, direta ou indireta. De forma direta, as mensagens devem possuir um tamanho xo e nomear explicitamente o receptor e remetente da comunica ca o, ou apenas o receptor e nomeado, a desvantagem desta forma de envio, ocorre quando o nome de um processo e alterado. J a na forma indireta, o tamanho das mensagens pode ser variado e as mensagens s ao enviadas para caixas postais ou portas e delas recebidas, cada caixa postal possui identica ca o u nica e a comunica c ao s o ocorre se os dois processos compartilharem uma caixa postal. A comunica c ao entre processos pode ser s ncrona, com bloqueio na transmiss ao de mensagem, ou ass ncrona, sem bloqueio. Assim tanto send como receive podem ser com ou sem bloqueio. Como explica Siberschatz (2004), as mensagens trocadas na comunica ca o de processos cam em uma la, que pode ser implementada de tr es maneiras:

3.1. Processos

31

Capacidade zero, na qual o link n ao pode conter qualquer mensagem em espera, neste caso o remetente ca bloqueado at e que o receptor receba a mensagem; Capacidade limitada, a la tem tamanho nito n, se o link estiver cheio, o remetente e bloqueado at e ser liberado espa co na la; Capacidade ilimitada, a la possui tamanho innito, podendo conter qualquer n umero de mensagens, o remetente nunca e bloqueado. Neste projeto, a comunica ca o ser a feita atrav es do uso de buer compartilhado entre os threads.

3.1.4

Sincroniza c ao de processos

Os processos cooperativos compartilham um espa co de endere camento l ogico, assim, para que mantenham a consist encia de seus dados, em casos de acessos concorrentes, e necess ario realizar a sincroniza c ao de processos. A se c ao cr tica e o local onde os processos podem alterar dados comuns, gravar arquivos e realizar outras fun co es que comprometeriam os demais processos. Para manter a consist encia de dados, a execu ca o de uma se c ao cr tica por processos deve ser mutuamente exclusiva, ou seja, enquanto um processo estiver executando sua se c ao cr tica, nenhum outro processo pode estar executando a sua pr opria se c ao cr tica, como arma Siberschatz (2004). Para evitar que processos interram um no outro, cada software de protocolos que pode ser executado por diversos processos, utiliza uma ferramenta denomizada sem aforo, para implementar a exclus ao m utua, segundo Comer (1997). Um sem aforo S e uma vari avel inteira, que e acessada apenas por duas opera co es at omicas padr oes: wait e signal, como mostra a gura 3.2.
1 2 3 4 5 6 7 8 9

Semaforo S ; wait (S) S . v a l o r ; Se ( S . v a l o r < 0 ) adiciona o processo a S .L e bloqueio o processo signal (S) S . v a l o r ++; Se ( S . v a l o r <= 0 ) remove o p r o c e s s o P de S . L e d e s b l o q u e i a o p r o c e s s o

Figura 3.2: Opera c oes wait e signal. Fonte Siberschatz (2004) Quando um processo chama wait, o sistema operacional decrementa em 1 a vari avel S e, caso ela que com valor negativo o processo e bloqueado. J a a opera c ao signal tem

3.2. Threads

32

a fun c ao inversa do wait, se o signal for chamado por um processo, a vari avel S ser a incrementada e caso algum processo esteja bloqueado ele ser a liberado quando o valor for maior que zero. Estas fun co es s ao importantes para garantir, dentre outras coisas, a exclus ao m utua.

3.2

Threads

Thread e a unidade b asica de utiliza ca o da CPU, e a forma de um processo se dividir em mais de uma tarefa. Cada thread possui um ID, um contador de programa, um conjunto de registradores e uma pilha, por em, compartilha as se co es de c odigo, dados e arquivos com os demais threads, de acordo com Siberschatz (2004). H a dois tipos de thread, o de usu ario User-Level Thread (ULT) e o de kernel Kernel-Level Thread (KLT). Os ULT s ao implementados por uma biblioteca de thread a n vel de usu ario. Estes threads s ao mais r apidos, pois n ao precisam acessar o kernel, toda cria ca o e escalonamento e realizado no espa co do usu ario. Os KLT s ao suportados pelo sistema operacional e e responsabilidade do kernel a cria ca o e escalonamento dos threads. O multithread e a utiliza ca o de mais de um thread em um processo, viabilizando a realiza ca o de v arias tarefas diferentes ao mesmo tempo. Como explica Siberschatz (2004) os benef cios da utiliza ca o de multithreads s ao: Capacidade de resposta: permitindo que um programa continua a execu ca o mesmo se outra parte dele estiver bloqueada; Compartilhamento de recursos: o compartilhamento de recursos permite que uma aplica c ao tenha diversos threads utilizando o mesmo espa co de endere camento; Economia: gra cas ao compartilhamento de recursos, a cria c ao de threads se torna mais r apida que a cria ca o de processos; Utiliza ca o da arquitetura de multiprocessadores: nas arquiteturas de multiprocessadores atuais, diversos thread podem ser executados simultaneamente. Existem tr es formas de gera ca o de multithreads. A primeira forma e o modelo Muitospara-Um, no qual h a v arios threads de n vel usu ario e um no n vel de kernel. O gerenciamento deste modelo e realizado no ambiente do usu ario, por em, se um thread zer a chamada de bloqueio, todo o processo ser a bloqueado. O segundo modelo e o Um-para-Um, onde e criado um thread de kernel para cada uma de usu ario, resolvendo o problema do bloqueio que ocorre no modelo anterior e fazendo

3.2. Threads

33

com que haja maior concorr encia. A desvantagem e justamente o fato de que para cada thread de usu ario dever a ser criada um de kernel. J a o modelo Muitos-para-Muitos, criar a uma quantia menor ou igual de threads de kernel em rela ca o a ` quantidade de threads de usu ario. Conforme Siberschatz (2004), o cancelamento de threads e a tarefa desse thread ser terminado antes que se complete, como por exemplo, m ultiplos threads podem estar pesquisando concorrentemente em um banco de dados, quando um thread retorna o resultado, os outros threads podem ser cancelados. Esse thread que est a para ser cancelado e normalmente chamado de thread-alvo. Este cancelamento ocorre de forma ass ncrona, onde um thread termina imediatamente o thread-alvo, e de forma adiada, quando o threadalvo executa verica c oes periodicamente para saber se dever a terminar.

3.2.1

Sincroniza c ao de threads

A id eia de sincroniza ca o de threads e an aloga a ` sincroniza ca o de processos. Como os multithreads possuem dados, c odigos e outros recursos do sistema operacional compartilhados, haver a a concorr encia por eles. Para que n ao ocorra inconsist encia nos resultados, as regi oes cr ticas parte do c odigo que e suscept vel a ser afetada os threads utilizam sem aforo que possui as fun c oes lock, que pede o bloqueio para entrar em uma regi ao cr tica, e unlock, que libera o bloqueio do sem aforo, semelhantes ao wait e signal, respectivamente, utilizados na sincroniza ca o de processo.

3.2.2

Pthread

Pthread e como se chama o Posix thread, que dene uma Application Programming Interface (API) para cria ca o e sincroniza c ao de threads, conforme Siberschatz (2004). Posix e um conjunto de normas denidas pela IEEE para a interface de programa ca o com sistemas operacionais. A IEEE 1003.1c dene a interface de programa c ao para threads. Atualmente os pthreads s ao restritos a sistemas baseados em UNIX. Exemplos de fun c oes da biblioteca Pthreads O pthread possui in umeras subrotinas e aquelas que ser ao u teis no desenvolvimento do programa, s ao explicadas neste projeto. pthread create: a fun c ao pthread_create() cria um novo thread, com atributos especicados por attr, dentro de um processo; pthread exit: a fun ca o pthread_exit() termina o thread que fez a chamada;

3.2. Threads

34

pthread join: a fun c ao pthread_join() deve suspender a execu c ao do thread que fez a chamada at e que o thread de destino termina.

Cap tulo 4 Prot otipo


Para a implementa c ao dos protocolos IP, UDP e TCP que foi realizada neste projeto, foram utilizados multithreads, que simularam a comunica ca o entre os protocolos em uma rede. Foram criados dois threads, cada um simulando um computador, e foi feito o encaminhamento dos pacotes entre eles, de acordo com os protocolos utilizados. Para representar o canal de comunica c ao, foi disponibilizado um buer, que e compartilhado entre os threads, representado no programa por uma vari avel global chamada g_data_channel. Os dados de congura c ao de cada m aquina encontram-se em arquivos no formato txt, assim, cada arquivo tem como nome o endere co IP da m aquina. Nestes arquivos, encontra-se o comando que a m aquina ir a executar, ou seja, um send, recb, connect_tcp ou listen_tcp, que ser ao explicados na se ca o: 4.2. Na implementa c ao deste projeto, apenas as funcionalidades b asicas dos protocolos foram desenvolvidas, visto que s ao in umeras e demanda um tempo maior para a implementa ca o completa. O c alculo do checksum e a tabela de roteamento s ao exemplos de funcionalidades que n ao foram implementadas. A implementa ca o foi no sistema operacional Windows, na linguagem C/C++.

4.1

Estrutura de dados

Como explicado na se ca o 2.2, para realizar a comunica ca o, os protocolos adicionam um cabe calho em seus dados, e s o depois os enviam, este detalhe pode ser observado na gura 2.3. Para o desenvolvimento do programa, a id eia foi utilizar estruturas para simular os protocolos. Estas estruturas cont em o campo dados mais o cabe calho referente a um protocolo espec co. A seguir ser a explicado cada estrutura.

35

4.1. Estrutura de dados

36

4.1.1

Estrutura My socket

A estrutura My_socket passa para os protocolos de transporte e rede, as congura c oes de IP de origem e de destino, porta de origem e de destino, assim como o protocolo de transporte que e utilizado, como mostra a gura 4.1.
struct My socket { unsigned unsigned unsigned unsigned unsigned };

ip src : 32; port src ; : 32; ip dst port dst ; transp proto ;

// IP de origem // p o r t a de origem // IP de d e s t i n o // p o r t a de d e s t i n o // p r o t o c o l o de t r a n s p o r t e (UDP ou TCP)

Figura 4.1: Estrutura de dados My socket

4.1.2

Estrutura do protocolo da camada de transporte

Como h a dois protocolos na camada de transporte estudados neste projeto, foram criados duas estruturas, uma para o protocolo UDP e outra para o protocolo TCP. Estrutura do protocolo UDP As vari aveis declaradas nesta estrutura, exceto a vari avel dados, j a foram devidamente apresentadas na se ca o 2.2.2. J a a vari avel dados receber a os dados que vem da camada de aplica ca o, como mostra a gura 4.2.
struct U d p p r o t o c o l o // c a b e calho + { unsigned p o r t a o r i g e m ; unsigned p o r t a d e s t i n o ; unsigned comprimento : 16; unsigned checksum : 16; char dados ; }; dados UDP // e n d e r e c o IP de origem // e n d e r e c o IP de d e s t i n o // comprimento t o t a l do datagrama // v e r i f i c a c a o de e r r o s na t r a n s m i s s ao // dados do p r o t o c o l o UDP

Figura 4.2: Estrutura de dados do protocolo UDP

Estrutura do protocolo TCP Todas as vari aveis pertencentes a esta estrutura, foram apresentadas na se ca o 2.2.3.

4.2. Fun c oes para comunica ca o

37

Com exce c ao da vari avel dados, que recebe os dados vindo da camada de aplica ca o, como mostra a gura 4.3.
struct T c p p r o t o c o l o // c a b e calho { unsigned p o r t a o r i g e m unsigned p o r t a d e s t i n o unsigned num sequencia unsigned num confirmacao unsigned tamanho cabecalho unsigned URG unsigned ACK unsigned PSH unsigned RST unsigned SYN unsigned FIN unsigned t a m a n h o j a n e l a unsigned checksum unsigned u r g e n t p o i n t e r char o p c o e s ; char dados ; }; + dados TCP : : : : : : : : : : : // p o r t a de origem TCP // p o r t a de d e s t i n o TCP // p o s i c a o do f l u x o de dados // pr o ximo b y t e e s p e r a d o // tamanho do c a b e calho //campo u r g e n t e // c o n f i r m a c ao v alida // e n t r e g a i m e d i a t a // r e i n i c i a l i z a r a conex ao // s i n c r o n i z a n u mero de s e q u encia // a l c a n c e do f i n a l do f l u x o de byte : 4 ; // q u a n t i d a d e de b y t e s pode ser enviado : 1 6 ; // v e r i f i c a c a o de e r r o s na transmiss ao : 1 6 ; // aponta para dados u r g e n t e s // i m p r e v i s t o s no c a b e calho // dados do p r o t o c o l o TCP 16; 16; 32; 32; 16; 1; 1; 1; 1; 1; 1;

Figura 4.3: Estrutura de dados do protocolo TCP

4.1.3

Estrutura do protocolo da camada de rede

O protocolo estudado da camada de rede, e o protocolo IP, e a sua estrutura e mostrada a seguir. Estrutura do protocolo IP Como nos demais protocolos, todas as vari aveis deste protocolo j a foram explicadas anteriormente, estas foram na se c ao 2.2.1. Apenas a vari avel dados merece uma ressalva, esta vari avel receber a os dados e o cabe calho do protocolo de transporte, UDP ou TCP, como mostra a gura 4.4.

4.2

Fun c oes para comunica c ao

Para a realiza c ao da comunica ca o entre as m aquinas, e descrito a seguir, as principais fun c oes implementadas. Estas fun c oes podem ser encontradas no Ap endice A.

4.2. Fun c oes para comunica ca o

38

struct I p p r o t o c o l o // c a b e c a l h o + dados IP { unsigned v e r s a o : 4 ; // v e r s a o do p r o t o c o l o : 4 ; // comprimento do c a b e calho unsigned c o m p c a b e c a l h o I p : 8 ; // t i p o de s e r v i co unsigned t i p o d e s e r v i c o unsigned c o m p t o t a l d a t a g r a m a : 1 6 ; // comprimento t o t a l unsigned i d e n t i f i c a d o r : 1 6 ; // i d e n t i f i c a o datagrama unsigned NF : 1 ; //N ao Fragmentar unsigned MF : 1 ; // Mais Fragmentos : 1 3 ; // p o s i c a o do f r a g m e n t o no unsigned F r a g m e n t O f f s e t datagrama o r i g i g a l unsigned t e m p o d e v i d a : 8 ; // tempo de v i d a do p a c o t e unsigned p r o t o c o l o t r a n s p o r t e : 8 ; //UDP ou TCP : 3 2 ; // e n d e r e c o IP de origem unsigned i p o r i g e m unsigned i p d e s t i n o : 3 2 ; // e n d e r e c o IP de d e s t i n o char o p c o e s ; // o p c o e s do datagrama char dados ; // dados do p r o t o c o l o IP };

Figura 4.4: Estrutura de dados do protocolo IP Fun c ao Main O c odigo da fun ca o principal main, tem como fun ca o: Fazer a chamada do thread, thread_canal, que controla a escrita e leitura de pacotes no buer, atrav es da fun c ao libera_canal; Fazer a chamada dos threads, tcpip_threads, que simulam as m aquinas da rede, atrav es da fun c ao tcpip_thread_proc. Fun c ao libera canal A fun c ao libera_canal, tem como responsabilidade decrementar a vari avel global canal_ocupado. Caso esta vari avel tenha valor maior que zero, signica que h a pacote no buer, logo, as m aquinas (threads) podem apenas ler o buer. Se esta vari avel possui valor igual a zero, as m aquinas podem escrever no buer. Essa situa c ao foi criada para simular a manuten c ao dos dados no canal de comunica ca o compartilhado. Dessa forma, ap os o sinal se propagar no canal por um per odo, ele se atenua e os dados desaparecem. Fun c ao tcpip thread proc Cada thread, que representa uma m aquina, chama a fun c ao tcpip_thread_proc, que atrav passa como par ametro o identicador do thread, ou seja, o seu endere co IP. E es

4.2. Fun c oes para comunica ca o

39

deste endere co que se abre o arquivo que cont em os comandos de comunica ca o que cada m aquina ir a executar. Isto e, o thread com identicador 10.0.0.1 ir a abrir o arquivo de nome 10.0.0.1.txt. No cap tulo 5 e apresentado, como exemplo, o conte udo desse arquivo. H a quatro comandos que podem ser encontrados dentro do arquivo de congura c ao, send, recb, connect_tcp e listen_tcp, cada um e explicado a seguir. send: O arquivo que cont em o comando send, tamb em cont em os seguintes dados separados por uma nova linha: IP de destino, protocolo de transporte, porta origem, porta destino, e os dados. A fun ca o send copia o IP de destino, protocolo de transporte (UDP), porta origem e porta destino para uma vari avel s do tipo My_socket. E os dados para a vari avel msg do tipo char. Logo ap os e chamada a fun c ao envia_app_msg; recb: A m aquina que executa este comando est a esperando dados da protocolo UDP. Tem como dever fazer a chamada da fun c ao recb_fisica_camada_proc; connect_tcp: O comando connect_tcp estabelece a comunica c ao entre a m aquina de origem e de destino. O seu arquivo de congura c ao cont em, separados por uma nova linha, o comando connect_tcp, IP de destino, porta de origem, porta de destino e os dados que devem ser enviados. Ap os fazer o connect_tcp, a m aquina verica o tamanho da janela, denida como 1000, que e o tamanho m aximo do pacote que pode ser enviada a ` m aquina de destino. Caso o tamanho dos dados seja maior que o tamanho da janela, os dados s ao fragmentados e enviados, lembrando que para cada fragmento enviado e necess ario receber uma mensagem de conrma ca o para se enviar o pr oximo fragmento; listen_tcp: A m aquina que executa este comando, tamb em possui em seu arquivo de congura ca o, o n umero da porta de destino. O comando listen_tcp espera uma m aquina executar o comando connect_tcp, ao chegar um pedido de estabelecimento de comunica ca o, a m aquina de destino envia uma resposta para a m aquina de origem, informando que est a pronta para o in cio da comunica ca o. Ap os o estabelecimento da conex ao, a m aquina que executa o comando listen_tcp, ca acessando o buer (g_data_channel), para vericar se chegou alguma mensagem. Fun c ao connect tcp A fun c ao connect_tcp e chamada quando o arquivo de congura c ao da m aquina possui o comando connect_tcp, explicado anteriormente. Esta fun ca o estabelece a comunica c ao entre duas m aquinas, que desejam trocar mensagens usando o TCP como protocolo de transporte.

4.2. Fun c oes para comunica ca o

40

No primeiro passo, a m aquina de origem marca em uma tabela de conex oes que se trata de uma estrutura global, o IP de destino, IP de origem, porta destino e porta origem. Em seguida, envia um pedido de conex ao para a m aquina de destino e atribui o valor 1 para a vari avel global qnt_conex~ oes, que foi uma solu ca o encontrada para saber quando uma m aquina iniciou um pedido de conex ao TCP. Logo ap os, ca esperando a conrma ca o da m aquina de destino. Ao chegar a conrma ca o, a m aquina de origem envia ou parte do pacote de aplica ca o ou todo o pacote dependendo do tamanho deste. Fun c ao listen tcp A m aquina que executa a fun ca o listen_tcp possui em seu arquivo de congura c ao o comando listen_tcp, explicado anteriormente. Esta fun c ao faz a m aquina esperar um pedido de comunica ca o TCP e ao receb e-lo a m aquina retorna uma mensagem conrmando comunica ca o. Fun c ao envia udp protocol proc Esta fun ca o gera o cabe calho UDP, atrav es dos dados contidos na vari avel socket, depois envia o cabe calho e os dados contidos na vari avel msg, para a camada inferior, IP. Fun c ao envia tcp protocol proc A fun c ao envia_tcp_protocol_proc envia os dados contidos no arquivo txt para a ` m aquina de destino. Esta fun c ao s o e chamada ap os o estabelecimento de conex ao entre a m aquina origem e de destino. Fun c ao envia ip protocol proc A fun c ao envia_ip_protocol_proc, ao ser chamada verica o tamanho dos dados que chegaram da camada de transporte, caso eles sejam maiores que o MTU IP (denido como 1500), e necess ario fazer a fragmenta ca o dos dados. Para cada fragmento e gerado um cabe calho IP, e logo ap os, e enviado este fragmento com o cabe calho rec em-criado para a camada de enlace. Para os dados que n ao necessita ser fragmentados, tamb em e gerado um cabe calho IP e assim como nos dados fragmentados, e enviado o pacote que cont em o cabe calho IP e os dados, para a camada inferior. Fun c ao envia enlace protocol proc Esta fun ca o gera o cabe calho de enlace para os dados recebidos do protocolo IP e encaminha o pacote contendo os dados com o cabe calho de enlace para a camada f sica.

4.2. Fun c oes para comunica ca o

41

Fun c ao envia sica protocol proc Um pacote s o e enviado para o buer (g_data_channel) quando a vari avel global canal_ocupado tiver valor zero, isto signica que, ou n ao h a pacote na rede para ser recebido, ou o tempo para que as m aquinas recebessem um determinado pacote se esgotou. Como o buer e compartilhado, para representar o funcionamento de um barramento de comunica c ao, e utilizado a sincroniza ca o atrav es de sem aforos para controlar o acesso. Fun c ao recb sica camada proc O thread ao chamar esta fun ca o, l e os dados que est ao no buer (g_data_channel) e passa para a camada de enlace atrav es da fun ca o recb_enlace_camada_proc. Para que a leitura ocorra a vari avel global canal_ocupado, deve ter um valor maior que zero. Fun c ao recb enlace camada proc O cabe calho de enlace e retirado nesta fun ca o e os dados do enlace s ao passados para a camada superior, IP. Fun c ao recb ip camada proc Aqui e vericado se o endere co IP de destino, contido no cabe calho do pacote que e recebido, e o mesmo endere co IP da m aquina que faz a chamada desta fun c ao. Caso seja, insere em uma lista e apenas quando o u ltimo ou u nico pacote chegar, e que os dados s ao encaminhados para a camada de transporte. Fun c ao recb udp camada proc Esta fun ca o, recebe os dados vindo da camada inferior, IP, retira o cabe calho UDP e envia para a camada de aplica ca o. Fun c ao recb tcp camada proc Esta fun c ao recebe o pacote do protocolo IP. Do pacote recebido a fun ca o verica os campos ACK e SYN, do cabe calho TCP. Se ACK tiver valor zero e SYN valor um, uma m aquina est a querendo estabelecer conex ao, parte da fun ca o connect_tcp, logo, a m aquina responde que est a dispon vel para o estabelecimento. Por em, se o ACK possuir valor um e SYN valor zero e vericado qual das m aquinas est a recebendo este pacote. Se for a m aquina de origem, quer dizer que a mensagem

4.2. Fun c oes para comunica ca o

42

recebida e uma conrma c ao de entrega de um pacote, assim a m aquina de origem envia o pr oximo pacote de aplica ca o. Todavia, se e a m aquina de destino que est a recebendo ACK com valor um e SYN com valor zero, um pacote da m aquina de origem acaba de chegar, logo, os dados deste pacote s ao inseridos em uma lista at e que o u ltimo pacote chegue, ap os o recebimento do u ltimo pacote, a fun c ao recb_tcp_protocol_proc envia os dados para a aplica ca o.

Cap tulo 5 Testes do prot otipo


Esta se c ao apresenta exemplos de testes feitos a partir do c odigo desenvolvido, como tamb em mostra como devem ser os arquivos de congura ca o. S ao usados dois arquivos de entrada, um que solicita o envio dos dados, 10.0.0.2.txt, e outro que recebe os dados, 10.0.0.1.txt. A seguir, ser a demonstrada a congura c ao de cada arquivo.

5.1

Testes

Para demonstrar como e o envio e recebimento de dados, ser ao feitos dois testes, um sem fragmenta c ao IP e outro com fragmenta ca o. Esta se c ao mostra como ser a a congura c ao de duas m aquinas, uma que possui o comando recb, e a outra que executa o comando send. Como explicado no cap tulo 4, cada thread abre um arquivo que possui como nome seu endere co IP. Em seguida, ser a apresentado o encapsulamento dos dados nos n veis de transporte, rede e enlace, assim como o desencapsulamento realizado na ordem inversa.

5.1.1

Teste 1: Dados sem fragmenta c ao

O teste apresentado a seguir, demonstra o envio de uma mensagem tendo o UDP como protocolo de transporte. Arquivo 10.0.0.1.txt Este arquivo possui apenas o comando recb, que recebe os dados da rede, como mostrado a seguir. recb // Comando. 43

5.1. Testes

44

Arquivo 10.0.0.2.txt A entrada deste arquivo cont em, primeiramente, o comando send, que envia os dados a ` rede, em seguida o IP de destino, protocolo de transporte, porta de origem, porta de destino e dados. Note que, como os dados tem um tamanho pequeno, a camada IP n ao necessita fragmentar, como mostrado a seguir. send // 10.0.0.1 1 20 21 Ola, teste! Comando. // IP destino. // Protocolo de transporte (UDP). // Porta origem. // Porta destino. // Dados que ser~ ao transmitidos.

Fun c ao envia udp protocol proc A fun ca o envia_udp_protocol_proc recebe a mensagem Ola, teste! e adiciona o cabe calho UDP. O pacote UDP e passado para o protocolo IP. O texto da gura 5.1 mostra a mensagem com o cabe calho UDP.

Figura 5.1: Dados enviados a ` camada de transporte (UDP)

Fun c ao envia ip protocol proc A fun ca o envia_ip_protocol_proc, recebe o pacote do protocolo UDP, e como o ao e necess ario fragment a-lo. O pacote recebido pacote e menor que o MTU IP (1500), n da camada UDP adicionado do cabe calho IP, pode ser visto na gura 5.2.

Figura 5.2: Dados enviados a ` camada de rede (IP)

Fun c ao envia enlace protocol proc Esta fun ca o recebe o pacote do protocolo IP e adiciona o cabe calho de enlace. O pacote recebido mais o cabe calho de enlace pode ser visto na gura 5.3.

5.1. Testes

45

Figura 5.3: Dados enviados a ` camada enlace Fun c ao envia sica protocol proc A fun c ao envia_fisica_camada_proc, recebe o pacote da camada de enlace e o coloca no barramento, que e representada pela vari avel global g_data_channel. Os dados nesse n vel s ao exatamente os mesmos da gura 5.3. Fun c ao recb sica protocol proc A fun ca o recb_fisica_camada_proc pega o pacote que est a no barramento e repassa a ` camada de enlace. Os dados manipulados por essa fun c ao, s ao exatamente os mesmos da gura 5.3. Fun c ao recb enlace protocol proc Esta fun ca o recebe o pacote da camada f sica, com os mesmos dados da gura 5.3, retira o cabe calho de enlace e encaminha a mensagem para o protocolo IP. Fun c ao recb ip protocol proc Esta fun ca o recebe o pacote da camada de enlace, que e identico ao da gura 5.2. O cabe calho IP e retirado do pacote que recebeu e os seus dados s ao armazenados em uma lista. Ao chegar o u ltimo pacote, os dados s ao remontados e assim enviados para a camada UDP. Fun c ao recb udp protocol proc A fun ca o recb_udp_protocol_proc, recebe o pacote do protocolo IP, retira o seu cabe calho e encaminha para a camada de aplica ca o. A gura 5.1 mostra o pacote recebido da camada IP, ainda com o cabe calho UDP. Recebimento da mensagem A m aquina de destino recebeu, exatamente, o pacote que a m aquina origem enviou, Ola, teste!.

5.1. Testes

46

5.1.2

Teste 2: Dados com fragmenta c ao

O teste apresentado a seguir, demonstra o envio de uma mensagem que e fragmentada pelo protocolo IP, sendo o UDP o protocolo de transporte. Arquivo 10.0.0.1.txt Este arquivo possui apenas o comando recb, que recebe os dados da rede, como mostrado a seguir. recb // Comando.

Arquivo 10.0.0.2.txt A entrada deste arquivo e exatamente igual ao do primeiro exemplo, com exce c ao dos dados. A entrada possui o comando send, que envia os dados a ` rede, em seguida o IP de destino, protocolo de transporte, porta de origem, porta de destino e dados. Mas como a mensagem e grande, h a a necessidade de fragment a-la, como mostrado a seguir. send 10.0.0.1 1 20 21 // Comando. // IP destino. // Protocolo de transporte (UDP). // Porta origem. // Porta destino. // Abaixo os dados que ser~ ao transmitidos. Filtro solar! (Pedro Bial) Se eu pudesse dar s o uma dica sobre o futuro seria esta: usem o ltro solar! Os benef cios a longo prazo do uso de Filtro Solar est ao provados e comprovados pela ci encia, J a o resto de meus conselhos n ao tem outra base con avel al em de minha pr opria experi encia errante. Mas agora eu vou compartilhar esses conselhos com voc es... Aproveite bem, o m aximo que puder, o poder e a beleza da juventude. Ou, ent ao, esquece... Voc e nunca vai entender mesmo o poder e a beleza da juventude at e que tenham se apagado. [...] N ao se preocupe com o futuro. Ou ent ao preocupe-se, se quiser, mas saiba que pr e-ocupa c ao e t ao ecaz quanto mascar chiclete para tentar

5.1. Testes

47

resolver uma equa ca o de a lgebra. As encrencas de verdade em sua vida tendem a vir de coisas que nunca passaram pela sua cabe ca preocupada, E te pegam no ponto fraco ` as 4 da tarde de uma ter ca-feira modorrenta. Todo dia, enfrente pelo menos uma coisa que te meta medo de verdade. Cante. N ao seja leviano com o cora ca o dos outros. N ao ature gente de cora c ao leviano. Use o dental. N ao perca tempo com inveja. ` vezes se est As a por cima, a `s vezes por baixo. A peleja e longa e, no m, e s o voc e contra voc e mesmo. N ao esque ca os elogios que receber. Esque ca as ofensas. Se conseguir isso, me ensine. Guarde as antigas cartas de amor. Jogue fora os extratos banc arios velhos. Estique-se. N ao se sinta culpado por n ao saber o que fazer da vida As pessoas mais interessantes que eu conhe co n ao sabiam, aos vinte e dois o que queriam fazer da vida. Alguns dos quarent oes mais interessantes que eu conhe co ainda n ao sabem. Tome bastante c alcio. Seja cuidadoso com os joelhos. Voc e vai sentir falta deles. [...] Fa ca o que zer n ao se auto congratule demais, nem seja severo demais com voc e, As suas escolhas tem sempre metade das chances de dar certo, assim para todo mundo. E Desfrute de seu corpo use-o de toda maneira que puder, mesmo!! N ao tenha medo de seu corpo ou do que as outras pessoas possam achar dele, E o mais incr vel instrumento que voc e jamais vai possuir. Dance.

5.1. Testes

48

Mesmo que n ao tenha aonde al em de seu pr oprio quarto. Leia as instru c oes mesmo que n ao v a segui-las depois. N ao leia revistas de beleza, elas s o v ao fazer voc e se achar feio [...] imposs Dedique-se a conhecer seus pais. E vel prever quando eles ter ao ido embora, de vez. Seja legal com seus irm aos. Eles s ao a melhor ponte com o seu passado e possivelmente quem vai sempre mesmo te apoiar no futuro. Entenda que amigos v ao e vem, mas nunca abra m ao de uns poucos e bons. Esforce-se de verdade para diminuir as dist ancias geogr acas e de estilos de vida, porque quanto mais velho voc e car, Mais voc e vai precisar das pessoas que voc e conheceu quando jovem. More uma vez em Nova York, mas v a embora antes de endurecer. More uma vez no Hava , mas se mande antes de amolecer. Viaje. Aceite certas verdades inescap aveis: Os pre cos v ao subir, os pol ticos v ao saracotear, voc e tamb em vai envelhecer. E quando isso acontecer voc e vai fantasiar que quando era jovem os pre cos eram razo aveis, os pol ticos eram decentes, E as crian cas respeitavam os mais velhos. Respeite os mais velhos!! E n ao espere que ningu em segure a sua barra. Talvez voc e arrume uma boa aposentadoria privada. Talvez voc e case com um bom partido, mas n ao esque ca que um dos dois de repente pode acabar. N ao mexa demais nos cabelos se n ao quando voc e chegar aos 40 vai aparentar 85. Cuidado com os conselhos que comprar, mas seja paciente com aqueles que os oferecem. Conselho e uma forma de nostalgia. Compartilhar conselhos e um jeito de pescar o passado do lixo, esfreg a-lo, repintar as partes feias e reciclar tudo por mais do que vale. Mas, no ltro solar, acredite. Fun c ao envia udp protocol proc A fun ca o envia_udp_protocol_proc recebe a mensagem, adiciona o cabe calho e passa o pacote para o protocolo IP. A mensagem com o cabe calho UDP pode ser vista na gura 5.4.

5.1. Testes

49

Figura 5.4: Dados enviados a ` camada de transporte (UDP) Fun c ao envia ip protocol proc A fun c ao envia_ip_protocol_proc, recebe o pacote do protocolo UDP, e fragmentae encaminhado o, uma vez que este pacote e maior que o MTU IP (1500). Cada fragmento para a camada de enlace. As guras 5.5, 5.6 e 5.7 representam os fragmentos do pacote recebido do protocolo UDP adicionados do cabe calho IP.

Figura 5.5: Fragmento 1: Dados enviados a ` camada de rede (IP)

Fun c ao envia enlace protocol proc Esta fun ca o recebe os pacotes do protocolo IP e adiciona o cabe calho de enlace. Pode-se ver os pacotes recebidos da camada IP, adicionado do cabe calho de enlace nos fragmentos nas guras 5.8, 5.9 e 5.10. Em seguida, os pacotes s ao enviados para o meio f sico.

5.1. Testes

50

Figura 5.6: Fragmento 2: Dados enviados a ` camada de rede (IP)

Figura 5.7: Fragmento 3: Dados enviados a ` camada de rede (IP)

Figura 5.8: Fragmento 1: Dados enviados a ` camada de enlace

Figura 5.9: Fragmento 2: Dados enviados a ` camada de enlace

Figura 5.10: Fragmento 3: Dados enviados ` a camada de enlace

5.1. Testes

51

Fun c ao envia sica protocol proc A fun c ao envia_fisica_camada_proc, recebe os pacotes da camada de enlace e encaminha para o barramento, representada pela vari avel global g_data_channel, os pacotes s ao os mesmos da camada de enlace, como mostra nas gras 5.8, 5.9 e 5.10. Fun c ao recb sica protocol proc Note que a u nica responsabilidade desta fun ca o e a de receber o pacote que est a no barramento e passar para a camada de enlace, essa fun ca o recebe os mesmos pacotes das guras 5.8, 5.9 e 5.10. Fun c ao recb enlace protocol proc A fun ca o recb_enlace_camada_proc recebe os pacotes da camada f sica, como mostra nas guras 5.8, 5.9 e 5.10, retira o cabe calho de enlace e encaminha a mensagem para o protocolo IP. Fun c ao recb ip protocol proc Esta fun ca o recebe os pacotes da camada de enlace, assim como mostrado nas guras 5.5, 5.6 e 5.7, retira o cabe calho, e armazena os dados do pacote sem o cabe calho em uma lista. Ao chegar o u ltimo pacote, os dados s ao remontados e enviados para a camada UDP. Fun c ao recb udp protocol proc A fun ca o recb_udp_protocol_proc recebe o pacote do protocolo IP, que e id entico ao da gura 5.4, retira seu cabe calho e encaminha para a camada de aplica ca o. Recebimento da mensagem Observe que e o mesmo texto que a m aquina de IP de origem (10.0.0.2) encaminhou para a m aquina de IP de destino (10.0.0.1). Filtro solar! (Pedro Bial) Se eu pudesse dar s o uma dica sobre o futuro seria esta: usem o ltro solar! Os benef cios a longo prazo do uso de Filtro Solar est ao provados e comprovados pela ci encia, J a o resto de meus conselhos n ao tem outra base con avel al em de minha pr opria experi encia errante.

5.1. Testes

52

Mas agora eu vou compartilhar esses conselhos com voc es... Aproveite bem, o m aximo que puder, o poder e a beleza da juventude. Ou, ent ao, esquece... Voc e nunca vai entender mesmo o poder e a beleza da juventude at e que tenham se apagado. [...] N ao se preocupe com o futuro. Ou ent ao preocupe-se, se quiser, mas saiba que pr e-ocupa c ao e t ao ecaz quanto mascar chiclete para tentar resolver uma equa ca o de a lgebra. As encrencas de verdade em sua vida tendem a vir de coisas que nunca passaram pela sua cabe ca preocupada, E te pegam no ponto fraco ` as 4 da tarde de uma ter ca-feira modorrenta. Todo dia, enfrente pelo menos uma coisa que te meta medo de verdade. Cante. N ao seja leviano com o cora ca o dos outros. N ao ature gente de cora c ao leviano. Use o dental. N ao perca tempo com inveja. ` As vezes se est a por cima, a `s vezes por baixo. A peleja e longa e, no m, e s o voc e contra voc e mesmo. N ao esque ca os elogios que receber. Esque ca as ofensas. Se conseguir isso, me ensine. Guarde as antigas cartas de amor. Jogue fora os extratos banc arios velhos. Estique-se. N ao se sinta culpado por n ao saber o que fazer da vida As pessoas mais interessantes que eu conhe co n ao sabiam, aos vinte e dois o que queriam fazer da vida. Alguns dos quarent oes mais interessantes que eu conhe co ainda n ao sabem. Tome bastante c alcio. Seja cuidadoso com os joelhos. Voc e vai sentir falta deles.

5.1. Testes

53

[...] Fa ca o que zer n ao se auto congratule demais, nem seja severo demais com voc e, As suas escolhas tem sempre metade das chances de dar certo, assim para todo mundo. E Desfrute de seu corpo use-o de toda maneira que puder, mesmo!! N ao tenha medo de seu corpo ou do que as outras pessoas possam achar dele, o mais incr E vel instrumento que voc e jamais vai possuir. Dance. Mesmo que n ao tenha aonde al em de seu pr oprio quarto. Leia as instru c oes mesmo que n ao v a segui-las depois. N ao leia revistas de beleza, elas s o v ao fazer voc e se achar feio [...] imposs Dedique-se a conhecer seus pais. E vel prever quando eles ter ao ido embora, de vez. Seja legal com seus irm aos. Eles s ao a melhor ponte com o seu passado e possivelmente quem vai sempre mesmo te apoiar no futuro. Entenda que amigos v ao e vem, mas nunca abra m ao de uns poucos e bons. Esforce-se de verdade para diminuir as dist ancias geogr acas e de estilos de vida, porque quanto mais velho voc e car, Mais voc e vai precisar das pessoas que voc e conheceu quando jovem. More uma vez em Nova York, mas v a embora antes de endurecer. More uma vez no Hava , mas se mande antes de amolecer. Viaje. Aceite certas verdades inescap aveis: Os pre cos v ao subir, os pol ticos v ao saracotear, voc e tamb em vai envelhecer. E quando isso acontecer voc e vai fantasiar que quando era jovem os pre cos eram razo aveis, os pol ticos eram decentes, E as crian cas respeitavam os mais velhos. Respeite os mais velhos!! E n ao espere que ningu em segure a sua barra. Talvez voc e arrume uma boa aposentadoria privada. Talvez voc e case com um bom partido, mas n ao esque ca que um dos dois de repente pode acabar. N ao mexa demais nos cabelos se n ao quando voc e chegar aos 40 vai aparentar 85. Cuidado com os conselhos que comprar, mas seja paciente com aqueles que os oferecem. Conselho e uma forma de nostalgia. Compartilhar conselhos e um jeito de pescar o passado do lixo,

5.1. Testes

54

esfreg a-lo, repintar as partes feias e reciclar tudo por mais do que vale. Mas, no ltro solar, acredite.

Cap tulo 6 Considera co es Finais


No presente projeto foram realizados estudos sobre os protocolos da pilha TCP/IP, mais especicamente dos protocolos IP, UDP e TCP, a m de simular uma comunica ca o em rede. Essa comunica ca o e vista por muitas pessoas como uma tarefa simples, visto que, basta um computador conectar-se a ` internet para a comunica c ao em rede ocorrer. O objetivo deste projeto foi demonstrar de uma maneira simulada, o percurso que uma mensagem faz, em rede, ao ser enviada da m aquina de origem para a m aquina de destino. Foi determinado que a utiliza c ao de threads, na qual cada thread simula uma m aquina, e uma maneira vi avel de representar uma rede. O c odigo foi desenvolvido de uma forma simples atendendo o objetivo de envio e recebimento de pacotes entre duas m aquinas, demonstrando essa comunica ca o. Para ns did aticos, este projeto tamb em d a suporte a ` disciplina de Redes de Computadores, melhorando o entendimento e mostrando, na pr atica, a funcionalidade de cada protocolo, visto que em sala de aula e ministrado mais a parte te orica. Como este e um projeto inicial que visa um maior entendimento da comunica c ao em rede, apenas o b asico da comunica ca o entre m aquinas foi desenvolvido, para a continuidade deste projeto, poss veis melhorias poderiam ser feitas, como as listadas a seguir: Capacidade de recebimento de mais de um pacote por vez na rede. Uma sugest ao para que isso possa ser feito e utilizar ponteiros locais para a inser ca o de pacotes nas listas, que est ao nas fun co es recb_ip_protocol_proc e recb_tcp_protocol_proc. C alculo de checksum dos protocolos IP, UDP e TCP. Este c alculo possibilitaria a verica ca o da integridade dos dados que s ao transmitidos pelos protocolos citados anteriormente. Desenvolvimento de tabelas de roteamento para o protocolo IP, que decide qual rota o pacote deve seguir. Uma sugest ao e criar estruturas que simulariam as tabelas de roteamento, estas estruturas poderiam armazenar: 55

56

Endere co IP da m aquina destino; Endere co IP do roteador mais pr oximo e Tipo de entrega, que informar a se a entrega e direta ou indireta. Fazer uma vers ao distribu da do programa, que possibilita a comunica ca o de mais de duas m aquinas em uma rede.

Ap endice A Principais fun c oes implementadas


apresentado nesse ap E endice, o c odigo-fonte das principais fun co es que realiza a comunica ca o entre as m aquinas.
/ V a r i a v e i s g l o b a i s / / V a r i a v e l g l o b a l que s i m u l a o barramento , no q u a l , as m a quinas podem l e r ou e s c r e v e r dados . Essa v a r i avel e a l o c a d a na main . / char g d a t a c h a n n e l ; / Contadora que d e t e r m i n a s e o barramento e s t a l i v r e ou ocupado para a e s c r i t a . / int c a n a l o c u p a d o ; / Fun c a o main / int main ( ) { int i ; int n t c p i p s t a c k s = 0 ; // i n i c i a l i z a ca o de v a r i aveis globais qnt conexoes = 0; p r i m e i r o i p = NULL; u l t i m o i p = NULL; ultimo ip = primeiro ip ; p r i m e i r o t c p = NULL; u l t i m o t c p = NULL; ultimo tcp = primeiro ip ; f o r ( i =0; i < 256; i ++) conexoes [ i ] . status = 0;

57

58

g d a t a c h a n n e l = ( char ) m a l l o c ( TAM CANAL s i z e o f ( char ) ) ; i f ( g d a t a c h a n n e l == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados de aplicacao : g_data_channel ") ; exit (1) ; } d a d o s t c p = ( char ) m a l l o c ( TAM CANAL s i z e o f ( char ) ) ; i f ( d a d o s t c p == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados ." ) ; exit (1) ; } // I n i c i a n d o sem a foro l i b e r a d o para e s c r i t a na t a b e l a de c o n e x oes . s e m i n i t (& s e m e s c r c o n e x , 0 , 1 ) ; // I n i c i a n d o d o sem a foro de c a n a l l i b e r a d o . a s s e r t ( s e m i n i t (& sem canal , 0 , 1 ) == 0 ) ; / A t h r e a d c a n a l f o i c r i a d a e s p e c i f i c a m e n t e para c o n t r o l a r a e n t r a d a de dados no c a n a l sendo que d u r a n t e o tempo i g u a l a CONT CANAL a thread bloquear a a e n t r a d a de dados no barramento ( g d a t a c h a n n e l ) , ap o s o d e c o r r e r do tempo , e l a l i b e r a r a o c a n a l para e s c r i t a novamente , i s t o f a r a com que s e o p a c o t e n ao c h e g a r ` a m a quina c o r r e t a d u r a n t e e s t e tempo o p a c o t e s e r a p e r d i d o . / p t h r e a d c r e a t e (& t h r e a d c a n a l , NULL, l i b e r a c a n a l , NULL) ; // Cria c a o da p i l h a t c p / i p f o r ( i =0; i <MAX TCPIP STACKS ; i ++) { char s t r i p a d d r [MAX ADDR STR LEN ] ; s p r i n t f ( s t r i p a d d r , BASE ADDR STR, n t c p i p s t a c k s +1) ; // a t r i b u i n d o o v a l o r f i n a l do i p // Cria a t h r e a d da p i l h a TCP/IP . i f ( p t h r e a d c r e a t e (& t c p i p t h r e a d s [ i ] , NULL, t c p i p t h r e a d p r o c , s t r i p a d d r ) == 0 ) { n t c p i p s t a c k s ++; } S l e e p ( 1 0 0 ) ; // e s p e r a para c r i a r a proxima t h r e a d } // Esperando o t h r e a d t e r m i n a r . f o r ( i =0; i < n t c p i p s t a c k s ; i ++) p t h r e a d j o i n ( t c p i p t h r e a d s [ i ] , NULL) ;

59

f f l u s h ( stdout ) ; return 0 ; } / Fun c a o t c p i p t h r e a d p r o c / / E s t e e o p r o c e d i m e n t o p r i n c i p a l da t h r e a d TCP/IP . Toda i n i c i a l i z a d a c a o da p i l h a TCP/IP d e v e s e r f e i t a a q u i . O par a metro ( v o i d d a t a ) e o endere co i p da m a quina . O e n d e r e c o IP d e s t i n o e l i d o de um a r q u i v o t x t . / void t c p i p t h r e a d p r o c ( void data ) { char comando [ 1 2 ] ; char a r q u i v o [ 3 2 ] ; char aux [ 3 2 ] ; char msg ; struct My socket s ; s i z e t len ; int r e p = 0 ; FILE f p ; a s s e r t ( data != NULL ) ; s t r c p y ( a r q u i v o , ( char ) data ) ; s t r c a t ( a r q u i v o , ".txt" ) ; / Abre a r q u i v o que cont em a c o n f i g u r a c a o IP . / f p = f o p e n ( a r q u i v o , "r" ) ; i f ( ! fp ) { p r i n t f ( "\ nErro ao abrir o arquivo \n" ) ; e x i t ( 1) ; } / Lendo o comando : send , re cb , c o n n e c t t c p , ou l i s t e n t c p . / f s c a n f ( fp , "%s" , &comando ) ; / A v a r i a v e l msg r e c e b e os dados que s e r a enviado ` a m a quina d e s t i n o . / msg = ( char ) m a l l o c (TAM CANAL s i z e o f ( char ) ) ; i f ( msg == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados ." ) ; exit (1) ; } i f ( strcmp ( comando , "send" ) == 0 ) { a v e l data . // s . i p s r c r e c e b e o v a l o r c o n v e r t i d o da v a r i

60

s . i p s r c = c o n v e r t e i p s t r t o u n s i g n e d ( ( char ) data ) ; // Terminando de l e r os dados de c o n f i g u r a c ao . send ( s , msg , f p ) ; l e n = s t r l e n ( msg ) +1; // armazena tamanho da mensagem mais o \ 0 p r i n t f ( "\n\ nMaquina de origem : %s\n\n" , ( char ) data ) ; p r i n t f ( "\ nMensagem a ser enviada :\n %s\n\n" , msg ) ; envia app msg ( s , msg , l e n ) ; // e n v i a n d o para a camada de a p l i c a c ao f c l o s e ( fp ) ; } else { i f ( strcmp ( comando , "recb" ) == 0 ) { rep = 0 ; s t r c p y ( aux , ( char ) data ) ; / Recebendo n v e z e s da camada de f sica , necess a r i o c a s o os dados e s t e j a m f r a g m e n t a d o s / while ( r e p !=1000) { Sleep (100) ; r e c b f i s i c a c a m a d a p r o c ( aux ) ; r e p++; } f c l o s e ( fp ) ; } else { i f ( strcmp ( comando , " connect_tcp " ) == 0 ) { c o n n e c t t c p ( fp , data ) ; f c l o s e ( fp ) ; } e l s e / l i s t e n t c p / { unsigned p o r t a d e s t ; int r e p = 0 ; / l e n d o a p o r t a d e s t i n o que s e e n c o n t r a no a r q u i v o de e n t r a d a / f s c a n f ( fp , "%d " , &p o r t a d e s t ) ; / chamada da f u n c a o l i s t e n t c p / l i s t e n t c p ( data , p o r t a d e s t ) ;

61

f c l o s e ( fp ) ; rep = 0 ; / La c o para e s p e r a r a chegada dos dados do t c p / while ( r e p !=1000) { Sleep (100) ; r e c b f i s i c a c a m a d a p r o c ( data ) ; r e p++; } } } } } / Fun c a o l i b r a c a n a l / / Fun c a o para decrementar a v a r i a v e l g l o b a l c a n a l o c u p a d o . / void l i b e r a c a n a l ( void ) { while ( 1 ) { / Espera 1 segundo para decrementar a v a r i a v e l g l o b a l c a n a l o c u p a d o / Sleep (1000) ; / Sem a foro para n ao h a v e r i n c o n s i s t e n c i a dos dados / sem wait (& s e m c a n a l ) ; / Enquanto c a n a l o c u p a d o f o r maior que z e r o e l e e decrementado / i f ( canal ocupado > 0 ) c a n a l o c u p a d o ; sem po st (& s e m c a n a l ) ; // l i b e r a n d o sem a fora para t h r e a d t e n t a r f a z e r a l e i t u r a do barramento . } } / Fun c a o c o n n e c t t c p / / Fun c a o que pede o e s t a b e l e c i m e n t o de comunica c a o e n t r e duas m a quinas , e s p e r a a r e s p o s t a . E ap os a confirma ca o da r e s p o s t a e n v i a os dados . / void c o n n e c t t c p ( FILE fp , void i p ) { struct T c p p r o t o c o l o t c p ; char d a d o s c o n e x a o ; int i = 0 ; char aux [ 3 2 ] ; sem wait (& s e m e s c r c o n e x ) ;

62

/ q n t c o n e x o e s i g u a l a zer o , n a o ha nenhuma conex a o TCP e s t a b e l e c i d a a in da l o g o e marcado na t a b e l a de c o n e x o e s o p e d i d o . / i f ( q n t c o n e x o e s == 0 ) { / Marcando na t a b e l a de conex o es , os dados da m a quina que e s t a r e q u e r e n d o uma conex a o . L e do a r q u i v o . t x t . / conexoes [ qnt conexoes ] . ip origem = c o n v e r t e i p s t r t o u n s i g n e d (( char ) i p ) ; f s c a n f ( fp , "%s" , &aux ) ; c o n e x o e s [ q n t c o n e x o e s ] . i p d e s t i n o = c o n v e r t e i p s t r t o u n s i g n e d ( aux ); f s c a n f ( fp , "%d" , &c o n e x o e s [ q n t c o n e x o e s ] . p o r t a o r i g e m ) ; f s c a n f ( fp , "%d" , &c o n e x o e s [ q n t c o n e x o e s ] . p o r t a d e s t i n o ) ; f s c a n f ( fp , "%c" , &d a d o s t c p [ 0 ] ) ; / Copiando para a v a r i a v e l g l o b a l os dados que d e v e r ao ser enviados para a m a quina d e s t i n o ap o s a conex a o t c p s e r e s t a b e l e c i d a . / do { dados tcp [ i ] = getc ( fp ) ; p r i n t f ( "%c" , d a d o s t c p [ i ] ) ; // g l o b a l i ++; } while ( d a d o s t c p [ i 1] != EOF) ; d a d o s t c p [ i 1] = \0 ; tam tcp= s t r l e n ( d a d o s t c p ) + 1 ; / Gerando os dados no c a b e c a l h o que i n d i c a um p e d i d o de conex a o . / g e r a d a d o s c o n e x a o ( tcp , c o n e x o e s [ q n t c o n e x o e s ] . p o r t a o r i g e m , conexoes [ qnt conexoes ] . porta destino ) ; d a d o s c o n e x a o = ( char ) m a l l o c ( s i z e o f ( struct T c p p r o t o c o l o ) s i z e o f ( char ) ) ; i f ( d a d o s c o n e x a o == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados ." ) ; exit (1) ; } / Encapsulando dados para encaminhar para o p r o t o c o l o IP . / memcpy ( dados conexao , &tcp , s i z e o f ( struct T c p p r o t o c o l o ) ) ; / Enviando dados para camada IP . / e n v i a i p p r o t o c o l p r o c ( dados conexao , s i z e o f ( struct T c p p r o t o c o l o ) , TCP PROTO, c o n e x o e s [ q n t c o n e x o e s ] . i p o r i g e m , , c o n e x o e s [ qnt conexoes ] . ip destino ) ; / Ap o s o p a c o t e c h e g a r no barramento , a v a r i avel ( qnt conexoes )

63

r e c e b e o v a l o r 1 i n d i c a n d o que h a um p e d i d o de conex a o TCP. / q n t c o n e x o e s ++; sem po st (& s e m e s c r c o n e x ) ; } i =0; / Esperando c h e g a r dados de c o n f i r m a c a o para e n v i a r os dados c o n t i d o s em d a d o s t c p . A f u n c ao r e c b f i s i c a c a m a d a p r o c e s t a d e n t r o de um la c o p o i s o p r o t o c o l o TCP r e c e b e e e n v i a dados a t r a v e s da f u n c ao r e c b t c p p r o t o c o l p r o c / while ( i !=1000) { Sleep (100) ; r e c b f i s i c a c a m a d a p r o c ( ( char ) i p ) ; i ++; } } / Fun c a o l i s t e n t c p / / Esta f u n ca o e s p e r a que h a j a um p e d i d o de conex a o , para que assim r e t o r n e uma mensagem confirmando a conex a o . / void l i s t e n t c p ( void i p o r i g e m , unsigned p o r t a d e s t i n o ) { bool r e c b = f a l s e ; while ( ! r e c b ) { / Aqui v e r i f i c a : s e h a algum p e d i d o de conex a o , ou s e j a , qnt conex o e s == 1 . Se a p o r t a d e s t i n o c o n t i d a na t a b e l a de conexao e a mesma p o r t a que a m a quina d e s t i n o e s t a esperando para r e c e b e r os dados . E s e o i p d e s t i n o c o n t i d o na t a b e l a de conex oes e o mesmo da m a quina que e s t a chamando a f u n c ao l i s t e n t c p / i f ( ( q n t c o n e x o e s == 1 ) && ( c o n e x o e s [ 0 ] . p o r t a d e s t i n o == p o r t a d e s t i n o ) && ( strcmp ( ( char ) i p o r i g e m , ( char ) c o n e x o e s [ 0 ] . p o r t a d e s t i n o ) == 0 ) ) { / A mensagem que e r e c e b i d a a q u i p o s s u i ack == 0 e syn ==1 / r e c b f i s i c a c a m a d a p r o c ( ( char ) i p o r i g e m ) ; r e c b = true ; } } } / Fun c a o e n v i a a p p m s g / / Se e s t a f u n c ao e chamada , os dados s a o e n v i a d o s para a camada UDP, uma

64

v e z que , da maneira que f o i implementado , o p r o t o c o l o TCP n a o p a s s a os dados para a camada de a p l i c a c a o / void envia app msg ( struct My socket& s , char msg , unsigned l e n ) { switch ( s . t r a n s p p r o t o ) { case UDP PROTO: { e n v i a u d p p r o t o c o l p r o c ( msg , l e n , s ) ; break ; } } } / Fun c a o e n v i a t c p p r o t o c o l p r o c / / Esta f u n ca o r e c e b e como dados , ( msg ) , um c a b e c a l h o t c p contendo as informa c o e s dos pr o ximos dados que devem s e r e n v i a d o s . Depois e n v i a para o p r o t o c o l o IP , dados que e s t a v a no a r q u i v o . t x t , com ou sem fragmenta c a o dependendo do seu tamanho . / void e n v i a t c p p r o t o c o l p r o c ( char msg , s i z e t tam msg ) { struct T c p p r o t o c o l o tcpAux ; struct T c p p r o t o c o l o tcpMSG ; char dados ; char pt ; s i z e t tam = tam tcp ; s i z e t tam aux ; / p t aponta para o i n c i o dos dados que estavam no a r q u i v o . t x t . / pt = d a d o s t c p ; / D e s e n c a p s u l a o p a c o t e que chegou no p r o t o c o l o TCP. / memcpy(&tcpAux , msg , tam msg ) ; / A t r a v e s das i n f o r m a c o e s c o n t i d o s em tcpAux e g e r a d o um novo c a b e calho para os d a d o s t c p , e s t e s dados s e r a o e n v i a d o s para o p r o t o c o l o IP / tam aux = g e r a t c p c a b e c a l h o ( tcpMSG , tcpAux , pt , tam ) ; dados = ( char ) m a l l o c ( ( tam aux+ s i z e o f (tcpMSG) ) s i z e o f ( char ) ) ; i f ( dados == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados tcp" ) ; exit (1) ; } / Encapsulando o c a b e c a l h o e dados tcp , para a v a r i a v e l dados . / memcpy ( dados , &tcpMSG , s i z e o f (tcpMSG) ) ;

65

memcpy ( dados+ s i z e o f (tcpMSG) , tcpMSG . dados , tam aux ) ; / Enviando os dados e n c a p s u l a d o s para o p r o t o c o l o IP . / e n v i a i p p r o t o c o l p r o c ( dados , ( tam aux+ s i z e o f (tcpMSG) ) ,TCP PROTO, conexoes [ 0 ] . ip origem , conexoes [ 0 ] . i p d e s t i n o ) ; f r e e ( dados ) ; } / Fun c a o e n v i a u d p p r o t o c o l p r o c / / UDP N ao f a z f r a g m e n t a c a o . Os dados da camada de cima s a o p a s s a d o s ao UDP e s a o c o l o c a d o s no campo de dados de um datagrama UDP que por sua v e z e p a s s a d o ao IP para s e r t r a n s p o r t a d o num datagrama IP , que pode e v e n t u a l m e n t e s e r f ra gmen t a d o / void e n v i a u d p p r o t o c o l p r o c ( char msg , s i z e t tam msg , struct My socket s ) { struct U d p p r o t o c o l o udpMSG ; char dados udp ; s i z e t tam udp ; / Gerando c a b e c a l h o UDP. / g e r a u d p c a b e c a l h o (udpMSG, msg , tam msg , s ) ; tam udp = tam msg + ( s i z e o f (udpMSG) ) ; dados udp = ( char ) m a l l o c ( tam udp s i z e o f ( char ) ) ; i f ( dados udp == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados udp" ) ; exit (1) ; } / Copiando o c a b e c a l h o e dados UDP, para a v a r i a v e l dados udp . / memcpy ( dados udp , &udpMSG, s i z e o f (udpMSG) ) ; memcpy ( dados udp+ s i z e o f (udpMSG) , udpMSG . dados , tam msg ) ; e n v i a i p p r o t o c o l p r o c ( dados udp , tam udp , UDP PROTO, s . i p s r c , s . ip dst ) ; f r e e ( dados udp ) ; dados udp = NULL; f r e e (udpMSG . dados ) ; } / Fun c a o e n v i a i p p r o t o c o l p r o c / / O p r o t o c o l o IP u t i l i z a o encaminhamento de e n t r e g a d i r e t o , j a que e s u p o s t o que t o d a s as m a quinas , e m i s s o r a e r e c e p t o r a , e s t a o na mesma r e d e . / void e n v i a i p p r o t o c o l p r o c ( char d a d o s t r a n s , s i z e t tam trans , unsigned

66

p r o t t r a n s p o r t e , unsigned i p o r i g e m , unsigned i p d e s t ) { struct I p p r o t o c o l o ipMSG ; // E s t r u t u r a do c a b e c a l h o IP / char d a d o s i p ; // dados e n c a p s u l a d o do f r a g m e n t o ip , com o seu cabe calho char p t i n i ; // p o t e i r o para s a b e r onde comeca a f r a g m e n t a c a o dos pacotes char d a t a f r a g ; // v a r i a v e l que r e c e b e r a a p a r t e fr a gmen ta d a dos dados s i z e t tam ip ; float qnt frag ; // c a s o s e j a n e c e s s a r i o f ra gme nt a r , a v a r i a v e l qnt conter a a q u a n t i d a d e de p a c o t e s i p que s e r ao enviados int i ; int r e s t o ; // V a r i a v e l que c o n t e r a o tamanho do u l t i m o p a c o t e , p o i s e s t e pode s e r menor que o tamanho de MTU IP / V e r i f i c a n d o s e ha n e c e s s i d a d e de f r a g m e n t a r os dados v i n d o da camada de t r a n s p o r t e . Caso o v a l o r de ( q n t f r a g ) s e j a ( 1 ) , nao s e r a n e c e s s a r i o fra gm en t a r , c a s o s e j a maior , o i p n e c e s s i t a r a f r a g m e n t a r o p a c o t e / q n t f r a g = c e i l ( ( f l o a t ) t a m t r a n s / (MTU IP s i z e o f ( struct I p p r o t o c o l o ) )); / V e r i f i c a n d o s e o p a c o t e que vem do p r o t o c o l o UDP, p o s s u i v a l o r menor i g u a l ou maior que a MTU IP ( tamanho m aximo de dados que o p r o t o c o l o IP s u p o r t a e n v i a r , n e s t e caso , f o i d et ermin a d o 1500) . Caso e s t e tamanho s e j a menor i g u a l , o p r o t o c o l o IP n ao n e c e s s i t a r a fragmentar os dados que vem da camada UDP. Caso o tamanho s e j a maior , h a v e r a fragmenta c a o dos dados . / i f ( q n t f r a g == 1 ) { / Gerando o c a b e c a l h o IP quando nao eh n e c e s s a r i o f r a g m e n t a r o p a c o t e udp . / g e r a i p c a b e c a l h o (ipMSG , d a d o s t r a n s , tam trans , 1 , i p o r i g e m , ip dest , qnt frag , prot transporte ) ; / Copiando o c a b e c a l h o e dados Ip , para a v a r i a v e l d a t a . / tam ip = t a m t r a n s + ( s i z e o f (ipMSG) ) ; // r e c e b e o v a l o r dos dados de t r a n s p o r t e mais o v a l o r do c a b e c a l h o IP . d a d o s i p = ( char ) m a l l o c ( tam ip s i z e o f ( char ) ) ; // a l o c a n d o mem o ria para e n c a p s u l a r o c a b e c a l h o IP mais s e u s dados . i f ( d a d o s i p == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados ip" ) ;

67

exit (1) ; } memcpy ( d a d o s i p , &ipMSG , s i z e o f (ipMSG) ) ; // Copiando o c a b e calho IP memcpy ( d a d o s i p+ s i z e o f (ipMSG) , ipMSG . dados , t a m t r a n s ) ; // c o p i a n d o os dados de IP / Enviando para a camada de e n l a c e . / e n v i a e n l a c e c a m a d a p r o c ( d a d o s i p , tam ip , i p o r i g e m , i p d e s t ) ; } / N e c e s s i d a d e do p r o t o c o l o IP f r a g m e n t a r o p a c o t e da camada de t r a n s p o r t e / else { p t i n i = d a d o s t r a n s ; // p o n t e i r o r e c e b e n d o o e n d e r e c o dos dados de transporte / La c o que f a r a a f r a g m e n t a c a o e e n v i o dos dados ip , para a camada de e n l a c e / f o r ( i =0; i < ( int ) q n t f r a g ; i ++) { / Condi c a o que v e r e f i c a s e e o u l t i m o p a c o t e / i f ( i == q n t f r a g 1) { r e s t o = ( t a m t r a n s ( ( q n t f r a g 1 ) (MTU IP s i z e o f ( struct I p p r o t o c o l o ) ) ) ) ; // C a l c u l o para s a b e r o r e s t o d a t a f r a g = ( char ) m a l l o c ( r e s t o s i z e o f ( char ) ) ; // Alocando memoria para o u l t i m o p a c o t e i f ( d a t a f r a g == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados ip - data frag -- resto " ) ; exit (1) ; } / Copiando os dados para d a t a f r a g , d a t a f r a g r e c e b e a p a r t i r do e n d e r e c o de ( p t i n i + i MTU IP) que e a posi c a o do p o n t e i r o na v a r i a v e l d a t a . / memcpy ( d a t a f r a g , p t i n i + i (MTU IP s i z e o f ( struct Ip protocolo ) ) , resto ) ; tam ip = r e s t o ; } e l s e //N ao e o u l t i m o p a c o t e do f r a g m e n t o . { / Fazendo f r a g m e n t a ca o do p a c o t e r e c e b i d o da camada de t r a n s p o r t e , d a t a f r a g r e c e b e a p a r t i r do e n d e r e c o de ( p t i n i + i MTU IP) , que e a posi c a o do p o n t e i r o na

68

vari a v e l d a t a . / d a t a f r a g = ( char ) m a l l o c ( (MTU IP s i z e o f ( struct I p p r o t o c o l o ) ) s i z e o f ( char ) ) ; i f ( d a t a f r a g == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados ip - data frag" ) ; exit (1) ; } memcpy ( d a t a f r a g , p t i n i + ( i (MTU IP s i z e o f ( struct I p p r o t o c o l o ) ) ) , (MTU IP s i z e o f ( struct Ip protocolo ) ) ) ; tam ip = (MTU IP s i z e o f ( struct I p p r o t o c o l o ) ) ; } / Gerando o c a b e c a l h o i p para o f r a g m e n t o . / g e r a i p c a b e c a l h o (ipMSG , d a t a f r a g , tam ip , i +1, i p o r i g e m , ip dest , qnt frag , prot transporte ) ; d a d o s i p = ( char ) m a l l o c ( ( tam ip + ( s i z e o f (ipMSG) ) ) s i z e o f ( char ) ) ; i f ( d a d o s i p == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados ip - data frag" ) ; exit (1) ; } / Encapsulando p a c o t e IP , c o p i a n d o os dados i p para o p a c o t e que s e r a e n v i a d o para a camada de e n l a c e / memcpy ( d a d o s i p , &ipMSG , s i z e o f (ipMSG) ) ; // c o p i a do c a b e calho memcpy ( d a d o s i p+ s i z e o f (ipMSG) , d a t a f r a g , tam ip ) ; // c o p i a dos dados tam ip = tam ip + ( s i z e o f (ipMSG) ) ; // t a m i p e p a s s a d o contend o o v a l o r do c a b e c a l h o i p mais os dados i p / Enviando para a camada de e n l a c e . / e n v i a e n l a c e c a m a d a p r o c ( d a d o s i p , tam ip , i p o r i g e m , i p d e s t ) ; free ( data frag ) ; d a t a f r a g = NULL; f r e e ( dados ip ) ; d a d o s i p = NULL; } // fim do f o r de f r a g m e n t a c a o } // fim do e l s e f r e e ( dados ip ) ;

69

d a d o s i p = NULL; f r e e (ipMSG . dados ) ; } / Fun c a o e n v i a e n l a c e p r o t o c o l p r o c / / Esta f u n ca o r e c e b e os dados v i n d o s do p r o t o c o l o IP , a d i c i o n a o c a b e calho de e n l a c e e e n v i a para a camada f i s i c a . / void e n v i a e n l a c e c a m a d a p r o c ( char d a d o s i p , s i z e t tam ip , unsigned i p o r i g e m , unsigned i p d e s t ) { struct e n l a c e p r o t o c o l o enlaceMSG ; s i z e t tam enlace ; char d a d o s e n l a c e ; / Gerando c a b e c a l h o de e n l a c e . / g e r a e n l a c e c a b e c a l h o ( enlaceMSG , d a d o s i p , tam ip , i p o r i g e m , i p d e s t ) ; / Copiando o c a b e c a l h o e dados de e n l a c e para a v a r i avel dados enlace . / t a m e n l a c e = tam ip + ( s i z e o f ( enlaceMSG ) ) ; d a d o s e n l a c e = ( char ) m a l l o c ( t a m e n l a c e s i z e o f ( char ) ) ; i f ( d a d o s e n l a c e == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados enlace " ) ; exit (1) ; } memcpy ( d a d o s e n l a c e , &enlaceMSG , s i z e o f ( enlaceMSG ) ) ; // c o p i a do cabe c a l h o de e n l a c e memcpy ( d a d o s e n l a c e+ s i z e o f ( enlaceMSG ) , enlaceMSG . dados , tam ip ) ; // c o p i a dos dados de e n l a c e envia fisica camada proc ( dados enlace , tam enlace ) ; } / Fun c a o e n v i a f i s i c a p r o t o c o l p r o c / / Envia os dados para o barramento , v a r i a v e l c o m p a r t i l h a d a g d a t a c h a n n e l . / void e n v i a f i s i c a c a m a d a p r o c ( char data , s i z e t &l e n ) { bool e n v i o u = f a l s e ; / V e r i f i c a n d o s e pode s e r f e i t a a e s c r i t a , c a s o o c a n a l e s t e j a com v a l o r ze ro , s i g n i f i c a que o c a n a l e s t a l i v r e para e s c r i t a , c a s o c o n t r a r i o , h a dados no c a n a l e e l e e s t a l i b e r a d o apenas para l e i t u r a . / while ( ! e n v i o u )

70

{ / U t i l i z a semaforo para g a r a n t i r a c o n s i s t e n c i a dos dados , uma v e z que s e e s t a e s c r e v e n d o em uma v a r i a v e l g l o b a l , assim apenas um t h r e a d por v e z pode t e r a c e s s o ao c a n a l . Caso uma segunda t h r e a d t e n t e e s c r e v e r no c a n a l e l a d e v e r a esperar a variavel c a n a l o c u p a d o , v o l t a r a z e r a r . / sem wait (& s e m c a n a l ) ; i f ( c a n a l o c u p a d o == 0 ) { memcpy ( g d a t a c h a n n e l , data , l e n ) ; g data len = len ; / R e i n i c i a o c o n t a d o r do c a n a l para que as maquinas possam l e r os dados do barramento , i s t o e i m p o r t a n t e , p o i s da tempo para os t h r e a d s que e s t a o t e n t a n d o r e c e b e r a mensagem a c e s s a r o barramento e f a z e r a l e i t u r a . / c a n a l o c u p a d o = CONT CANAL; e n v i o u = true ; } sem po st (& s e m c a n a l ) ; } } / Fun c a o r e c b f i s i c a p r o t o c o l p r o c / / Recebe b y t e s de m dia f s i c a / void r e c b f i s i c a c a m a d a p r o c ( void i p ) { char data ; s i z e t len ; bool r e c e b e u = f a l s e ; / V e r i f i c a n d o s e maquinas podem f a z e r a l e i t u r a de dados do barramento . A l e i t u r a s o o c o r r e s e a v a r i a v e l g l o b a l c a n a l o c u p a d o f o r maior que z e r o e s e o v a l o r de g d a t a l e n f o r maior que z e r o . / while ( ! r e c e b e u ) { sem wait (& s e m c a n a l ) ; i f ( c a n a l o c u p a d o > 0 && g d a t a l e n > 0 ) { / Copiando os dados do barramento para a v a r i a v e l d a t a / data = ( char ) m a l l o c ( g d a t a l e n s i z e o f ( char ) ) ; i f ( data == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados enlace " ) ;

71

exit (1) ; } memcpy ( data , g d a t a c h a n n e l , g d a t a l e n ) ; len = g data len ; r e c e b e u = true ; } sem po st (& s e m c a n a l ) ; } / Fazendo a e n t r a g a do p a c o t e para a camada de e n l a c e / r e c b e n l a c e c a m a d a p r o c ( data , l e n , i p ) ; f r e e ( data ) ; data = NULL; } / Fun c a o r e c b e n l a c e p r o t o c o l p r o c / / A camada de e n l a c e d e s e n c a p s u l a r a os dados , ou s e j a , t i r a o c a b e c a l h o de e n l a c e e encaminha para o p r o t o c o l o IP / void r e c b e n l a c e c a m a d a p r o c ( char d a d o s e n l a c e , s i z e t &t a m e n l a c e , void ip dst ) { struct e n l a c e p r o t o c o l o enlaceMSG ; char data aux ; s i z e t tam ip = t a m e n l a c e s i z e o f ( enlaceMSG ) ; memcpy (&enlaceMSG , d a d o s e n l a c e , s i z e o f ( struct e n l a c e p r o t o c o l o ) ) ; // Copiando apenas o c a b e c a l h o para a e s t r u t u r a de e n l a c e data aux = ( char ) m a l l o c ( tam ip s i z e o f ( char ) ) ; i f ( data aux == NULL) { p r i n t f ( "\n\ nErro da alocacao dos dados enlace " ) ; exit (1) ; } / Copiando os dados , e x c e t o o c a b e c a l h o de e n l a c e / memcpy ( data aux , d a d o s e n l a c e + s i z e o f ( struct e n l a c e p r o t o c o l o ) , tam ip ) ; / Encaminhando para o p r o t o c o l o i p / r e c b i p p r o t o c o l p r o c ( data aux , tam ip , i p d s t ) ; f r e e ( data aux ) ; } / Fun c a o r e c b i p p r o t o c o l p r o c / / Esta f u n ca o armazena os p a c o t e s r e c e b i d o s da camada de e n l a c e . Ap os r e c e b e r t o d o s os dados , o p r o t o c o l o IP os une em um u nico pacote , e o

72

e n v i a a camada de t r a n s p o r t e . / void r e c b i p p r o t o c o l p r o c ( char d a d o s i p , s i z e t &l e n , void i p d s t ) { int v e r i f i d ; s i z e t tam msg ; unsigned i p d e s t ; struct dadosRemontagem x ; struct I p p r o t o c o l o ipMSG ; char data aux ; / Convertendo o i p da maquina que e s t a r e c e b e n d o os dados para u n s i g n e d / i p d e s t = c o n v e r t e i p s t r t o u n s i g n e d ( ( char ) i p d s t ) ; / Copiando c a b e c a l h o IP para a e s t r u t u r a ipMSG / memcpy (&ipMSG , d a d o s i p , s i z e o f ( struct I p p r o t o c o l o ) ) ; / tam msg r e c e b e o tamanho dos dados menos o tamanho do c a b e c a l h o IP / tam msg = l e n s i z e o f ( struct I p p r o t o c o l o ) ; a no / Compara s e o e n d e r e c o IP d e s t i n o (ipMSG . i p d e s t i n o ) que e s t cabe c a l h o dos dados que acaba de c h e g a r e o mesmo da m a quina que est a r e c e b e n d o os dados ( i p d e s t ) . / i f ( ipMSG . i p d e s t i n o == i p d e s t ) { / Desempacotando a msg c o n t i d a na v a r i a v e l d a d o s i p / data aux = ( char ) m a l l o c ( tam msg s i z e o f ( char ) ) ; // a l o c a n d o e s p a c o para os dados i f ( data aux == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } c a l h o IP / / d a t a a u x r e c e b e os dados sem o c a b e memcpy ( data aux , d a d o s i p + s i z e o f ( struct I p p r o t o c o l o ) , tam msg ); / Passando os dados para a l i s t a encadeada / x = ( struct dadosRemontagem ) m a l l o c ( s i z e o f ( struct dadosRemontagem )); completaDados ( x , data aux , tam msg , ipMSG . F r a g m e n t O f f s e t ) ; / i n s e r i n d o os dados de x na l i s t a / insereNaLista (x , primeiro ip , ultimo ip ) ; f r e e ( data aux ) ; data aux = NULL;

73

/ V e r i f i c a n d o s e t o d o s os p a c o t e s do p r o t o c o l o i p chegou , s e t o d o s os p a c o t e s chegaram , v e r i f i c a i p r e t o r n a r a um v a l o r maior que z e r o / v e r i f i d = v e r i f i c a I D ( p r i m e i r o i p , ipMSG) ; / Caso t o d o s os f r a g m e n t o s tenham ch e go . / i f ( v e r i f i d > 0) { / Retorna o tamanho t o t a l dos dados sem o c a b e c a l h o i p / tamanhoDados ( tam msg , p r i m e i r o i p ) ; data aux = ( char ) m a l l o c ( tam msg s i z e o f ( char ) ) ; i f ( data aux == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } / Faz a c o p i a dos dados que e s t a o na l i s t a e p a s s a para d a t a a u x / copiaDados ( data aux , tam msg , p r i m e i r o i p ) ; / Encaminhando os dados para a camada de t r a n s p o r t e / i f (ipMSG . p r o t o c o l o t r a n s p o r t e == UDP PROTO) // e n v i a n d o para UDP r e c b u d p p r o t o c o l p r o c ( data aux , tam msg ) ; else r e c b t c p p r o t o c o l p r o c ( data aux , tam msg , ipMSG . i p o r i g e m , ipMSG . i p d e s t i n o ) ; } } f r e e ( data aux ) ; data aux = NULL; } / Fun c a o r e c b t c p p r o t o c o l p r o c / / Esta f u n c a o ao r e c e b e r os dados , a n a l i s a os campos ack e syn e toma uma decis a o do que f a z e r com o p a c o t e r e c e b i d o . / void r e c b t c p p r o t o c o l p r o c ( char data , s i z e t &l e n , unsigned i p s r c , unsigned i p d s t ) { struct T c p p r o t o c o l o tcpMSG ; struct T c p p r o t o c o l o tcpAUX ; struct dadosRemontagem x ; char dados ; s i z e t tam msg ; / Desencapsulando dados r e c e b i d o s /

74

memcpy (&tcpMSG , data , s i z e o f ( struct T c p p r o t o c o l o ) ) ; / V e r i f i c a n d o os dados r e c e b i d o s . Se ack t i v e r v a l o r z e r o e syn v a l o r um, uma m a quina e s t a querendo e s t a b e l e c e r conex a o , a mensagem r e c e b i d a f o i e n v i a d a p e l a c o n n e c t t c p . A m a quina de d e s t i n o r e s p o n d e que e s t a d i s p o n v e l para o e s t a b e l e c i m e n t o , e s t a r e s p o s t a e chamada na f u n ca o l i s t e n t c p . / i f (tcpMSG . ack == 0 && tcpMSG . syn ==1) { i f ( i p d s t == c o n e x o e s [ 0 ] . i p d e s t i n o ) { / Sera g e r a d o um c a b e c a l h o para c o n f i r m a r o e s t a b e l e c i m e n t o de conexao , a t r a v e s da f u n c a o c o n f i r m a r e s p o s t a . Esta f u n c ao informa que j a pode s e r e n v i a d o os dados c o n t i d o s no a r q u i v o . t x t e que e s p e r a os dados a p a r t i r do p r i m e i r o b i t . / c o n f i r m a r e s p o s t a ( tcpAUX , c o n e x o e s [ 0 ] ) ; / Escrevendo na t a b e l a de c o n e x o e s / conexoes [ qnt conexoes ] . ip origem = i p s r c ; conexoes [ qnt conexoes ] . porta origem = conexoes [ qnt conexoes 1]. porta destino ; conexoes [ qnt conexoes ] . i p d e s t i n o = conexoes [ qnt conexoes 1 ] . ip origem ; conexoes [ qnt conexoes ] . porta destino = conexoes [ qnt conexoes 1]. p o r t a o r i g e m ; conexoes [ qnt conexoes ] . status = 2; dados = ( char ) m a l l o c ( s i z e o f ( tcpAUX ) s i z e o f ( char ) ) ; i f ( dados == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } // Encapsulando a mensagem de c o n f i r m a c ao . memcpy ( dados , &tcpAUX , s i z e o f ( tcpAUX ) ) ; // Enviando os dados para a maquina de origem e n v i a i p p r o t o c o l p r o c ( dados , s i z e o f ( tcpAUX ) , TCP PROTO, conexoes [ 0 ] . ip destino , conexoes [ 0 ] . ip origem ) ; f r e e ( dados ) ; q n t c o n e x o e s ++; } } else { / A maquina de origem , que e n v i a os dados do a r q u i v o . t x t , acaba de r e c e b e r uma c o n f i r m a c a o que j a pode e n v i a r os dados ,

75

a fun ca o e n v i a t c p p r o t o c o l p r o c e n v i a os dados para a maquina d e s t i n o . / i f ( i p d s t == c o n e x o e s [ 0 ] . i p o r i g e m ) { e n v i a t c p p r o t o c o l p r o c ( data , l e n ) ; } / V e r i f i c a n d o s e a m a quina d e s t i n o e s t a r e c e n d o dados de a p l i c a c ao . / else { i f ( c o n e x o e s [ 0 ] . i p d e s t i n o == i p d s t ) { / A maquina d e s t i n o , acaba de r e c e b e r dados do a r q u i v o . t x t / i f (tcpMSG . ack == 1 && tcpMSG . syn == 0 ) { // O u l t i m o p a c o t e a in da n a o chegou , l o g o os dados s ao a d i c i o n a d o s em uma l i s t a i f (tcpMSG . f i n == 0 ) { tam msg = l e n s i z e o f ( struct T c p p r o t o c o l o ) ; dados = ( char ) m a l l o c ( tam msg s i z e o f ( char ) ) ; // a l o c a n d o e s p a c o para os dados i f ( dados == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } memcpy ( dados , data + s i z e o f ( struct T c p p r o t o c o l o ) , tam msg ) ; // Passando os dados para a l i s t a encadeada x = ( struct dadosRemontagem ) m a l l o c ( s i z e o f ( struct dadosRemontagem ) ) ; completaDados ( x , dados , tam msg , tcpMSG . num sequencia ) ; // I n s e r i n d o na l i s t a insereNaLista (x , primeiro tcp , ultimo tcp , primeiro aux tcp , ultimo aux tcp ) ; f r e e ( dados ) ; // tcpAUX armazena um c a b e c a l h o com dados que confirmam a e n t r e g a do p a c o t e a t u a l c o n f i r m a e n t r e g a ( tcpMSG , tcpAUX ) ; dados = ( char ) m a l l o c ( s i z e o f ( tcpAUX ) s i z e o f ( char ) ) ;

76

i f ( dados == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } // Encapsulando os dados memcpy ( dados , &tcpAUX , s i z e o f ( tcpAUX ) ) ; // Enviando os dados de c o n f i r m a c a o para a maquina destino e n v i a i p p r o t o c o l p r o c ( dados , s i z e o f ( tcpAUX ) , TCP PROTO, c o n e x o e s [ 0 ] . i p d e s t i n o , c o n e x o e s [ 0 ] . ip origem ) ; f r e e ( dados ) ; } / Ultimo p a c o t e r e c e b i d o , f i n == 1 / else { tam msg = l e n s i z e o f ( struct T c p p r o t o c o l o ) ; dados = ( char ) m a l l o c ( tam msg s i z e o f ( char ) ) ; i f ( dados == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } memcpy ( dados , data + s i z e o f ( struct T c p p r o t o c o l o ) , tam msg ) ; x = ( struct dadosRemontagem ) m a l l o c ( s i z e o f ( struct dadosRemontagem ) ) ; completaDados ( x , dados , tam msg , tcpMSG . num sequencia ) ; // I n s e r i n d o na l i s t a insereNaLista (x , primeiro tcp , ultimo tcp , primeiro aux tcp , ultimo aux tcp ) ; f r e e ( dados ) ; // r e t o r n a o tamanho t o t a l dos dados sem o cabe calho tcp tamanhoDados ( tam msg , p r i m e i r o t c p ) ; dados = ( char ) m a l l o c ( tam msg s i z e o f ( char ) ) ; i f ( dados == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } // Faz a c o p i a dos dados que e s t a o na l i s t a e p a s s a para a v a r i a v e l dados copiaDados ( dados , tam msg , p r i m e i r o t c p ) ;

77

removeLista ( primeiro tcp , ultimo tcp ) ; // e n v i a para a camada de a p l i c a c ao r e c b a p p p r o t o c o l p r o c ( dados , tam msg ) ; f r e e ( dados ) ; } } } } } } / Fun c a o r e c b u d p p r o t o c o l p r o c / / Esta f u n ca o r e t i r a o cabe c a l h o UDP e e n v i a o p a c o t e para a camada de aplica c a o . / void r e c b u d p p r o t o c o l p r o c ( char dados udp , s i z e t &l e n ) { struct U d p p r o t o c o l o udpMSG ; char data aux ; s i z e t tam msg ; / Copiando c a b e c a l h o UDP. / memcpy (&udpMSG, dados udp , s i z e o f ( struct U d p p r o t o c o l o ) ) ; tam msg = l e n s i z e o f ( struct U d p p r o t o c o l o ) ; data aux = ( char ) m a l l o c ( tam msg s i z e o f ( char ) ) ; i f ( data aux == NULL) { p r i n t f ( "ERRO" ) ; exit (1) ; } / Desempacotando a msg c o n t i d a na v a r i a v e l dados udp . / memcpy ( data aux , dados udp + s i z e o f ( struct U d p p r o t o c o l o ) , tam msg ) ; // Enviando para a camada de a p l i c a c ao . r e c b a p p p r o t o c o l p r o c ( data aux , tam msg ) ; } / Fun c a o r e c b a p p m s g p r o t o c o l p r o c / / Mostra a mensagem que a m a quina d e s t i n o r e c e b e u . / void r e c b a p p p r o t o c o l p r o c ( char data , s i z e t &l e n ) { p r i n t f ( "\n\n Mensagem recebida CAMADA de APLICACAO " ) ; p r i n t f ( "\n[%s]" , data ) ; p t h r e a d e x i t (NULL) ; }

Refer encias Bibliogr acas


Comer, D. E. (1997). Interliga c ao em Rede com TCP/IP - Volume 2. Editora Campos, 3th edition. Comer, D. E. (2006). Interliga c ao em Rede com TCP/IP. Editora Campos, 5th edition. Forouzan, B. A. (2000). Comunica c ao de dados e redes de computadores. Edit, 5 edition. James F. Kurose, K. W. R. (2006). Redes de Computadores e a Internet. Edit, 3 edition. Postel, J. (1980). User Datagram Protocol. http://www.rfc-editor.org/rfc/rfc768.txt. Siberschatz, A. (2004). Fundamentos de Sistemas Operacionais. Editora Campos, 6th edition. Tanenbaum, A. S. (2003). Redes de Computadores. Editora Elsevier, 4th edition.

78

You might also like