UNIVERSIDADE LUTERANA DO BRASIL

CURSO DE CINCIA DA COMPUTAO

CMPUS GRAVATA
BIBLIOTECA TCP/IP PARA
AMBIENTES
MICROPROCESSADOS
Luiz Guiode Salamon
Monografia desenvolvida durante a disciplina de Trabalho
de Concluso de Curso em Informtica II e apresentada ao
Curso de Cincia da Computao da Universidade
Luterana do Brasil, cmpus Gravata, como pr-requisito
para a obteno do ttulo de Bacharel em Cincia da
Computao.
Orientador: Prof. Elgio Schlemer
Gravata, dezembro de 2002.
2
Universidade Luterana do Brasil ULBRA
Curso de Cincia da Computao Cmpus Gravata
Reitor:
Pastor Ruben Eugen Becker
Vice-Reitor:
Eng. Leandro Eugnio Becker
Diretor do Cmpus Gravata:
Prof. Felcio Korb
Coordenador do Curso de Cincia da Computao (Cmpus Gravata):
Prof. Jos Luiz Andrade Duizith
Coordenador das Disciplinas de Trabalho de Concluso de Curso (Cmpus Gravata):
Prof. Roland Teodorowitsch
Banca Avaliadora composta por: Data da defesa: 5/12/2002.
Prof. Elgio Schlemer (Orientador)
Prof. Roland Teodorowitsch
Prof. Julio Carlos Balzano de Mattos
CIP Catalogao na Publicao
S159b Salamon, Luiz Guiode
Biblioteca TCP/IP para ambientes microprocessados / Luiz Guiode
Salamon; [orientado por] Elgio Schlemer. Gravata: 2002.
68 p.: il.
Trabalho de Concluso de Curso (Graduao em Cincia da
Computao). Universidade Luterana do Brasil, 2002.
1. TCP/IP. 2. Microprocessador. 3. Interface Socket. I. Schlemer,
Elgio. II. Ttulo.
CDU 004.738.5.057.4
Setor de Processamento Tcnico da Biblioteca Martinho Lutero ULBRA-Gravata
Endereo:
Universidade Luterana do Brasil Cmpus Gravata
Estrada Itacolomi, 3.600 Bairro So Vicente
CEP 94170-240 Gravata-RS Brasil
Quem controla as suas palavras sbio, e quem mantm
a calma mostra que inteligente. At um tolo pode passar
por sbio e inteligente se ficar calado.
Provrbios de Salomo
minha esposa Luciane Salamon, que aceitou minha
dedicao aos estudos com resignao.
Aos meus filhos, Francis Salamon e Samuel Salamon, que
so minha inspirao.
Aos meus familiares, que sempre me apoiaram neste meu
objetivo.
SUMRIO
LISTA DE FIGURAS.............................................................................................................7
LISTA DE ABREVIATURAS E SIGLAS............................................................................8
RESUMO ..............................................................................................................................10
ABSTRACT..........................................................................................................................11
1 INTRODUO................................................................................................................12
2 INFRA-ESTRUTURA DE REDE...................................................................................14
2.1 COMO FUNCIONA A TROCA DE DADOS.........................................................................15
2.2 MODELO EM CAMADAS ..............................................................................................15
2.3 INTERLIGAO EM REDE ............................................................................................18
3 A PILHA DE PROTOCOLOS TCP/IP..........................................................................20
3.1 COMUNICAO SEGURA.............................................................................................20
3.2 ESTABELECIMENTO DE CONEXES .............................................................................21
3.3 ESPECIFICAO TCP .................................................................................................23
3.4 MQUINA DE ESTADOS ..............................................................................................24
3.5 PROTOCOLO IP...........................................................................................................25
3.6 FRAGMENTAO........................................................................................................27
3.7 ROTEAMENTO............................................................................................................27
3.8 IP ORIENTADO POR HARDWARE ...................................................................................29
3.9 ESPECIFICAO IP.....................................................................................................29
3.10 MODELO DE OPERAO IP.........................................................................................31
3.11 MENSAGENS DE ERRO (ICMP) ...................................................................................31
3.12 USER DATAGRAM PROTOCOL (UDP) .........................................................................33
4 A INTERFACE SOCKET................................................................................................34
4.1 A CHAMADA SOCKET() ...............................................................................................35
4.2 ASSOCIAO DE PORTAS AO SOCKET ..........................................................................35
4.3 ENVIANDO E RECEBENDO DADOS ...............................................................................36
4.4 CHAMADAS AUXILIARES ............................................................................................37
5 PROJETO PROPOSTO..................................................................................................39
5.1 PROJETO DE SOFTWARE...............................................................................................40
5.2 IMPLEMENTAO DO PROTOCOLO TCP/IP .................................................................41
5.3 FUNES DE GERENCIAMENTO...................................................................................42
5.4 AMBIENTE DE TESTES.................................................................................................43
5.5 ESPECIFICAO DO PROTTIPO..................................................................................44
6
5.5.1 Caractersticas do mdulo selecionado ..............................................................44
5.5.2 Especificaes do microcontrolador ..................................................................45
5.5.3 Interfaces disponveis.........................................................................................45
6 IMPLEMENTAO DO PROJETO ............................................................................47
6.1 AMBIENTE ESCOLHIDO...............................................................................................47
6.2 AMBIENTE DE TESTE ..................................................................................................48
6.3 IMPLEMENTAO DO PROTOCOLO PPP.......................................................................49
6.3.1 Fluxo de negociao PPP...................................................................................50
6.3.2 Otimizao na negociao LCP .........................................................................51
6.3.3 Otimizao na negociao IPCP ........................................................................52
6.3.4 Otimizando a negociao com CCP...................................................................52
6.4 IMPLEMENTAO DO PROTOCOLO IP..........................................................................52
6.4.1 Extraindo dados do datagrama IP.......................................................................54
6.4.2 Tratamento de mensagem UDP..........................................................................55
6.4.3 Tratamento de mensagem TCP..........................................................................55
6.4.3.1 Implementao de temporizadores............................................................56
6.4.3.2 Dando partida mquina de estados TCP.................................................57
6.4.3.3 Estruturas de dados...................................................................................57
6.5 PORTANDO O CDIGO PARA O DESTINO.......................................................................59
6.5.1 Ferramentas utilizadas .......................................................................................61
6.6 VERIFICAO DE FUNCIONAMENTO............................................................................62
6.6.1 Tipos de testes....................................................................................................62
6.6.1.1 Teste de conexo TCP ..............................................................................63
7 CONCLUSO..................................................................................................................65
REFERNCIAS....................................................................................................................67
LISTA DE FIGURAS
Figura 1 Datagramas que trafegam na rede TCP/IP .............................................................14
Figura 2 As sete camadas de referncia do modelo RM-OSI ...............................................16
Figura 3 Dados sendo passados entre as camadas................................................................18
Figura 4 As quatro camadas conceituais da arquitetura de software TCP/IP........................18
Figura 5 Estabelecimento de conexo inicial .......................................................................23
Figura 6 Formato do cabealho TCP....................................................................................24
Figura 7 Mquina de estados TCP (RFC793, p. 23).............................................................26
Figura 8 Classes de redes IP.................................................................................................28
Figura 9 Formato do cabealho IP Verso 4 ........................................................................30
Figura 10 Formato do cabealho do protocolo ICMP ..........................................................32
Figura 11 Formato do cabealho UDP.................................................................................33
Figura 12 A interface socket e os protocolos........................................................................34
Figura 13 Modelo de ciclo de vida incremental ...................................................................41
Figura 14 Estrutura do hardware com suas interfaces .........................................................43
Figura 15 Interao entre camadas.......................................................................................43
Figura 17 Troca de seqncias de caracteres com o MODEM.............................................48
Figura 18 Interconexo entre os sinais RS-232....................................................................49
Figura 19 Formato do protocolo PPP...................................................................................49
Figura 20 Algoritmo de tratamento para quadros.................................................................54
Figura 21 Estrutura de dados do datagrama IP.....................................................................58
Figura 22 Estrutura para manipulao de dados numricos de 2 bytes.................................58
Figura 23 Estrutura para manipulao de dados numricos de 4 bytes.................................58
Figura 24 Estrutura de dados do datagrama TCP.................................................................58
Figura 25 Estrutura auxiliar usada para clculo de soma de verificao TCP......................59
Figura 26 Fluxograma de tratamento de recepo................................................................61
Figura 27 Captura de testes de conexo TCP.......................................................................63
LISTA DE ABREVIATURAS E SIGLAS
ACK ACKnowledgement
ANSI American National Standards Institute
API Applicatio Programming Interface
ARPANET Advanced Research Projects Agency
ATeT American Telephone and Telegraph Corparation
BSD UNIX Berkeley Software Distribution UNIX
CCP Compression Control Protocol
CMOS Complementary Metal Oxide Silicon
DARPA Defence Advanced Research Projects Agency
EEPROM Eletrically Erasable Programmable Read Only Memory
EPROM Erasable Programmable Read Only Memory
FCS Frame Check Sequence
FTP File Transfer Protocol
GPL General Public License
HTTP Hypertext Transfer Protocol
ICMP Internet Control Message Protocol
INTERNIC Internet Network Information Center
ISO Internacional Organization for Standardization
IP Internet Protocol
IPC Interprocess Communication
IPCP Internet Protocol Control Protocol
IPv4 Internet Protocol Verso 4
IPv6 Internet Protocol Verso 6
LAN Local Area Network
LCD Liquid Cristal Display
LCP Link Control Protocol
LSB Last Significant Bit
MODEM MOdulador-DEMOdulador
MRU Maximun Receive Unit
MSB Most Significant Bit
NSF National Science Fundation
OSI Open Systems Interconnection
PAP Password Authentication Protocol
PPP Point to Point Protocol
RAM Random Access Memory
RFC Request For Comments
RM-OSI Reference Model of Open System Interconnection
9
ROM Read Only Memory
SYN SYNcronizing Segment
TCB Transmission Control Block
TCP Transmission Control Protocol
TTL Time To Live
UART Universal Asynchronous Receiver and Transmitter
UCP Unidade Central de Processamento
UDP User Datagram Protocol
VLSI Very Large Scale Integration
WWW World Wide Web
RESUMO
Este trabalho descreve a implementao de uma biblioteca TCP/IP voltada para
sistemas microprocessados de 8 bits, propiciando que arquiteturas mais simples possam
utilizar-se da Internet para as mais diversas finalidades. Assim sistemas de monitorao,
dispositivos de pagamento eletrnicos, controladores de processos industriais, circuitos de
vigilncia residenciais, podem ser conectados Internet e tornar possvel serem monitorados e
controlados partir de qualquer lugar. Buscou-se implementar a biblioteca de forma
otimizada, com vistas a atender exigncias especficas de ambientes com recursos
computacionais limitados. Esta otimizao exigiu estudo criterioso do funcionamento dos
protocolos TCP, IP, UDP e ICMP, bem como seu inter-relacionamento, a fim de manter suas
funcionalidades e, acima de tudo, compatibilidade com a arquitetura presente nos dispositivos
que se utilizam da Internet. Em uma implementao deste tipo deve-se buscar uma integrao
no uso de recursos, principalmente no uso de memria. Ao mesmo tempo, que a otimizao
norteou o desenvolvimento, os recursos de comunicao foram disponibilizados de forma
acessvel e simplificada, para que sua utilizao por aplicaes fosse da forma mais
transparente possvel. Para isto, implementou-se uma interface socket, que permite uma
abstrao para chamadas de comunicao, disponibilizando uma camada otimizada para
acesso aos recursos, alm disto, o estudo permitiu que o objetivo fosse atingido, pois,
estabeleceu a diretriz para o desenvolvimento do prottipo de forma segura e planejada,
permitindo comprovar na prtica a implementao dos recursos, demonstrando seu uso e
funcionamento no ambiente microprocessado escolhido.
Palavras-chaves: TCP/IP; Microprocessador; Interface Socket.
ABSTRACT
Title: TCP/IP library for microprocessed environments
This work describes the implementation of a TCP/IP library directed toward
microprocessed systems of 8 bits, that simpler architectures can be used from the Internet for
the most diverse purposes. Thus electronic systems of monitoring, controlling devices of
payment, industrial processes, monitoring residential circuits, can be connected to the
Internet and can be monitored and controlled from of any place. One searched to implement
the library of optimized form, with sights to take care of specific environment requirements
with limited computational resources. This optimization demanded dedicate study of the
functioning of protocols TCP, IP, UDP and ICMP, as well as its inter-relationship, in order
to keep its functionalities and, above of everything, compatibility with the present architecture
in the devices that if they use of the Internet. In an implementation of this type an integration
in the use of resources must be searched, mainly in the memory use. At the same time, that the
optimization guided the development, the communication resources had been disabled of
accessible and simplified form, so that its use for applications was of the possible form most
transparent. For this, an interface was implemented socket, that it allows an abstraction for
communication calls, making use a layer optimized for access to the resources, moreover, the
study allowed that the objective was reached, therefore, established the line of direction for
the development of the prototype of safe and planned form, allowing to prove in the practical
a implementation of the resources, being demonstrated its use and functioning in the chosen
microprocessed environment.
Key-words: TCP/IP; Microprocessor; Socket Interface.
1 INTRODUO
A Internet demonstrou ser o caminho de interao entre os mais diversos dispositivos
eletrnicos e esta possibilidade exerce grande fascnio sobre as pessoas. Praticamente
qualquer dispositivo que tenha recursos de comunicao est apto a ser conectado grande
rede mundial. A tecnologia atual permite esta integrao com grande facilidade, pois os
sistemas eletrnicos tm a sua disposio memria e capacidade de processamento a baixos
custos.
As possibilidades e aplicaes que esta rea da tecnologia disponibiliza esto longe de
se esgotar. A Internet vem crescendo de forma surpreendente, superando todas as
expectativas, tanto que as classes de endereamento IP (Internet Protocol) esto esgotadas.
Isto demonstra o sucesso que sua utilizao representa. Talvez uma boa razo para este
sucesso seja sua filosofia, onde todas as correntes de pensamento tem oportunidades de
expresso.
O uso da Internet avana em todas as reas tecnolgicas de nossa sociedade e sua
aplicao assume novas propores medida que passa a ser usada rotineiramente. A
demanda por meios que propiciem o acesso Internet movimenta profissionais em todas as
reas, dentre elas os sistemas embarcados e sistemas microprocessados dedicados, onde os
recursos de hardware disponveis normalmente so limitados, o que justifica o
desenvolvimento de tecnologias otimizadas para estas finalidades.
Esta grande demanda movimentou a comunidade da Internet para impedir que seu
crescimento seja prejudicado pelas limitaes impostas pelos protocolos utilizados
atualmente. Esto sendo desenvolvido testes de uma nova verso do protocolo IP, verso 6,
que busca justamente dar maior flexibilidade faixa de endereamento. Neste novo protocolo
o endereo IP passa a ter 128 bits, bem mais do que os 32 bits da verso atual (IPv4).
Dentre as muitas reas que esto aderindo integrao com a Internet, sistemas
industriais uma das mais automatizadas, pela crescente busca de eficincia e reduo de
custos, permitindo que vrios tipos de dispositivos sejam conectados WWW (World Wide
Web). Para isto h grande demanda de sistemas de monitorao que possibilitem o controle
distncia de equipamentos. Sistemas podem, desta forma, identificar falhas e notificar os
sistemas de monitorao sobre tais situaes, o que reduz a necessidade de interveno
humana, muitas vezes em ambientes nocivos.
Este trabalho pretende implementar os protocolos necessrios para que um sistema
microprocessado possa conectar-se Internet e interagir com ela, fornecendo e recebendo
dados. Para isto ser descrito o funcionamento dos protocolos usados na Internet e detalhados
os aspectos dos protocolos que devem ser utilizados. Levando-se em conta que os recursos
disponveis neste tipo de equipamento so escassos, e muitas vezes compartilhados com o
13
sistema que exerce o controle sobre o equipamento, a otimizao, juntamente com a
compatibilidade das funcionalidade implementadas, foi uma das principais metas.
Inicialmente, no captulo 2 sero abordados os conceitos que formam uma infra-
estrutura de rede, descrevendo os modelos que deram origem organizao existente
atualmente. Ser discutido o desenvolvimento de protocolos com viso em camadas,
abordando os exemplos mais relevantes, que servem de referncia para esta rea, pois
possibilitaram que os problemas fossem reduzidos em partes menores e mais fceis de
resolver. A seguir, no captulo 3, sero discutidos os detalhes especficos dos protocolos que
este trabalho se prope a implementar, que so: TCP (Transmission Control Protocol), IP,
UDP (User Datagram Protocol) e ICMP (Internet Control Message Protocol). Todos fazem
parte da pilha de protocolos que compem a Internet. O captulo 4 discorrer sobre o conceito
de socket, utilizado como uma abstrao para criar isolamento entre os recursos de
comunicao fornecidos pelo sistema e as aplicaes que fazem uso destes servios. No
captulo 5 discutido o projeto proposto. Sero vistas as opes de ferramentas de
desenvolvimento que foram utilizadas para a implementao do cdigo do prottipo, as
tcnicas que foram empregadas no desenvolvimento, qual o ambiente de teste necessrios, os
recursos disponibilizados no hardware do prottipo escolhido e suas interfaces. O captulo 6
descreve a implementao do projeto abordando como ele foi realizado. Descreve os
problemas enfrentados e as solues encontradas, os teste que foram realizados, utilizando-se
do hardware escolhido como prottipo deste projeto, bem como os resultados obtidos. Por
fim, no captulo 7, ser apresentada a concluso do trabalho.
2 INFRA-ESTRUTURA DE REDE
O principal objetivo de uma rede o compartilhamento de recursos, sejam eles dados,
aplicativos, dispositivos de armazenamento, impressoras, etc. A possibilidade de troca de
informaes sobre diversos assuntos com computadores em rede local ou geograficamente
distribudos encurta distncias e virtualmente aproxima as pessoas. As diversas ferramentas
que fazem uso destes recursos, como correio eletrnico, listas de discusso e navegadores de
pginas na Internet so exemplos atravs dos quais as pessoas interagem, utilizando-se dos
computadores interligados a redes (JORDAM e CHURCHILL, 1994, p. 16).
Um ambiente de rede consiste de estaes interconectadas que normalmente so
atendidas por um servidor. Esta viso pode ser aplicada a uma rede local com
microcomputadores interligados atravs de uma placa de rede Ethernet ou grandes redes
(ARPANET, Internet).
H vrios nveis de protocolos trafegando na rede na forma de pacotes, tambm
chamados de datagramas, dependendo do nvel em que eles esto. A Figura 1 mostra um
exemplo de pacote TCP contido em um datagrama IP. O termo pacote usado genericamente
para designar uma poro de dados que trafegam entre as estaes. O formato dos pacotes que
esto nesta rede definido por vrios protocolos, responsveis pelo transporte dos dados entre
as estaes (computadores conectados rede que so fonte e destino de pacotes de dados).
Pacote TCP Dados da Aplicao
Datagrama IP Dados do datagrama
Figura 1 Datagramas que trafegam na rede TCP/IP
Alm das estaes, existem outros equipamentos, que fazem parte da rede. Estes
equipamentos normalmente do suporte rede, tais como:
gateway: um dos vrios tipos de servidores de comunicao, sua funo
permitir que duas ou mais redes diferentes se comuniquem como se fossem uma
nica entidade lgica;
roteadores: so dispositivos que controlam o trnsito de pacotes entre redes
separadas logicamente;
15
pontes (bridges): as pontes conectam duas redes separadas fisicamente;
repetidores: os repetidores so utilizados para estender a extenso fsica de uma
LAN (Local Area Network).
2.1 COMO FUNCIONA A TROCA DE DADOS
Independentemente do tipo de conexo que faam, seja entre computadores ou entre
terminais e computadores, as redes de comunicao dividem-se em dois tipos bsicos:
comutao de circuitos (tambm conhecidas como redes baseadas em conexes);
comutao de pacotes (conhecidas, ainda, como redes sem conexo).
A comutao por circuitos opera formando uma conexo dedicada entre duas pontas.
J nas redes de comutao de pacotes, as mensagens a serem transmitidas atravs das estaes
da rede so divididas em pequenas unidades chamadas pacotes, que so multiplexados por
meio de conexes entre mquinas de alto desempenho. Um pacote, que geralmente contm
pequenas unidades de informaes, transporta uma identificao que capacita o hardware da
rede a enviar as informaes ao destino. Por exemplo, a transmisso de um arquivo extenso
entre dois equipamentos deve ser feita a partir da diviso do arquivo em vrios pacotes antes
de encaminh-los rede. O hardware da rede envia os pacotes aos seus respectivos destinos
onde o software os rene novamente em um nico arquivo.
De acordo com Nunes (1999), a grande vantagem da comutao de pacotes a
possibilidade de realizar simultaneamente vrias conexes entre computadores distintos. A
desvantagem que medida que a atividade se intensifica, h um decrscimo do desempenho
da rede.
As estaes conectadas Internet, quando querem transmitir dados, fazem chamadas
ao TCP passando buffers com dados. O TCP cria os pacotes com os tamanhos adequados de
segmentos, agregando informaes de controle. Aps, chamado o mdulo responsvel por
enviar os pacotes pela rede.
O destino, ao receber os pacotes em segmentos, coloca os dados no buffer do usurio e
notifica a recepo dos dados.
Os dados recebidos contm informaes que garantem que os pacotes possam ser
corretamente ordenados, visto que podem chegar fora de ordem no destino.
2.2 MODELO EM CAMADAS
A diviso dos mdulos de protocolo em camadas surgiu com o objetivo de isolar o
tratamento da comunicao das aplicaes, e ao mesmo tempo isolar os vrios nveis de
problemas que este tipo de ambiente apresenta, como pode ser visto em Comer e Stevens
(1999a, p. 177).
A viso em camadas permite que problemas apresentados em nveis diferentes sejam
tratados por mdulos especficos, com maior eficincia, pois cada mdulo desenvolvido
para resolver da melhor forma o tratamento de sua camada. Assim os problemas no so
propagados aos mdulos seguintes. Dividindo o tratamento em unidades menores fica mais
fcil de implementar solues que sejam mais eficientes.
16
Uma das primeiras vises desta implementao foi o modelo RM-OSI (Reference
Model of Open System Interconnection), feito pela ISO (Internacional Organization for
Standardization).
Este modelo foi concebido nas sete camadas apresentadas na Figura 2.
Camada Funcionalidade
7 Aplicativo
6 Apresentao
5 Sesso
4 Transporte
3 Rede
2 Enlaces de Dados
1 Conexo Fsica
Figura 2 As sete camadas de referncia do modelo RM-OSI
O propsito do modelo fornecer uma base comum para o desenvolvimento
coordenado de padres para a interconexo de sistemas. O modelo no trata questes de
implementao.
Conceitualmente o modelo OSI (Open Systems Interconnection) no define uma
arquitetura, j que no especifica os servios e protocolos de cada camada, apenas indica o
que cada uma deve fazer (NUNES, 1999).
Desta forma dois sistemas obedecendo o modelo OSI podem no interagir, por
oferecer protocolos e servios incompatveis nas suas camadas.
Outro aspecto relevante do modelo OSI que o mesmo foi concebido para redes
homogneas e distribudas.
A definio das camadas do modelo OSI especifica o seguinte:
Nvel Fsico (1): Permite o envio de cadeias de bits pela rede sem se preocupar
com o significado dos bits ou com o modo como so agrupados. Especifica um
padro para interconexo fsica entre estaes e comutadores de pacotes de rede, e
tambm os procedimentos usados para transferir pacotes de uma mquina para
outra. No modelo de referncia, o nvel 1 especifica a interconexo fsica,
incluindo as caractersticas eltricas de voltagem e corrente.
Nvel de Enlace de Dados (2): Neste nvel a unidade de dados chama-se quadro.
Este nvel detecta e opcionalmente corrige erros no nvel fsico. Particiona a
cadeia de bits em quadros de forma a incluir dados que possam garantir deteco
de erros. Tambm responsvel por evitar que o transmissor envie mais dados ao
receptor do que este possa receber. Para isso usa mtodos de controle de fluxo. O
protocolo deste nvel responsvel por definir o formato dos quadros e especificar
como as duas mquinas reconhecem os limites deste.
Nvel de Rede (3): Fornece ao nvel de rede uma independncia quanto a questes
de chaveamento e roteamento associado com a conexo da rede. Duas filosofias
de servios so oferecidas: servio de datagrama (no orientado a conexo), onde
cada pacote carrega por completo o endereo do destino e servio de circuito
virtual (orientado a conexo), onde o transmissor inicialmente envia pacotes para
17
estabelecer a conexo. Ao circuito dado um nmero que representa a conexo,
que usada pelos outros pacotes. O software presente neste nvel deve reunir os
pacotes na forma que a rede espera e usa o nvel de Enlace de Dados para
transferi-los at os comutadores de pacotes.
Nvel de Transporte (4): Tem como funo fornecer os seguintes servios:
- comunicao fim-a-fim (origem e destino) confivel, uma vez que o nvel de
rede no garante a entrega dos pacotes, nem sua ordem;
- otimizao de conexes de rede utilizando multiplexao (vrias conexes de
transporte partilhando a mesma conexo de rede) ou splitting (uma conexo
de transporte ligada a vrias conexes de rede);
- controle de fluxo;
- controle fim-a-fim;
- deteco e recuperao de erros;
- segmentao de mensagens.
Apesar das camadas inferiores de protocolos fornecerem verificao confivel de
cada transferncia, a camada fim-a-fim faz outra verificao para se certificar de
que nenhuma mquina no meio falhou.
Nvel de Sesso (5): Fornece servios para estruturar os circuitos oferecidos pelo
nvel de transporte. Os servios deste nvel so:
- gerenciamento de tokens: controlam a posse e a passagem do token entre
entidades de aplicao que esto utilizando o servio;
- controle de dilogo: permitem retomar um dilogo interrompido por falha de
rede;
- gerenciamento de atividades: partes do intercmbio de dados.
Nvel de Apresentao (6): Fornece servios para aplicativos, tais como:
- transformao de dados, com criptografia e compresso de textos;
- formatao de dados tais como converso de padres entre redes;
- seleo de sintaxe adequada entre entidades;
- conexo de apresentao.
Nvel de Aplicao (7): Fornece funes de gerenciamento e mecanismos
genricos de suporte construo de aplicaes distribudas.
Cada camada comunica-se com sua semelhante em outro computador. Quando a
informao passada de uma camada para outra inferior, um cabealho adicionado aos
dados para indicar de onde a informao vem e para onde vai. A Figura 3 exemplifica como
os dados so passados de uma camada para a seguinte, onde os blocos de cabealho e dados
de uma camada so os dados da prxima camada.
18
Estao A Estao B
Aplicativo Mensagem Aplicativo
Transporte Cabealho Dados Transporte
Interligao
de rede
Cabealho Dados
Interligao
de rede
Interface
de redes
Cabealho Dados
Interface
de redes
Pacote idntico
Datagrama idntico
Rede Fsica
Quadro idntico
Figura 3 Dados sendo passados entre as camadas
2.3 INTERLIGAO EM REDE
O desenvolvimento da arquitetura RM-OSI foi patrocinada pelo DARPA (Defence
Advanced Research Projects Agency) (COMER e STEVENS, 1999a, p. 41). Esta arquitetura
baseia-se em um servio de transporte orientado conexo, determinado pelo protocolo TCP
e um servio de rede no orientado conexo, datagrama no confivel, determinado pelo
UDP, usando o IP para transportar mensagens entre mquinas. A arquitetura Internet d
nfase interconexo de redes com diferentes tecnologias.
Este modelo foi concebido em quatro camadas, tal como o modelo apresentado na
Figura 4.
Camada Conceitual Objetos Passados entre Camadas
4 Aplicao Mensagens ou Fluxos
3 Transporte Pacotes de Protocolos de Transporte
2 Interrede Datagramas IP
1 Interface de Redes Quadros de Redes Especficos
Hardware
Figura 4 As quatro camadas conceituais da arquitetura de software TCP/IP
19
A descrio de cada camada a seguinte:
Nvel Interface de Redes (1): Compatibiliza a tecnologia especfica de cada rede
ao protocolo IP. Recebe os datagramas IP do nvel interrede e os transmite atravs
da rede especfica.
Nvel Interrede ou Camada Internet (2): Responsvel pela transferncia de dados
pela interrede, da mquina origem ao destino. Recebe do nvel de transporte os
pedidos de transmisso de pacotes j com o endereo de onde devem ser
entregues. O pacote encapsulado em um datagrama IP e o algoritmo de
roteamento executado. Este nvel tambm processa pacotes recebidos das
interfaces de rede. Esta camada responsvel por enviar mensagens de controle e
de erro ICMP e tratar as mensagens ICMP que chegam.
Nvel de Transporte (3): Permite a comunicao fim-a-fim entre as aplicaes. O
protocolo TCP possui servios de: controle de erro, controle de fluxo,
seqenciamento e multiplexao de acesso ao nvel interrede. O protocolo UDP
tem apenas multiplexao e demultiplexao do acesso ao nvel interrede.
Nvel de Aplicativo (4): Usurios utilizam programas de aplicao para acessar
servios disponveis na interrede. Aplicaes interagem com o nvel de transporte
para enviar e receber dados. As aplicaes podem utilizar o servio de transporte
orientado a conexo, ou no orientado a conexo.
A arquitetura de interligao em rede com nveis de abstrao, onde cada nvel executa
uma dada tarefa, possibilitou que a tecnologia de cada nvel fosse sendo aprimorada, sem que
houvesse interferncia nos demais nveis.
Segundo Comer e Stevens (1999a, p. 100), o grande sucesso desta organizao
hierrquica ocorreu porque esta arquitetura surpreendentemente eficiente e adaptvel.
Apesar da diviso em camadas ser extremamente til, servindo como base para a
implementao do projeto de protocolo, seu uso de forma rgida pode resultar em algoritmos
extremamente ineficientes. Desta forma o isolamento total entre as camadas no deve ser
levado ao extremo, mas para que se tenha uma relao custo-benefcio aceitvel, a
implementao deve permitir que haja difuso de dados entre camadas adjacentes.
Existem algumas diferenas entre os modelos RM-OSI e TCP/IP, alm da
simplificao no nvel de camadas proposto pela arquitetura Internet. Uma delas a tcnica
para garantir segurana na transferncia de dados. O modelo OSI trata erros em vrios nveis
enquanto o TCP/IP adota um esquema menos rgido, onde pacotes podem ser perdidos ou
descartados e mesmo assim o protocolo garante a comunicao eficiente fim-a-fim. Salienta-
se tambm que o modelo OSI, criado para descrever protocolos para uma nica rede, no
contm um nvel especfico de roteamento de interligao em redes igual ao dos protocolos
TCP/IP.
3 A PILHA DE PROTOCOLOS TCP/IP
As referncias que so normalmente encontradas sobre implementao de protocolos
para a Internet abordam arquiteturas que suportam ambientes multitarefas. Assim boa parte do
material de referncia est voltada para sistemas com grande capacidade de processamento.
A documentao base para qualquer implementao que vise manter o padro definido
para o protocolo TCP/IP so os documentos chamados RFCs (Requests for Comments), que
abordam detalhadamente sua implementao. Este material est disponvel para ser
consultado livremente por qualquer pessoa ou entidade. Os RFCs podem ser obtidos em
http://www.rfc.net.
A tecnologia TCP/IP no pertence a nenhum fornecedor e a nenhuma sociedade
profissional ou instituies responsveis pelos padres. Uma entidade chamada National
Science Fundation (NSF) financia um grupo da ATeT para manter e distribuir informaes
sobre TCP/IP e Internet global. Este grupo conhecido como Internet Network Information
Center (INTERNIC), que trata de muitos detalhes administrativos para a Internet, alm de
distribuir a documentao.
A leitura desta documentao essencial para o correto entendimento dos padres de
protocolos que esto em operao, pois estes fornecem todas as informaes que so
utilizadas por quem deseja desenvolver protocolos compatveis com os padres da Internet.
A base deste estudo foi a leitura das RFCs 768, 791, 792, 793 e 1180, as quais
descrevem os protocolos que sero implementados e sua fundamentao. A leitura destes
documentos fornece esclarecimento para que os modelos possam ser entendidos e assim
orientar sua implementao, no caso, para o ambiente especfico ao qual o projeto se destina,
ou seja, um sistema microprocessado com poucos recursos em funo de sua caractersticas
de hardware.
O trabalho de Dunkels (2001) uma obra de referncia nesta rea. Este trabalho traz a
implementao de um servidor TCP/IP voltado para o processador 6502, e implementa o
protocolo de forma a proporcionar bibliotecas para acesso aos servios de comunicao,
criando com isso uma abstrao que separa a aplicao da implementao do protocolo. Esta
abstrao criada usando-se o conceito conhecido como Socket (COMER e STEVENS,
1999a, p. 371) e desenvolvido inicialmente no sistema operacional BSD UNIX.
3.1 COMUNICAO SEGURA
O protocolo TCP foi concebido para garantir uma comunicao segura entre duas
estaes. Para isto a transmisso feita com o uso de numerao de seqncia nos pacotes
21
que so enviados, e com o uso de ACK (ACKnowledgement) para confirmar que os dados
foram recebidos corretamente pela interface de rede responsvel pelo encaminhamento do
pacote, a qual tambm pode ser o destino final, caso se trate de uma rede local onde os
pacotes no tenham de ser roteados (RFC1180).
Quando h a transmisso de dados em um pacote TCP, este colocado em uma fila de
retransmisso e um temporizador (timer) associado ao pacote inicializado. Ao receber um
ACK o segmento apagado da fila de retransmisso. Se o ACK no for recebido antes do
trmino da contagem do temporizador, o segmento retransmitido.
O recebimento de um ACK no garante que os dados chegaram ao destino. Quem
deve garantir que os dados sejam corretamente recebidos a estao remota, a qual tem a
responsabilidade de informar de que pacotes necessita para continuar montando a mensagem.
Para garantir o fluxo de dados entre duas conexes TCP, um mecanismo de controle
de fluxo empregado. A estao destino informa sua janela de dados para a estao de
origem. Esta janela informa o nmero de octetos (bytes), iniciando com o cdigo de ACK
(confirmao), assim a estao receptora estar preparada para a recepo de dados.
Segundo Comer e Stevens (1999a, p. 212), a interface entre programas aplicativos e o
servio TCP/IP de transmisso confivel pode ser representada por cinco caractersticas:
Orientao do stream (fluxo de dados): O servio de transmisso de streams da
mquina de destino passa para o receptor exatamente a mesma seqncia de
octetos que o transmissor passa para ele na mquina de origem.
Conexo de circuito virtual: Uma conexo vista por programas aplicativos como
um circuito de hardware dedicado, onde a confiabilidade proporcionada pelo
servio de transmisso de fluxo de dados. Esta abstrao proporcionada aos
aplicativos de forma transparente, mas para isto h uma srie de interaes entre
transmissor e receptor.
Transmisso bufferizada: O protocolo livre para manipular o tamanho dos
pacotes de forma mais adequada, a fim de proporcionar o uso adequado do meio
de transmisso, armazenando dados para reuni-los em blocos maiores ou
particionando-os para que sejam transmitidos dentro de blocos menores. Ao final
de recepo, o protocolo entrega os dados exatamente na mesma ordem em que
foram enviados.
Stream desestruturado: O servio de stream TCP/IP no reconhece os dados que
manipula. Estes so tratados como uma seqncia de bits.
Conexo full duplex: As conexes fornecidas pelo servio de stream TCP/IP
permitem transferncia em ambas as direes.
Estas so as caractersticas que o protocolo disponibiliza na forma de propriedades ou
caractersticas de sua implementao. Cabe observar que o conjunto de protocolos que torna
possvel a existncia destas caractersticas. Isoladamente cada protocolo implementa aes
que fazem que o conjunto seja responsvel pelo desempenho observado em cada nvel.
3.2 ESTABELECIMENTO DE CONEXES
O protocolo TCP foi concebido para ser executado em ambiente multitarefa, onde
mltiplas conexes podem estar em andamento simultaneamente. Para que isto possa ocorrer
foi criado o conceito de porta de conexo. Este identificador utilizado para isolar conexes
em uma estao e associar estas a determinados tipos de servios. Assim os processos que
22
utilizam o TCP associam suas conexes a portas. Exemplos de portas atribudas servios
so:
7: Eco. Utilizada normalmente para verificar se um determinado servidor
encontra-se ativo;
20: FTP (File Transfer Protocol);
23: TELNET;
80: HTTP (Hypertext Transfer Protocol).
Atravs da mquina de estados apresentada na seo 3.4 possvel descrever os passos
necessrios para que processos possam se utilizar do TCP, estes devem solicitar uma conexo
via uma porta, para isto implementada a chamada ao estado OPEN, para a qual so passados
a porta e os dados da conexo remota. Quando uma conexo estabelecida, o processo recebe
um identificador que dever ser utilizado nas chamadas subseqentes.
As informaes desta conexo so armazenadas em uma estrutura chamada TCB
(Transmission Control Block). Uma conexo pode ser realizada por iniciativa local ou remota.
O processo de conexo iniciado pela estao que deseja enviar ou receber dados.
Para isto ela toma a iniciativa de conexo, enviando pacotes necessrios para estabelecer uma
conexo TCP. Este processo assume que o computador remoto, ao qual se est solicitando a
conexo, est em estado de escuta (LISTEN, Figura 7), onde ele estar aguardando chegadas
de conexes. Para que seja aceita uma conexo endereada a qualquer porta, o estado
LISTEN deve ser aberto com a porta 0 (zero). De outra forma, somente para a porta
especificada que sero aceitas conexes.
Para que haja o estabelecimento de uma conexo, necessrio que as duas estaes
troquem dados iniciais, envolvendo a troca de trs mensagens utilizando-se do flag de
sincronismo SYN (FLAGS, Figura 6). Uma conexo iniciada com a retribuio de um
segmento contendo SYN e a criao do TCB correspondente. Uma conexo dita
estabelecida quando as portas local e remota so as mesmas e h troca de seqncia de
sincronismo.
Para que uma conexo possa ser desfeita, deve existir troca de segmentos que
contenham o flag FIN, desta forma os processos sero notificados desta situao.
O protocolo TCP especifica o procedimento para estabelecimento de uma conexo
entre duas estaes conectadas Internet. Este procedimento conhecido como three-way
handshake, sendo mostrado na Figura 5 e descrito na RFC793. A especificao das regras de
operao para este procedimento de conexo, fazem com que este mtodo reduza a
possibilidade de haver falsas conexes, mas a principal razo para sua utilizao prevenir
duplicao de conexes j existentes, o que causaria uma srie de confuses. Isto
assegurado utilizando-se mensagens de controle e reinicializaes de forma planejada.
Partindo-se do estado CLOSED, a estao que deseja estabelecer uma conexo, inicia
enviando um segmento com o flag SYN. A estao receptora devolve outro segmento com os
flags SYN e ACK, indicando que recebeu a requisio e aceitou o pedido. Neste momento a
estao que iniciou a conexo passa para o estado ESTABLISHED, e envia uma confirmao
para a estao remota com o flag ACK ligado, assim esta recebe a confirmao que necessita
para passar para o estado ESTABLISHED.
O controle de fluxo faz parte da especificao do protocolo TCP, este estabelece
regras para que a troca de dados entre as estaes esteja adaptada s caractersticas de cada
23
estao. Isto realizado por meio de negociao do controle de fluxo, visando adequar o
tamanho da janela de dados capacidade das estaes.
Envia SYN
Recebe SYN
Envia SYN + ACK
Recebe SYN+ACK
Envia ACK
Recebe ACK
TCP A TCP B
Figura 5 Estabelecimento de conexo inicial
O envio de dados deve ser feito atravs de uma chamada funo SEND, que cria um
isolamento dos detalhes do protocolo para a aplicao, utilizando os conceitos de abstrao
socket. Para cada poro de dados uma nova chamada deve ser feita. O protocolo permite
tratamento de dados urgentes, fazendo com que os dados sejam entregues imediatamente ao
destino, para isto existe um flag chamado PSH (FLAGS, Figura 6), que pode ser definido. O
destino ao perceber o flag PSH disponibiliza os dados contidos em seu buffer imediatamente
para a aplicao, descartando tratamento de temporizao ou verificao de seqncia de
pacotes.
O envio de dados pelo TCP permite que os dados sejam quebrados em blocos
adequados conexo vigente, ou mesmo conter dados de mltiplas chamadas funo SEND.
3.3 ESPECIFICAO TCP
Os segmentos TCP so enviados em blocos chamados pacotes. Junto aos dados
includo um cabealho (header) que contm informaes especficas do protocolo, que
descrito em RFC793 e RFC1180. O formato do cabealho mostrado na Figura 6. Este
cabealho tem os seguintes campos:
source port (16 bits): nmero da porta origem, que identifica o processo que
enviou os dados;
destination port (16 bits): nmero da porta destino, que identifica o processo
remoto que deve tratar os dados enviados;
sequence number (32 bits): o nmero do primeiro octeto (byte) dentro do
segmento (exceto se o flag SYN estiver presente). Se o flag SYN estiver presente
este representa o primeiro nmero de seqncia (ISN);
acknowledgment number (32 bits): se o flag ACK estiver definido este campo ter
o valor do prximo nmero de seqncia esperado;
data offset (4 bits): o nmero de palavras (32 bits) que compem o cabealho
TCP;
reserved (6 bits): reservado para uso futuro, deve ser zero;
flags (6 bits):
24
- URG: especifica dados urgentes;
- ACK: ACKNOWLEDMENT (mensagem de confirmao);
- PSH: funo Push;
- RST: encerra a conexo;
- SYN: sincroniza o nmero de seqncia;
- FIN: indica que no h mais dados;
window (16 bits): tamanho da janela de dados que o protocolo TCP espera
receber;
checksum (16 bits): soma de verificao dos dados;
urgent pointer (16 bits): ponteiro para os dados urgentes, usado somente quando o
flag URG estiver definido, indica o final da rea dos dados urgentes;
options (24 bits): este campo no requerido para a maioria dos datagramas,
utilizado para testes e depurao;
padding (8 bits): este campo varivel, utilizado para preenchimento, de forma
que a barreira limite de trmino do cabealho acabe em mltiplos de 16 bits.
32 bits
Source port Destination port
Sequence number
Acknowledgment number
Data offset Reserved Flags Window
Checksum Urgent pointer
Options (+ padding)
Data (variable)
Figura 6 Formato do cabealho TCP
3.4 MQUINA DE ESTADOS
possvel representar o funcionamento do protocolo TCP como uma mquina de
estados (Figura 7), como descrito na especificao do protocolo (RFC 793) e comentada por
Comer e Stevens (1999a, p. 242; 1999b, p. 185).
Esta mquina de estados no representa totalmente todas as interaes, somente o
estado macroscpico, pois cada estado pode conter mais de um tratamento para os eventos.
H muitas situaes que so controladas em funo de contadores e relgios. Por exemplo,
para garantir que os dados cheguem ao destino, utilizando ao mximo a banda disponvel, so
implementados algoritmos que fazem avaliao constante de erros e time-outs.
A flexibilidade e adaptabilidade do protocolo TCP, que o tornou o protocolo padro da
Internet amparado em muitos de seus detalhes de operao, que no so mostrados ou
representados em suas mquinas de estados. No trabalho de Dunkels (2001), h uma nova
25
abordagem para a mquina de estados implementada. Esta nova abordagem procura otimizar
os estados que no so crticos, dentro da implementao proposta.
O estabelecimento de uma conexo pode ser exemplificado atravs do funcionamento
da mquina de estados. So percorridos os passos necessrios para o estabelecimento de uma
conexo, assumindo que tanto o cliente como o servidor tem a mesma mquina de estados
com base no esquema mostrado na Figura 7. Seu modo de operao tem a seqncia descrita
abaixo:
o servidor entra em modo de LISTEN (open passivo) e espera at que um cliente
faa uma conexo;
quando uma estao cliente emite um open ativo, ele faz com que o software TCP
envie um segmento SYN ao servidor e entra no estado SYN-SENT;
o servidor ao receber SYN, responde com um segmento SYN e um ACK, cria um
TCB e passa para o estado SYN-RECEIVED;
quando o segmento SYN e ACK chega ao cliente, este responde com um ACK e
passa do estado SYN-SENT para o estado ESTABLISHED;
finalmente, quando o ACK do cliente chega ao servidor, este passa para o estado
ESTABLISHED.
O TCP utiliza uma tcnica simples para garantir a entrega de dados: a confirmao
positiva com retransmisso (piggyback).
A cada pacote recebido o receptor informa ao transmissor (ACK) qual o prximo byte
do fluxo remoto que ele espera receber. Esta informao colocada no cabealho TCP, no
campo acknowledgment number. Outra informao importante que o protocolo trata o
campo sequence number, o qual informa qual o nmero do primeiro byte do fluxo que est
sendo enviado. Estas informaes representam a numerao seqencial dos bytes da rea de
dados que esto fluindo entre receptor e transmissor. A implementao destas informaes
utilizada pelo protocolo para garantir que os dados cheguem ao destino, permitindo que o
protocolo fornea o servio para qual ele foi projetado, que a garantia de entrega dos dados.
Uma implementao que pretenda ser otimizada por restries impostas pelo ambiente
onde ser utilizado, dever manter o tratamento para estes campos, pois so fundamentais
para o funcionamento adequado do protocolo.
3.5 PROTOCOLO IP
Conforme Comer e Stevens (1999a, p. 122), o objetivo do protocolo IP fornecer uma
rede virtual com vrias redes fsicas que oferea um servio de entrega de datagramas sem
conexo. Este nvel no se preocupa com a integridade dos dados.
O protocolo IP implementa o conceito da entrega de pacotes sem conexo. Esta
denominao especifica que cada pacote independente dos demais. Um certo nmero de
pacotes enviados podem trafegar por vrios percursos diferentes, serem perdidos, danificados,
ou mesmo chegar ao destino fora de ordem.
Os aspectos mais relevantes que o protocolo implementa so: fragmentao de
pacotes, adequando o tamanho dos fragmentos capacidade da rede, roteamento, ou seja, a
escolha de um caminho por onde os pacotes sero enviados. Alm disso o protocolo
especifica as regras de como os dados devem ser tratados por roteadores e estaes durante
sua permanncia na rede.
26
incio
algo / reset
CLOSED
close
open
passivo
open ativo / syn
LISTEN
send / syn
reset
syn / syn + ack
syn / syn + ack
SYN
SENT
close /
timeout /
reset
SYN
RECVD
ack
ESTAB-
LISHED
syn + ack / syn
CLOSE
WAIT
fin / ack
close / fin
CLOSING
LAST
ACK
ack / fin / ack
close / fin
close / fin
FIN
WAIT-1
FIN
WAIT-2
ack /
TIME
WAIT
ack /
timeout aps 2
milisegundos
ack /
Figura 7 Mquina de estados TCP (RFC793, p. 23)
27
Os servios que o protocolo IP fornece so atendidos por quatro caractersticas
implementadas em seu cabealho, so eles: Tipo de Servio, Tempo de Vida de um Pacote,
campo de Opes e dado de Soma de Verificao de integridade de cabealho.
A qualidade do servio de entrega desejado especificada no campo Tipo de Servio.
Este campo pode especificar o uso de servios desejados para o pacote e usados por entidades
da rede para tomada de decises de roteamento. O Tempo de Vida de um Pacote especifica o
quanto um pacote deve permanecer na rede at que ele seja descartado, antes de chegar ao
destino. Sua utilidade pode ser percebida pelo fato de que pacotes no entregues poderiam
ficar trafegando na rede indefinidamente, causando trafego desnecessrio. O campo de
Opes prov meios de controle para situaes no muito comuns e que normalmente no so
utilizadas para a maioria das comunicaes. H tratamento para segurana, roteamento e
relgios. A integridade do cabealho assegurada pelo campo Soma de Verificao, que pode
ser conferido para validao. Os dados enviados junto ao cabealho podem conter erros, mas
no h qualquer indicao para sua verificao. Em caso de um cabealho estar corrompido, o
pacote automaticamente descartado.
Este modelo de operao pressupe que os integrantes da rede tenham mdulos IP
idnticos residentes em cada unidade que faz parte desta rede. Desta forma podem
compartilhar das caractersticas que o protocolo implementa.
3.6 FRAGMENTAO
A protocolo IP usa campos de seu cabealho para tratar a fragmentao e remontagem
de pacotes. A fragmentao utilizada para adequar redes onde os fluxo de dados so de
diferentes capacidades. Esta caracterstica de adequao amparada por outra muito
importante: cada pacote tratado como uma unidade independente, no relacionado com
nenhum outro pacote.
A fragmentao ocorre independentemente de qualquer ao por parte da origem. Esta
pode enviar pacotes do tamanho que julgar necessrio, mas o uso de tamanho de pacotes
adequado ao tamanho utilizado na rede permite maior eficincia, pois reduz a necessidade de
fragmentao. O desempenho tende a ser seriamente afetado em redes onde h necessidade de
fragmentao, pois, em caso de perda de algum pacote fragmentado necessrio para
remontagem no destino, todos os demais pacotes sero descartados.
Por definio qualquer destino deve estar apto a receber um datagrama enviado com
tamanho de 68 bytes, sem necessidade de fragmentao. Isto ocorre porque um cabealho IP
mnimo tem 60 bytes e uma rea de dados mnima tem o tamanho de 8 bytes.
Em caso de datagramas que no devem ser fragmentados h o uso de um bit
sinalizador (DF- Dont Fragment). Este bit informa que determinado datagrama no deve ser
fragmentado para ser entregue ao seu destino. Em caso de recebimento de um datagrama com
este bit ligado, a origem ir descart-lo automaticamente, se no houver recursos suficientes
para realizar a remontagem do datagrama.
3.7 ROTEAMENTO
Um dos objetivos do protocolo IP fornecer uma rede virtual que abranja vrias redes
fsicas oferecendo servio de entrega de datagramas sem conexo aos protocolos de nvel
superior. Para isto o protocolo IP escolhe qual o melhor caminho a ser dado para um
28
datagrama em funo de seu destino, dentre as vrias redes fsicas que esto disponveis. Esta
deciso leva em considerao carga da rede, comprimento do datagrama e tipo de servio
solicitado no cabealho do datagrama. De acordo com Comer e Stevens (1999a, p. 122), a
maioria dos programas de roteamento da interligao em rede no so to sofisticados na
tomada de decises, estes selecionam rotas baseados em pressupostos fixos sobre caminhos
mais curtos.
O protocolo IP participa em conjunto com roteadores na tomada de decises de
roteamento de datagramas.
possvel classificar o roteamento em dois tipos: encaminhamento direto e
encaminhamento indireto. O encaminhamento direto a transmisso de um datagrama, por
meio de uma nica rede fsica entre duas mquinas. J o encaminhamento indireto se d
quando o destino no se encontra na mesma rede fsica, exigindo que o datagrama seja
passado para um roteador, conectado rede, que far a entrega.
Quando o IP recebe um datagrama, este deve mapear o endereo IP do destino para
um endereo fsico e entreg-lo ao hardware de rede. Para duas mquinas interligadas em
uma mesma rede fsica no h envolvimento de roteadores. O transmissor sabe que o destino
encontra-se em uma rede diretamente conectada.
O algoritmo de roteamento IP emprega o uso de tabela de roteamento. Esta tabela
armazena informaes sobre endereos de destinos e como acess-los. Seu contedo
dinmico e vai mudando conforme o trfego de entrega bem sucedido. A idia armazenar
o mximo de informaes que possam auxiliar na deciso de roteamento, mas deve ser
avaliado o tamanho e a facilidade de manipulao dos dados armazenados.
Endereos IP so formados por nmeros de 4 bytes (32 bits no total) e so
manipulados de forma a permitir uma diviso em classes com capacidades para comportar
diferentes tamanhos de redes. Sua construo foi dirigida visando tornar sua manipulao o
mais eficiente possvel, com vistas a garantir altas taxas de desempenho por parte de
roteadores. A definio do formato atribudo ao endereo de rede IP mostrado na Figura 8.
H uma parte designada para representar um segmento de rede e outra para representar uma
estao dentro desta rede.
H essencialmente trs classes principais. Endereos do tipo A so usados para redes
com muitas estaes, o tipo B para redes com tamanho mdio e o tipo C para redes pequenas
mas com grande distribuio geogrfica.
Classe Endereos Representao binria
A 1-126.E.E.E 0nnnnnnn.bbbbbbbb.bbbbbbbb.bbbbbbbb
B 128-191.E.E.E 10nnnnnn.nnnnnnnn.bbbbbbbb.bbbbbbbb
C 192-223.E.E.E 110nnnnn.nnnnnnnn.nnnnnnnn.bbbbbbbb
D 224-239.E.E.E 1110xxxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
E 240-247.E.E.E 11110xxx.xxxxxxxx.xxxxxxxx.xxxxxxxx
Figura 8 Classes de redes IP
29
A classe A permite formar at 126 redes (7 bits), sendo cada rede capaz de enderear
2
24
estaes diferentes. Endereos com todos os bits em zero no so vlidos. A classe B
permite formar 2
14
redes e endereamento de 65.535 estaes diferentes em cada n da rede.
Com a classe C possvel criar 2
21
redes diferentes, sendo que cada rede poder enderear at
256 estaes (8 bits). A classe D utilizada para endereamento multicast, para difuso de
pacotes entre estaes e redes. A classe D est definida como reservada para uso futuro.
A manipulao por software permite criar redes virtuais com base no endereamento
nico que uma estao pode ter na rede. As aplicaes que dedicam-se ao roteamento de
pacotes tratam essencialmente os bits que identificam a rede, objetivando encaminhar os
datagramas para a rede destino o mais rapidamente possvel, visto que devem ser processados
por equipamentos de alto desempenho.
3.8 IP ORIENTADO POR HARDWARE
H duas correntes de pensamento quanto forma de implementao do nvel de
transporte, como pode ser observado no trabalho de Iren e Amer (1999). Uma busca a
implementao do nvel de transporte orientado por hardware e outra direciona para
transporte orientado aplicao.
A corrente que busca o transporte orientado por hardware defende a implementao
deste servio em sistemas de integrao em larga escala, do tipo circuitos VLSI e
processadores dedicados. Defendem sua proposta argumentando que a necessidade do uso de
temporizadores, interrupes e acesso a memria degradam a desempenho do protocolo de
transporte. Assim defendem que seria necessrio o uso de arquiteturas dedicadas para esta
finalidade.
Os defensores do transporte em nvel de aplicao, argumentam que os atuais
processadores fornecem os recursos necessrios para que a implementao se faa a nvel de
sistema operacional, com vantagens para todos, visto que continuaria permitindo que sua
atualizao tecnolgica no fique presa ao hardware.
Esta, sem dvida, a forma mais conveniente de manter o protocolo sempre em
contnuo desenvolvimento, visto que no restringe novas implementaes a alteraes de
hardware.
3.9 ESPECIFICAO IP
O datagrama IP encontra-se especificado em RFC791. A seguir sero descritos o
cabealho (mostrado na Figura 9) e a finalidade de cada campo.
30
32 bits
Version IHL Type-of-service Total length
Identification Flags Fragment Offset
Time-to-live Protocol Header checksum
Source address
Destination address
Options (+ padding)
Data (variable)
Figura 9 Formato do cabealho IP Verso 4
Os campos que compem o cabealho de um pacote IP so:
version (4 bits): utilizado para informar a verso do protocolo;
IHL (4 bits): fornece o comprimento do cabealho em unidades de 32 bits;
type-of-service (8 bits): determina como o datagrama deve ser tratado e est
subdividido em cinco subcampos:
- precedence (bits 0-2): especifica a precedncia do datagrama com valores
variando de zero (precedncia normal) at sete (controle de rede);
- D (bit 3): especifica o tipo de transporte que o datagrama deseja, quando
definido solicita um intervalo baixo;
- T (bit 4): especifica o tipo de transporte que o datagrama deseja, quando
definido solicita um throughput alto;
- R (bit 5): especifica o tipo de transporte que o datagrama deseja, quando
definido solicita alta confiabilidade;
- bits 6 e 7: reservado para uso futuro;
total length (16 bits): fornecer o tamanho total do datagrama IP, incluindo o
cabealho e os dados;
identification (16 bits): nmero inteiro nico que identifica o datagrama (utilizado
para controle de fragmentao de datagramas);
flags (3 bits): bits de controle de fragmentao:
- bit 0: reservado, deve ser zero;
- bit 1: no fragmentar o datagrama;
- bit 2: ltimo fragmento.
fragment offset (13 bits): especifica o deslocamento do datagrama quando este
fragmentado;
time-to-live (8 bits): especifica o tempo em segundos, que o datagrama pode
permanecer no sistema de interligao em rede antes de ser descartado;
protocol (8 bits): especifica qual protocolo de alto nvel foi utilizado para criar a
mensagem, que est sendo transportada na rea de dados do datagrama. Este dado
esta especificado na RFC790, sendo 1 para ICMP, 6 para TCP e 17 para UDP;
31
header checksum (16 bits): soma de verificao dos dados do cabealho somente.
Os dados so somados em unidade de 16 bits em complemento de 1;
source address (32 bits): endereo IP do transmissor;
destination address (32 bits): endereo IP do destino do datagrama;
options (24 bits): campo utilizado para testes ou depurao da rede. No
necessrio em todo o datagrama. Este campo pode variar de tamanho conforme as
opes selecionadas;
padding (N bits): utilizado para preenchimento com bits visando garantir que o
cabealho seja mltiplo de palavras de 32 bits (deve ser preenchido com zeros).
Conforme Comer e Stevens (1999a, p. 101), o servio mais importante da interligao
em redes consiste em um sistema de entrega de pacotes. O protocolo IP define este
mecanismo de transmisso sem conexo no confivel dos programas de interligao em rede
TCP/IP. O protocolo define a unidade bsica de transferncia de dados utilizada atravs de
uma interligao em rede, fazendo com que seja especificado exatamente o formato de todos
os dados que trafegam pela interligao.
Outra funcionalidade que o IP apresenta o roteamento de pacotes, escolhendo um
caminho por onde os dados sero enviados.
Outro aspecto que sua estrutura de dados propicia informar como os roteadores
devem processar os pacotes, como e quando as mensagens de erro devem ser geradas e as
condies segundo as quais os pacotes podem ser descartados.
3.10 MODELO DE OPERAO IP
Estaes conectadas em uma rede TCP/IP devem se comportar de forma similar no
tratamento dos dados que trafegam na rede. A especificao do protocolo IP descreve
detalhadamente como este comportamento deve ser. Cada programador ao ler esta
especificao procura priorizar diferentes recursos descritos no protocolo. Assim, diferentes
implementaes so construdas, podendo diferir uma da outra. Para tentar minimizar
problemas de compatibilidade h a especificao de um mnimo de recursos que uma
interface IP deve atender. Na RFC 791 est descrita a interface mnima que deve ser
implementada.
3.11 MENSAGENS DE ERRO (ICMP)
O protocolo IP implementa a entrega no segura de pacotes, mas para dar um mnimo
de condies de administrao de falhas na rede, foi criado o protocolo ICMP (Internet
Control Message Protocol). Este trafega sob o datagrama IP, em sua rea de dados, e tem o
objetivo de criar condies para deteco de falhas na entrega ou roteamento de pacotes. Sua
especificao est descrita na RFC792.
O motivo de encapsular mensagens ICMP no protocolo IP, que este necessita
trafegar por vrias redes at alcanar seu destino.
Uma funcionalidade importante implementada por aplicaes que fornecem a rota
percorrida por pacotes at o seu destino. Estas aplicaes utilizam o ICMP como forma de
obterem as informaes deste trajeto. A tcnica empregada faz com que o TTL (Time To Live)
das mensagens ICMP enviadas, tenham valores que variam de 1 at o nmero de saltos de
roteadores que se espera at o destino. Cada pacote que passa por um roteador tem seu TTL
32
decrementado em uma unidade. Ao atingir o valor zero os pacotes so descartados, mas a
maioria dos roteadores mandam de volta uma mensagem ao remetente, indicando que o
pacote foi descartado. Esta informao de retorno traz os dados que indicam at onde os
pacotes foram. O formato das mensagens ICMP descrito na Figura 10.
32 bits
Type Code Checksum
Unused
Internet Header + 64 bits of Original Data Datagram
Figura 10 Formato do cabealho do protocolo ICMP
Cada mensagem ICMP tem um formato diferente dependendo de seu propsito, no
entanto alguns campos iniciais so comuns:
type (8 bits): identifica o tipo de mensagem. O campo type pode ter os seguintes
valores e significados entre outros:
- 0: resposta de eco;
- 3: destino no acessvel;
- 4: dissipao na origem (congestionamento);
- 5: redirecionamento;
- 8: solicitao de eco;
- 11: tempo excedido para um datagrama;
- 12: problemas de parmetro no datagrama;
- 13: solicitao de indicao de hora;
- 14: resposta de indicao de hora;
- 15: solicitao de mscara de endereo;
- 16: resposta de mscara de endereo.
code (8 bits): informa detalhes sobre o tipo de mensagem;
checksum (16 bits): soma de verificao que abrange somente os dados ICMP.
Embora todos estes tipos de mensagem estejam disponveis, a sua implementao em
sistemas com poucos recursos no essencial. Para este projeto a implementao se restringiu
ao tratamento dos cdigos 0, 8 e 12, visto que os demais cdigos abordam informaes e
tratamentos que se implementados iro contra a abordagem que busca um desempenho
otimizado.
H essencialmente duas classes de mensagens: uma de origem em estaes, que
normalmente indica destino inatingvel ou uma resposta de eco, e outra de origem em
roteadores, normalmente indicando problemas na rede ou rotas livres.
Mensagens de erro ICMP, devem incluir os primeiros 60 bytes do cabealho da
mensagem original, logo aps o cabealho ICMP. Desta forma a origem da mensagem poder
identificar o datagrama e tomar as medidas necessrias para corrigir o problema.
33
3.12 USER DATAGRAM PROTOCOL (UDP)
O UDP implementa um servio de transmisso sem conexo, no confivel, usando o
IP para transportar mensagens entre mquinas. Sua especificao esta descrita na RFC768.
Este protocolo implementa um servio sem garantia de entrega de datagramas, ou seja,
um datagrama pode ser perdido, entregue em duplicidade ao destino ou mesmo entregue fora
de ordem. Tambm no implementa controle de integridade de dados. Seu formato de
cabealho descrito na Figura 11.
Pelas suas caractersticas utilizado para transportar dados onde a importncia maior
seja o fluxo e no sua integridade, como, por exemplo, a transmisso de uma vdeo
conferncia onde uma frao de dados perdidos no compromete o restante da informao.
No caso deste projeto uma possvel aplicao abordaria a simples recepo de dados,
que poderiam ser monitorados por uma estao cliente. Neste caso a simplicidade deste
protocolo atenderia s necessidades.
O protocolo UDP fornece suporte para endereamento de portas, permitindo assim
distinguir qual aplicao deve receber determinado pacote de dados que tenha chegado. Desta
forma, vrias aplicaes distintas, executando em uma mesma mquina, podem fazer acesso
assncrono dados remotos.
Seu desempenho pode ser considerado muito bom em redes com baixa taxa de erros,
mas tende a ser problemtico em redes de baixa qualidade. Estes fatores devem ser levados
em considerao durante a sua implementao.
32 bits
Source port Destination port
Length Checksum
Figura 11 Formato do cabealho UDP
Os campos do cabealho UDP so:
source port (16 bits): porta do protocolo que foi obtida na conexo (opcional,
quando no usada deve ser zero);
destination (16 bits): porta do protocolo UPD cliente destino, aberta pelo processo
que espera receber/transmitir dados;
length (16 bits): contm o comprimento do datagrama UPD, incluindo cabealho e
dados;
checksum (16 bits): soma de verificao de 16 bits em complemento de um de
todo o datagrama mais um pseudocabealho, que no enviado, formado pelo
endereo IP origem, endereo IP destino, 8 bits em zero, 8 bits do cdigo do
protocolo (17 para UDP) e o campo comprimento (sem o pseudocabealho).
4 A INTERFACE SOCKET
O conceito da abstrao socket originou-se no sistema operacional Unix. Um socket
pode ser visto como uma generalizao do mecanismo de acesso a arquivos do Unix,
conforme Comer e Stevens (1999a, p. 371), pois este incorpora servios e dispositivos ao
sistema de arquivos. Um socket sempre ter um tipo, de acordo com as propriedades de
comunicao e um ou mais processos associados a ele. Um socket uma forma de IPC
(Interprocess Communication) genrica que permite comunicao entre processos em rede,
mas pode ser utilizado para comunicao entre processos na mesma mquina.
Esta abstrao procura isolar os detalhes de funcionamento dos protocolos formando
uma interface de acesso para os aplicativos, representada na Figura 12. Na verdade os
projetistas tentaram criar um mecanismo geral para acomodar muitos protocolos, aumentando
substancialmente a complexidade da interface de E/S.
Socket
Protocolo 1 Protocolo 2 Protocolo 3
Interface IP
Interface 1 Interface 2 Interface 3
Figura 12 A interface socket e os protocolos
Mas os protocolos de rede no so to simples como um arquivo de acesso local, por
exemplo. Por isto a interface socket permite que alguns detalhes possam ser especificados
pelo programador. Assim foram criadas novas bibliotecas para acomodar a grande variedade
de protocolos e suas caractersticas, possibilitando que os programadores possam ter acesso a
detalhes que podem ser definidos pela aplicao, conforme sua convenincia.
35
No existe uma padronizao a respeito do conceito de interface socket, apenas este
modelo se difundiu tornando-se amplamente utilizado por vrios sistemas operacionais
(DUNKELS, 2001, p. 12).
4.1 A CHAMADA SOCKET()
Algumas chamadas de sistema so disponibilizadas para que aplicaes tenham acesso
aos recursos de dispositivos de transmisso e recepo de dados. Sempre que uma aplicao
deseja usar um servio de comunicao este deve abrir o dispositivo, efetuar a operao
desejada e fechar o dispositivo.
No ambiente UNIX (BSD), a chamada socket() cria o socket solicitado. Esta chamada
necessita de trs argumentos e retorna um inteiro:
s = socket ( DOMNIO, TIPO, PROTOCOL )
Se bem sucedida, a chamada retorna um inteiro que deve ser utilizado para identificar
o recurso disponibilizado nas chamadas seguintes.
O parmetro DOMNIO especifica o domnio onde o socket criado, definindo o
protocolo e o espao de nomes. O parmetro TIPO especifica o tipo de comunicao
desejado, orientado conexo ou sem orientao conexo. O terceiro parmetro pode ser
utilizado para selecionar um protocolo especfico. Neste caso o programador passa a
determinar o protocolo que deve ser utilizado, sendo necessrio amplo conhecimento dos
detalhes do protocolo escolhido.
Para finalizar o uso do socket e liberar os recursos deve ser realizada uma chamada
close(), que tem o seguinte formato:
int close ( socket )
Esta chamada utiliza o parmetro passado como argumento para determinar o socket a
ser fechado.
4.2 ASSOCIAO DE PORTAS AO SOCKET
Ao ser criado um socket, este no est associado nenhuma porta especfica de
endereo local ou remoto. Dependendo do tipo de aplicao, pode ser necessrio especificar
que um determinado socket passe a tratar uma porta. Existem muitos aplicativos que tem seu
funcionamento associado a determinados nmeros de portas, alguns foram citados no item
3.2.
A associao de portas a um socket realizada atravs da chamada bind():
int bind ( socket, LOCALADDR, ADDRLEN )
A chamada recebe um parmetro que associa o socket porta especificada na estrutura
LOCALADDR. Esta estrutura contm o endereo da mquina, o protocolo e o nmero da
porta que deve ser utilizada. Em caso de falha, um cdigo de erro retornado.
Do mesmo modo que necessitamos especificar uma porta local para um socket, pode
ser til associ-lo a uma porta remota. Aplicativos que utilizam servio de datagramas sem
conexo no necessitam especificar uma porta, necessariamente. Mas, se optar por um servio
de entrega confivel, deve existir uma associao a uma porta remota. Assim foi criada a
chamada connect(), que apresenta a seguinte sintaxe:
36
int connect ( socket, DESTADDR, ADDLEN )
O argumento socket identifica o descritor socket que deve ser associado. DESTADDR
uma estrutura, que especifica o endereo do socket que deve ser vinculado. O terceiro
parmetro informa o tamanho da estrutura DESTADDR. Em caso de falha, um erro
retornado.
Normalmente aps a criao de um socket, um programa servidor de comunicao usa
uma chamada de sistema para permitir que ele possa receber conexes. Esta chamada tem o
seguinte formato:
int listen ( socket, LENGTH )
Esta chamada recebe o indicador do socket a ser utilizado e o tamanho da fila de
conexes que o sistema deve disponibilizar. Esta chamada aplica-se somente para servios de
entrega confivel.
A chamada accept() bloqueia um processo at que seja estabelecida uma conexo ao
respectivo socket. Seu formato :
int accept ( socket, ADDR, ADDLEN )
A chamada accept() recebe o descritor do socket a ser tratado, o parmetro ADDR que
fornece uma estrutura que contm o endereo e o tamanho desta estrutura.
4.3 ENVIANDO E RECEBENDO DADOS
As operaes de envio e recebimento esto disponveis em vrias chamadas de
sistema. Algumas delas so: send(), sento(), sendmsg(), write(), read(), recvfrom(), recvmsg().
As chamadas send(), write() e read() somente podem ser utilizadas com sockets conectados,
pois no permitem que seja informado um nmero de porta em sua chamada.
A chamada send tem o seguinte formato:
int send ( socket, MESSAGE, LENGTH, FLAGS )
O parmetro socket especifica o socket a ser usado, o argumento MESSAGE indica os
dados que devem ser enviados, LENGHT informa a quantidade de dados e o ltimo parmetro
utilizado para controle da transmisso. Estes flags permitem que o programador tenha
acesso aos detalhes especficos do protocolo. Pode-se, por exemplo, especificar que os dados
devem ser tratados como dados urgentes.
Algumas chamadas bloqueiam o processo durante sua execuo, at que estas sejam
executadas ou retornem em caso de falha. A chamada write() tem esta caracterstica de
operao. Seu formato :
int write ( socket, MESSAGE, LENGTH )
O argumento socket indica o socket a ser utilizado, MESSAGE informa o endereo
dos dados a serem transmitidos e LENGTH a quantidade de dados que deve ser tratada. Em
caso de erro um cdigo retornado.
A chamada sendto() permite que sejam enviados dados por um socket desconectado.
Seu formato mostrado a seguir:
int sendto ( socket, MESSAGE, LENGTH, FLAGS, DESTADDR, ADDLEN )
37
Como pode ser observado, os quatro primeiros parmetros so os mesmos presentes na
chamada send(). O parmetro DESTADDR especifica o endereo do destino e o parmetro
seguinte informa o comprimento desse endereo.
Um outro formato para a chamada sendto() est implementado com o nome
sendmsg(), onde h somente trs parmetros, a fim de proporcionar uma chamada com menos
argumentos. Os parmetros so passados em um estrutura. Esta chamada tem o seguinte
formato:
int sendmsg ( socket, MESSAGESTRUCT, FLAGS )
Para o recebimento de dados est disponvel a chamada read(). Esta chamada
utilizada da mesma forma que no acesso a um arquivo, com exceo de que o primeiro
parmetro passado, refere-se ao descritor de um socket. Seu formato o seguinte:
int read ( socket, BUFFER, LENGTH )
O parmetro BUFFER indica o endereo de memria onde os dados sero
armazenados. O parmetro LENGTH informa o tamanho da rea do BUFFER. Esta chamada
utiliza um identificador de socket que deve estar conectado uma porta destino e bloqueia o
processo at o retorno da chamada.
Outro mtodo de recebimento de dados a chamada recvfrom(), esta chamada permite
que seja informada a porta de entrada dos dados a serem recebidos. Seu formato :
int recvfrom ( socket, BUFFER, LENGTH, FLAGS, FROMADDR, ADDRLEN)
O parmetro socket especifica o descritor do qual os dados devem ser recebidos.
BUFFER indica o endereo onde devem ser armazenados os dados e LENGTH o tamanho
desta rea. O parmetro FLAGS permite controlar a recepo. FROMADDR um ponteiro
para uma estrutura que contm o endereo do socket e ADDRLEN informa o tamanho desta
estrutura.
A forma simplificada da chamada recvfrom() recebe somente trs parmetros e tem o
seguinte formato:
int recvmsg ( socket, MESSAGESTRUCT, FLAGS )
Os parmetros so os mesmos utilizados na chamada sendmsg(), o que torna mais fcil
enviar uma resposta para o origem da mensagem.
4.4 CHAMADAS AUXILIARES
Existem muitas variaes no formato e no nmero de chamadas que permitem acesso
aos recursos de comunicao e recepo de dados no ambiente de sistemas operacionais.
Normalmente os protocolos destes sistemas fazem parte integrante destes ambientes.
O objetivo destas chamadas propiciar uma interface amigvel para acesso aos
recursos. Assim foram disponibilizadas muitas chamadas auxiliares para permitir maior
flexibilidade na implementao de aplicaes. Entre elas, podemos citar:
gethostbyname(): devolve o identificador de rede associado ao nome;
inet_addr(): converte uma cadeia de caracteres contendo o IP no formato de rede;
inet_toa(): converte um endereo de rede em uma cadeia de caracteres;
getsockename(): utilizada para obter a estrutura associada a um socket.
38
Muitas chamadas so implementadas para atender necessidades especficas de cada
sistema, visto que no h um padro definido, apenas um modelo a ser seguido, assim os
programadores implementam chamadas que podem variar de nome, nmeros de parmetros
necessrios ou mesmo a ao que se propem realizar, dependendo de cada implementao.
Portanto a utilizao destes recursos est associada ao sistema onde foi implementado. Ao
utilizar-se de outro sistema, onde estejam presentes chamadas de servio socket, importante
que haja um estudo para reconhecimento e entendimento adequado de sua implementao.
5 PROJETO PROPOSTO
O objetivo final deste projeto permitir que um sistema microprocessado possa de
conectar-se Internet utilizando-se de uma pilha de protocolos TCP/IP especialmente
implementada para este fim.
O protocolo TCP foi implementado por ser este o protocolo padro da Internet. O TCP
fornece um dos principais servios: a comunicao segura entre duas estaes. O protocolo
UDP, por sua simplicidade, foi agregado ao projeto, pois a maioria dos recursos de que ele
necessita sero implementados para atender aos requisitos do protocolo TCP.
O protocolo IP fundamental nesta implementao, pois o meio pelo qual os pacotes
so enviados ao nvel fsico, ao destino da conexo. Este tem o papel de fornecer aos nveis
superiores a abstrao de uma rede virtual. Junto ao protocolo IP estar includo o protocolo
ICMP, muito utilizado para tratamento de erros na rede.
Para que uma aplicao possa utilizar os recursos implementados em forma de uma
biblioteca, foi necessrio criar uma interface para disponibilizar estes recursos de
comunicao, de forma a manter um isolamento e tornar seu uso mais simples e seguro.
O projeto final inclui, alm da implementao da biblioteca, o desenvolvimento de um
prottipo para que se possa realizar os testes e avaliaes.
Para atingir estes objetivos muitos desafios foram sobrepujados. Alguns destes
desafios so:
Microcontrolador: Decidiu-se pelo uso de um determinado microcontrolador, o
qual foi estudado. Isto envolveu conhecer como so controlados os recursos de
memria, quais instrues esto disponveis (instruction set), quais recursos
especiais ele apresenta e como utiliz-los. Como so tratadas as interrupes de
hardware e de que forma devem ser utilizadas. Em muitos casos a linguagem de
montagem ser utilizada como forma de garantir um cdigo mais eficiente e
otimizado.
Recursos do kit de hardware: por se tratar de um projeto com implementao
prtica ser utilizado um kit de hardware, para que sejam realizados testes na
implementao, assim, foi necessidade conhecer bem como funciona este kit e
quais recursos ele disponibiliza. Conhecer completamente os recursos disponveis
foi determinante para que a implementao pudesse tirar proveito destes. de
acordo com a especificao do hardware que deve-se configurar corretamente a
ferramenta de gerao de cdigo.
SDCC: O compilador escolhido para a montagem dos cdigos tambm foi
estudado. Somente com pleno conhecimento de suas limitaes foi possvel evitar
falhas que podiam ser atribudas codificao. Alguns desafios foram conhecer
40
todas as ferramentas utilizadas e a forma como as mesmas so utilizadas, definir
como as ferramentas so configuradas para as necessidades necessrias, que
parmetros usam, etc.
Pilha TCP/IP: Foi necessrio conhecer os detalhes de funcionamento que fazem
com que cada protocolo tenha suas caractersticas prprias, como cada um
interage com os demais, de que forma uma aplicao usar os recursos, quais
pontos crticos de cada protocolo devem ter tratamento especial e qual a melhor
forma de resolve-los (C ou linguagem de montagem). Aqui o conhecimento dos
detalhes de funcionamento do hardware extremamente importante. Estes so
alguns dos desafios que este estudo proporcionou nesta rea.
Ambiente de testes: Toda implementao deve ter seu ambiente para depurao.
Apesar da ferramenta escolhida proporcionar meios para simulaes, estes testes
estaro restritos uma parte especfica do cdigo. No possvel uma simulao
completa, j que h funes de gerenciamento do hardware sendo executadas,
com interrupes de hardware sendo tratadas e bibliotecas sendo utilizadas. Foi
necessrio um ambiente de testes para o projeto. Este ambiente envolveu um
microcomputador sendo utilizado como cliente, conectado via cabo serial ao
sistema em desenvolvimento. Este proporcionou os meios para captura do trfego
de comunicao e auxiliou na depurao dos erros.
Funes de Gerenciamento: Para que as funcionalidades que se deseja
implementar sejam utilizadas foi necessrio que o hardware escolhido possua
funes que permitam seu gerenciamento. Este foi implementado garantindo o uso
adequado das interfaces disponveis, oferecendo recursos para que aplicaes
possam tirar o melhor proveito possvel. Neste caso foi exigido amplo
conhecimento dos recursos de hardware disponibilizados.
O desenvolvimento de cada atividade no acorreu de forma isolada. Todas tem relao
e devem ser priorizadas medida que o andamento de uma implique na realizao de outra.
Para que o projeto ocorresse dentro do prazo proposto, cada tarefa e suas implicaes, foram
avaliadas com antecedncia, quando possvel.
5.1 PROJETO DE SOFTWARE
A implementao da Biblioteca TCP/IP para Ambientes Microprocessados foi
realizada utilizando-se a tcnica de Engenharia Progressiva (PETERS e PEDRYCZ, 2001, p.
559). Esta tcnica um modelo simplificado da tcnica de desenvolvimento de software Ciclo
de Vida Incremental.
Parte-se de uma planejamento com especificao mnima. seguir iniciada a
implementao e na seqncia os testes para verificao de conformidade. A medida que as
especificaes vo sendo atendidas, novas so introduzidas, fazendo com que o ciclo volte a
se repetir continuamente.
O Modelo de desenvolvimento de software Ciclo de Vida Incremental pode ser visto
na Figura 13.
Algumas tcnicas de programao devem ser observadas nesta implementao, como,
por exemplo, evitar flexibilidade desnecessria, isto pode tornar muito difcil a depurao e a
localizao de erros posteriormente (MAGUIRE, 1994, p. 176). Ao mesmo tempo deve-se
introduzir crticas em parmetros, evitando-se excessos, o que poderia, em determinados
casos, causar degradao de desempenho.
41

Requisitos
Projeto Implementao Testes
Projeto Implementao Testes
Projeto Implementao Testes
Figura 13 Modelo de ciclo de vida incremental
A fase de levantamento de requisitos foi realizada na avaliao de cada protocolo que
foi implementado. Nesta fase obteve-se os dados que seriam necessrios manipular, seus
relacionamentos e a definio de estruturas de dados.
O projeto avaliou as prioridades, seqncia de operao, tamanhos de reas de dados
volteis, definiu as funes e mdulos que podem ser compartilhados e interao entre
mdulos.
Durante a fase de implementao, alguns detalhes no previstos surgiram, os quais
foram corrigidos reavaliando suas implicaes no planejamento existente.
Uma boa prtica de codificao utilizada, foi a introduo de comentrios junto ao
cdigo, a fim de facilitar seu entendimento e o posterior incremento de novos requisitos. Para
tornar o cdigo apto a uma depurao mais amigvel, tambm foi introduzido cdigo que
permite visualizar certos dados considerados relevantes.
A fase de testes serviu para avaliar os requisitos implementados e o posterior
incremento nas funcionalidades do projeto.
5.2 IMPLEMENTAO DO PROTOCOLO TCP/IP
A pilha de protocolos TCP/IP foi criada de forma otimizada, tendo-se em mente que
os recursos disponibilizados so limitados. O uso da UCP (Unidade Central de
Processamento) estar sendo disputado por vrias necessidades. Haver interrupes de
hardware, funes de gerenciamento controlando os dispositivos de interface, uma possvel
aplicao sendo executada. Isto dever ser administrado de forma que no haja alocao
exclusiva da UCP.
Alguns detalhes de cada protocolo foram otimizados para atingir um uso mais racional
dos recursos, sem com isto descuidar da compatibilidade.
A construo dos protocolos buscando isolamento em demasia, pode contribuir para
um maior sobrecarga entre camadas. Um isolamento excessivo contribuiria para degradar a
desempenho, visto que acarretaria realocao de dados entre as vrias camadas envolvidas na
comunicao. Deve-se ter em mente que cada protocolo est designado para resolver um
determinado problema em sua camada, mas uma possvel propagao de dados entre estas
pode ser realizada sem comprometer suas caractersticas.
42
O protocolo TCP, por ser considerado o de implementao mais delicada, por envolver
contagem de ciclos de tempo, largamente utilizados em sua mquina de estados e, em muitos
casos, utilizado como regra para causar mudana de estado em sua mquina de estados, deve
estar mais prximo do ncleo, inclusive podendo ser parte integrante deste, como forma de
garantir um melhor desempenho global. A avaliao das necessidades de cada protocolo pode
auxiliar na escolha a ser feita para sua implementao. O protocolo TCP tem um execuo
peculiar neste caso, este envia e recebe dados provenientes de mais de uma camada.
Uma possvel abordagem foi definir o protocolo TCP para aceitar somente uma
conexo, neste caso, significaria uma grande simplificao na implementao, pois no
haveria necessidade de armazenar mltiplas cpias da estrutura de dados responsvel por
armazenar as conexes vigentes.
Quanto ao protocolo IP, este pode contribuir para minimizar o uso de recursos. Ao se
observar o uso de seu cabealho, podemos verificar que este pode ter um cabealho fixo, pois
muitas de sua opes no so utilizadas na prtica. Isto torna sua utilizao mais rpida e
simplifica a codificao.
Os recursos de memria utilizados podem ser minimizados de outra forma. A
biblioteca destina-se a dar suporte conexo Internet para um sistema microprocessado.
Equipamento este que, normalmente, deve estar dedicado para uma determinada atividade de
monitorao, envolvendo leitura de sinais analgicos, controle de acionamentos, etc. Sua
prioridade no manter uma base de dados histrica sobre algum evento, mas sim manter o
controle sobre determinado processo ou estados de entradas. Assim sua interao via Internet
estaria limitada a fornecer dados recentes, os quais estariam constantemente sendo
atualizados, ou receber algum tipo de dado que poderia ser interpretado por uma aplicao em
execuo. Com esta viso no haveria necessidade de armazenar buffers enviados, para os
casos em que os dados estejam sempre sendo atualizados e no fossem prioridade. Outra
forma seria o uso do protocolo UDP, que traria mais vantagens neste caso, pois um
protocolo mais adequado para envio de dados onde pode-se desprezar dados perdidos em um
envio.
5.3 FUNES DE GERENCIAMENTO
Uma parte importante do projeto foi tomada pela definio e construo das funes
de gerenciamento para gerenciar o hardware utilizado. Mesmo sendo um sistema de pequeno
porte, se comparado com um microcomputador que normalmente convivemos, este tem
muitas semelhanas. Uma viso geral de sua estrutura pode ser observada na Figura 14.
As funes construdas desempenha atividades bsicas para gerenciamento de
interfaces e prestar alguns servios s aplicaes que estaro sendo executadas. Seu
funcionamento foi definido de forma a acomodar o gerenciamento do hardware, rotinas
bsicas para tratamento de interrupes, fornecimento de servio de acesso dados e
chamadas de sistema para acesso biblioteca de comunicao.
Alm de ser responsvel pela inicializao do hardware, com o objetivo de preparar os
perifricos para entrar em funcionamento, uma funo principal deve ficar em um lao
infinito, responsvel pela operao de atendimento das requisies do hardware, bem como
execuo da aplicao principal.
43
SERIAL PORTAS I/O
D/A UCP+MEMRIA TECLADO
A/D DISPLAY LCD
Figura 14 Estrutura do hardware com suas interfaces
O isolamento entre as funes de gerenciamento, as bibliotecas e as aplicaes foi
planejado de acordo com a avaliao de desempenho necessria e o custo que isto
representaria ao sistema. Uma viso da estrutura construda pode ser vista na Figura 15. Como
mencionado anteriormente, o isolamento entre as camadas permitiu um grau de
permeabilidade entre as mesmas, com o objetivo de tornar o desempenho global mais
eficiente.
APLICAO
FUNES DE
GERENCIAMENTO
BIBLIOTECA
TCP/IP
Figura 15 Interao entre camadas
Em alguns casos foi til para uma aplicao ter acesso direto aos perifricos. Neste
caso deve-se evitar conflitos com as funes de gerenciamento do hardware, prevendo-se esta
possibilidade antecipadamente para poder implementar os acessos isoladamente.
5.4 AMBIENTE DE TESTES
O ambiente de testes foi fundamental para que o projeto tivesse xito. Esta estrutura
foi planejada antecipadamente para estar pronta quando iniciassem os testes de comunicao.
Foi necessrio alocao de recursos para a montagem deste ambiente. Os seguintes itens
foram utilizados:
um microcomputador com uma porta de comunicao serial disponvel;
software para interagir com o sistema desenvolvido e ferramentas que
possibilitem captura de pacotes que trafegam entre os protocolos;
cabos de comunicao para interligao dos equipamentos;
kit com microcontrolador.
44
Alm destes recursos, h as ferramentas utilizadas para o desenvolvimento do projeto.
Foi necessria muita pesquisa na Internet para a localizao de ferramentas livres para o
ambiente escolhido e que tornassem o desenvolvimento mais eficiente.
5.5 ESPECIFICAO DO PROTTIPO
Para servir de base para a implementao deste projeto, foi necessria uma plataforma
com caractersticas especficas, empregadas em sistemas de controle e monitorao.
Normalmente este hardware contm um circuito eletrnico contendo um microcontrolador e
circuitos perifricos que disponibilizam recursos para seu funcionamento, fornecendo
memria, canais de entrada e sada, pelos quais possvel interagir com o hardware.
Procurou-se uma plataforma onde houvesse documentao e ferramentas de
desenvolvimento, tais como compilador, depurador, baixo custo e tecnologia de fcil
manuteno, prevendo-se que em caso de dano ao hardware, durante a fase de
desenvolvimento poderia haver comprometimento nos prazos para concluso dos trabalhos.
Algumas caractersticas de hardware definiram o dispositivo que foi ser escolhido:
processador 8 bits;
memria voltil (RAM) de 32 Kbytes;
memria de programa de 64 Kbytes;
interface serial RS232;
entrada para teclada 3X4 teclas no mnimo;
interface para display de cristal lquido de duas linhas e 20 caracteres.
O processador de 8 bits foi definido por ser um dispositivo facilmente encontrado no
mercado de microcontroladores, com uma grande variedade de tipos disponveis. Os itens que
mais devem pesar na seleo do mdulo so: memria, ferramentas de desenvolvimento e
interfaces.
5.5.1 Caractersticas do mdulo selecionado
Entre as inmeras opes de hardware que foram localizadas para servir de base para
a implementao, selecionou-se o modelo CP-AT32 PLUS. Este modelo fornecido pela
empresa Futurlec (http://www.futurlec.com), localizada na Austrlia. A unidade central desta
placa um microcontrolador de 8 bits da PHILIPS modelo P89C51RD2. Este
microcontrolador compatvel com o chip 8051 do fabricante INTEL. As caractersticas desta
placa so:
processador P89C51RD2 e clock 18,432 Mhz;
64 K bytes de ROM Flash na prpria UCP;
32 K bytes de RAM;
9 portas I/O;
interface para display grfico LCD (Liquid Cristal Display);
interface para teclado 4 x 4;
8 portas de sada Open Collector;
ADC de 12 bits, com dois canais;
DAC de 8 bits, com 4 canais;
EEPROM serial da famlia 24XX;
relgio de tempo real DS1307;
45
RAM back up com DS1307;
interface RS232;
interface RS422/RS485;
carga de software direto para a placa via interface serial;
fonte reguladora.
A disponibilidade de recursos de memria e a variedade de interfaces possibilitou a
escolha deste mdulo, que propicia facilidade de carga de verses, pois utiliza memria flash
incorporada junto prpria UCP. Este recurso tornou o desenvolvimento e depurao mais
eficientes.
5.5.2 Especificaes do microcontrolador
O microcontrolador utilizado no mdulo CP-AT32 PLUS tem vrias caractersticas
que foram estudadas, para ser utilizado adequadamente. Algumas destas caractersticas mais
importantes so:
P89C51RD2 Unidade Central de Processamento compatvel com a famlia de
microcontroladores 8051 conforme datasheet disponibilizado pela fabricante
(http://www.semiconductors.philips.com/pip/P89C51RB2HBP);
On-Chip Flahs Program Memory rea de dados para programa esto junto ao
chip do microcontrolador;
memria ROM interna de 64 K bytes;
boot ROM UCP contm programa interno para carga de cdigo via porta serial;
6 ou 12 ciclos de relgio por operao;
capacidade de endereamento de at 64 K bytes de RAM;
4 nveis de prioridade de interrupes;
7 tipos de interrupes;
32 portas de I/O;
Full-duplex UART;
3 registradores de 16 bits com contadores programveis;
conjunto de instrues para manipulao de bits.
Este chip de microcontrolador, feito pela empresa PHILIPS, fabricado com
tecnologia CMOS que garante baixo consumo de energia. Esta tecnologia sensvel a
descargas eletrostticas, portanto deve-se ter cuidado especial com sua manipulao.
A gravao de dados facilitada pelo uso de memria interna ao microcontrolador.
Esta caracterstica evita o uso de memria de programa externa (EPROM), que torna o
processo de desenvolvimento mais lento, pela necessidade de apagamento e regravao da
memria a ser utilizada.
5.5.3 Interfaces disponveis
desejvel que todo dispositivo de hardware tenha recursos que disponibilizem meios
para interao com o dispositivo. Estes recursos so disponibilizados atravs de interfaces que
apoiam a conexo de dispositivos perifricos que do suporte entrada e sada de dados.
Dentre os recursos disponibilizados pelo mdulo CP-AT32 PLUS esto:
controle de teclado de at 16 teclas;
interface para display grfico LCD;
46
2 canais de entrada conversor A/D de 12 bits que permitem monitorar sinais
analgicos at 5 V;
4 canais de sada de conversor D/A de 8 bits;
8 portas de I/O open collector que permitem acionamento direto de dispositivos
com maior demanda de corrente, por exemplo, rels;
interface de comunicao serial. Esta utilizada para carga de programas e como
interface de comunicao para a rede.
mini alto-falante conectado a uma porta do microcontrolador. Permite emitir sons
associado eventos.
Atravs destas interfaces foi possvel interagir com o sistema, permitindo que
informaes de sua operao fossem visualizadas continuamente.
6 IMPLEMENTAO DO PROJETO
Este projeto envolveu o domnio sobre duas reas de conhecimento: os protocolos que
seriam implementados e o hardware microprocessado escolhido para ser utilizado como
prottipo. Em funo disto, optou-se por isolar a implementao da lgica de funcionamento
dos protocolos do ambiente microprocessado. Assim, foi possvel ter-se problemas menores,
mais fceis de resolver. Este isolamento permitiu que o desenvolvimento da lgica existente
na implementao de cada protocolo no fosse influenciado pelo desconhecimento das
limitaes do prottipo, bem como por alguma limitao ou restrio presente no compilador
para este microcontrolador.
Esta escolha permitiu o uso de um ambiente mais robusto no desenvolvimento da
lgica dos protocolos. Assim pode-se optar por um ambiente que tornou possvel a
codificao e depurao integrados. Esta medida, sem dvida, foi crucial para que o projeto
atingisse o sucesso.
A base para qualquer desenvolvimento de aplicaes deve estar amparada em testes
que servem para validar aquilo que foi especificado e implementado, sendo assim,
fundamental que este ambiente de teste esteja acima de qualquer suspeita, no que diz respeito
a seu funcionamento. Este ambiente de testes utilizado para exercitar o sistema em
desenvolvimento foi escolhido em funo da facilidade que traria para a depurao de falhas.
O desenvolvimento foi realizado em um ambiente de 32 bits, utilizando-se de um
compilador com ambiente integrado incluindo compilador, ligador e editor. Este ambiente
trouxe algumas restries quanto ao controle e manipulao dos protocolos utilizados no
ambiente de teste, em decorrncia do no acesso que se tem aos recursos de chamadas de
sistema, para manipulao de estruturas de dados utilizadas em chamadas socket.
6.1 AMBIENTE ESCOLHIDO
A opo de desenvolver a lgica de operao dos protocolos em uma plataforma 32
bits possibilitou o uso de ferramentas mais adequadas e que tornaram o desenvolvimento mais
fcil de ser administrado. A preocupao foi centralizada em manter uma implementao C
ANSI (American National Standards Institute), para que ao portar-se o cdigo para o
compilador do ambiente destino, no houvessem restries quando ao cdigo. Outra
preocupao foi seguida quanto ao acesso ao recurso de comunicao do sistema. Este deveria
trazer o mnimo de impacto no momento de portar o cdigo de uma plataforma para a outra.
Como este recurso envolve uma chamada de sistema, sua abordagem foi simples de
implementar, pois no sistema do prottipo este recurso faz parte das funes de
48
gerenciamento operacional que controla os recursos do hardware. Bastou manter esta
chamada restrita a uma funo de envio recebendo parmetros para seu controle.
6.2 AMBIENTE DE TESTE
O desenvolvimento no ambiente Windows permitiu conjugar a ferramenta de
desenvolvimento com o ambiente de teste. Por permitir facilidade no desenvolvimento e
depurao, foi escolhida a conexo com a Internet do Windows, como forma de verificar o
funcionamento da implementao que estava sendo realizada. Este processo ocorre de forma
automtica quando se utiliza algum recurso que dispare o acesso Internet envolvendo a
biblioteca socket do Windows. No se tem o controle sobre este processo, apenas pode-se dar
incio sua execuo. A API (Application Programming Interface) do Windows tem algumas
chamadas que permitem manipular certos parmetros, mas que se restringem a informar como
devem proceder durante sua execuo, sem permitir o controle destes. Esta forma de
funcionamento implementada por ser o Windows um produto comercial e por buscar
simplificar o acesso Internet para seus usurios.
Esta escolha de ambiente de teste trouxe algumas conseqncias implementao que
estava sendo realizada. Pretendia-se implementar no prottipo uma arquitetura cliente, que
toma a iniciativa de conexo. Face s restries impostas, a forma de contorn-las foi
implementar uma arquitetura servidor no prottipo.
O Windows, durante uma conexo discada Internet, utiliza o protocolo PPP (Point to
Point Protocol) para estabelecer uma conexo com um provedor. Outra srie de protocolos
tambm utilizada no processo inicial de conexo. Outro detalhe que o Windows espera
manipular um MODEM (MOdulador-DEModulador) em uma conexo discada. Assim,
sempre antes de iniciar uma conexo so trocadas seqncias de caracteres de controle com o
MODEM, que o Windows espera que esteja conectado e funcionando. Estas seqncias de
caracteres dizem ao MODEM como este deve operar e o telefone a ser discado. Aps esta
troca inicial de dados o Windows espera receber a confirmao do MODEM de que houve a
conexo com o nmero discado. Esta troca de seqncias de caracteres pode ser vista na
Figura 17, onde os caracteres em vermelho representam os dados que esto sendo enviados
pelo Windows e em azul os que esto sendo recebidos do MODEM.
Figura 17 Troca de seqncias de caracteres com o MODEM
O Windows detecta que a conexo se estabeleceu ao receber do MODEM a seqncia
de caracteres CONNECT, a partir deste momento se d incio o uso do protocolo PPP para
o estabelecimento da conexo com o provedor de acesso Internet.
Para poder simular tal funcionamento foi necessrio implementar esta troca de
seqncias de caracteres iniciais, para colocar a mquina de estados do Windows apta a dar
49
incio ao processo de conexo discada. Utilizou-se uma configurao que informava sobre a
existncia de um MODEM externo, desta forma foi possvel utilizar um computador com
duas portas de comunicao interligadas, conforme a configurao mostrada na Figura 18.
Onde uma porta serial controlada pela processo disparado pelo Windows e outra pelo
processo que simularia as respostas que o sistema operacional esperava receber.
Com esta tcnica seria possvel o desenvolvimento dos protocolos e seu teste no
mesmo ambiente, de forma prtica e controlada.
Figura 18 Interconexo entre os sinais RS-232
6.3 IMPLEMENTAO DO PROTOCOLO PPP
Um estudo extra foi necessrio para que o projeto fosse implementado no ambiente
escolhido, em virtude das restries impostas pelo ambiente de teste, que necessariamente
utiliza-se do protocolo PPP para uma conexo discada. A base para este estudo foi buscar as
informaes de especificao do protocolo. Por se tratar de uma arquitetura aberta seu
conhecimento de domnio pblico, estando presente na documentao disponvel na
Internet.
Para auxiliar o entendimento de como funciona um processo de conexo a um
provedor de acesso Internet, foi estudado um caso prtico. Foi realizada a captura dos dados
que trafegam entre um microcomputador e um provedor de acesso Internet, no momento em
que isto ocorre, para que os dados que so trocados fossem analisados, confrontando-os com
sua descrio de funcionamento e assim auxiliar o entendimento da operao do protocolo
PPP utilizado neste caso.
O protocolo PPP utilizado para transportar dados em uma conexo discada. Est
posicionado no nvel 2 (Enlace de Dados) da arquitetura OSI. Trabalha em conexes full-
duplex com transmisso de dados bidirecional e assume que os dados so enviados de modo
ordenado. Sua estrutura de controle simples e envolve poucos parmetros, como pode ser
visto na Figura 19, objetivando reduzir ao mnimo a quantidade de dados de controle
introduzidos pelo protocolo.
Flag Address Control Protocol Information Padding FCS Flag
Figura 19 Formato do protocolo PPP
Cada campo do protocolo tem uma finalidade descrita a seguir:
50
flag: cada quadro de dados inicia e termina com um byte 0x7E, sendo utilizado
para sincronizao na identificao de incio e fim de um quadro;
address: especifica o endereo da estao que deve receber os dados, sendo
utilizado o valor 0xFF para especificar todas as estaes;
control: controle de seqncia e confirmao de recebimento;
protocol: usado para identificar o protocolo transportado na rea de dados
(information);
information: rea de dados;
padding: rea para preenchimento, se necessrio;
FCS: frame check sequence, soma binria de 16 bits para verificao de erros no
frame;
flag: byte indicador de fim de quadro.
A verificao de integridade do quadro garante que dados incorretos no sejam
tratados, ocasionando erros de processamento, visto que os mesmos so descartados
automaticamente quando no for constatada a sua integridade. Este descarte realizado sem
qualquer notificao para a origem. responsabilidade de quem esta enviando os dados tentar
novamente quando no recebe resposta a uma solicitao.
Segundo a especificao do protocolo PPP, no RFC1661, um link para ser estabelecido
deve passar por uma negociao que determinar as regras a serem usadas na conexo e
servem para tornar o protocolo verstil e adaptvel a uma grande variedade de ambientes.
Para isto so utilizados protocolos que auxiliam o processo de negociao. Os protocolos
utilizados so:
LCP: Link Control Protocol, utilizado para negociar o formato de encapsulamento
dos dados, visando reduzir as reas de controle, negociar limites e tamanhos de
buffers, solicitar a finalizao da conexo;
PAP: Password Authentication Protocol, descrito em RFC1334, utilizado para
realizar autenticao de usurio com envio de nome de usurio e senha;
IPCP: Internet Protocol Control Protocol, descrito em RFC1332, utilizado para
configurar o uso do Internet Protocol encapsulado no protocolo PPP;
CCP: Compression Control Protocol, descrito em RFC1662, responsvel pela
negociao de algoritmos de compresso.
Seguindo a abordagem escolhida para a implementao dos protocolos, estes foram
implementados de forma seqencial, obedecendo o ciclo de desenvolvimento incremental
(projeto, implementao e testes).
6.3.1 Fluxo de negociao PPP
Ao dar-se incio a uma conexo discada, o Windows segue uma seqncia de
negociao que deve ser observada para que o mesmo atinja o estado conectado, permitindo
que exista trfego de dados utilizando o IP e TCP sob o protocolo PPP. Para chegar-se a este
estado a negociao deve passar por vrias etapas, onde so trocadas informaes que
permitem avanar o estabelecimento da conexo para o estado em que ambos tenham
condies de atender os requisitos impostos por cada implementao. Cada fase utiliza um
protocolo especifico e regras especificas. Um exemplo de fluxo a ser seguido pode ser visto
na seqncia a seguir:
1. enviado um quadro contendo o protocolo LCP, com os parmetros que se deseja
que sejam negociados.
51
2. O receptor devolve uma confirmao de aceite (ACK) ou de rejeio (NAK). No
caso de rejeio, este toma a iniciativa de informar os valores que devem ser
utilizados.
3. Assim que foi concluda a negociao, que tambm envolve a forma de
autenticao desejada, se d incio a fase seguinte, que a fase de autenticao
pelo modo j negociado. Neste caso est se utilizando autenticao PAP.
4. Aps a troca de dados de autenticao se inicia a fase de negociao envolvendo o
protocolo IPCP, o qual define como ser utilizado o IP encapsulado no protocolo
PPP. Nesta fase so definidas algumas regras de otimizao no envio de dados,
visando aumentar a eficincia do link.
5. Como ltima fase antes de passar para o estado conectado, existe a negociao
utilizando-se do protocolo CCP, o qual utilizado para negociar algoritmos de
compresso.
Apesar de existirem regras bem definidas quanto ao tipo de parmetros que podem ser
negociados, estes tem uma implementao flexvel, visto que so definidas as condies
mnimas que devem ser atendidas por aqueles que pretendem se utilizar destes recursos de
conexo, principalmente em se tratando de provedores de conexo, o qual devem atender o
mais variado tipo de dispositivo que necessita acesso Internet.
6.3.2 Otimizao na negociao LCP
Para esta implementao foi necessrio direcionar as exigncias de conexo com
vistas a atender as restries impostas pela capacidade e recursos disponveis no ambiente
prottipo. Durante a fase de negociao LCP, a configurao do MRU (Maximun Receive
Unit), que define o comprimento mximo que um quadro PPP pode atingir, foi estabelecido
em 128 bytes, quando o normal seria o Windows solicitar um tamanho de 1.500 bytes. Outros
parmetros de negociao que no suportados pela implementao realizada, so rejeitados.
A implementao do tratamento LCP se restringiu ao tratamento dos seguintes itens:
VENDOR SPECIFIC: uma solicitao de negociao de parmetros desta classe
rejeitada, somente as definies padro do protocolo so negociveis;
OPTION ACCM: esta opo aceita e define quais caracteres so tratados por
seqncia de escape;
AUTENTICATION PROTOCOL: foi estabelecido que a autenticao seria
realizada utilizando-se o protocolo PAP e uma solicitao diferente desta
rejeitada;
MAGIC NUMBER: esta opo aceita e retribuda adequadamente;
PROTOCOL FIELD COMPRESSION: foi previsto tratamento para esta opo,
que visa otimizar campos do protocolo PPP aps estabelecida a conexo,
evitando-se o envio de campos desnecessrios;
ADDRESS AND CONTROL FIELD COMPRESSION: para esta opo tambm
foi previsto tratamento, sendo aceito quando requerido, pois tem como objetivo
reduzir o envio da campos desnecessrios aps a conexo estar estabelecida;
CALLBACK: esta opo no aceita sendo rejeitada;
MULTLINK MRRU: este parmetro negociado para atender a limitao de
memria do prottipo, sendo solicitado o valor de 128 bytes, valores maiores que
este so rejeitados;
52
MULTLINK ENDPOINT DISCRIMINATOR: no h tratamento para esta opo,
sendo a mesma rejeitada caso ocorra.
Qualquer outra opo diferente das que foram implementadas so automaticamente
rejeitadas.
6.3.3 Otimizao na negociao IPCP
Atravs deste protocolo so estabelecidas as regras que permitem configurar o IP para
que este possa estar disponvel para receber e enviar dados para a Internet, sua especificao
est descrita em RFC1332 e RFC1877. O tratamento para estas opes foi necessrio para que
a mquina de estados do Windows atingisse os estgios seguintes, sendo sua implementao
obrigatria.
Esta implementao incluiu tratamento para as seguintes opes:
IP ADDRESS: o tratamento para este parmetro necessrio pois atravs desta
opo que informado o endereo que a estao dever assumir;
PRIMARY DNS ADDRESS: o tratamento para esta opo foi implementado por
exigncia da conexo solicitada pelo Windows, que necessita desta informao
para enviar suas solicitaes de resoluo de nomes;
PRYMARY NBNS ADDRESS: mantido tratamento pelo mesmo motivo,
necessidade de compatibilidade, visando atender as exigncias da mquina de
estados do Windows;
SECONDARY DNS ADDRESS: mantido tratamento pelo mesmo motivo;
SECONDARY NBNS ADDRESS: mantido tratamento pelo mesmo motivo.
O tratamento para estes casos ocorre de forma a fornecer dados estticos previamente
armazenados, no significando algum tipo de processamento especial quando de sua
negociao durante as fases de conexo.
6.3.4 Otimizando a negociao com CCP
Este protocolo utilizado para negociar os parmetros que determinaro como o
protocolo IP dever ser tratado, envolvendo, em certos casos, grandes limitaes de
implementao em virtude da opo escolhida, que pode envolver tratamentos no suportados
por um sistema onde busca-se otimizao. Alguns destes parmetros envolvem compresso de
dados, o que foge do escopo desta implementao, que visa proporcionar uma interface com
recursos otimizados.
A rejeio das opes existentes neste protocolo no compromete o objetivo que
colocar o Windows no estado conectado, apenas faz com que o protocolo passe a trafegar sem
usar este recurso. Sua implementao teria de utilizar algoritmos mais elaborados e
complexos, utilizando regras que tornariam sua descompresso excessivamente onerosa.
6.4 IMPLEMENTAO DO PROTOCOLO IP
Vencidas as barreiras no tratamento do quadro PPP, este trar em sua rea de dados as
informaes que aps extradas, podero ser identificadas como pertencentes ao protocolo IP.
Para isto h uma padronizao de codificao que especifica o tipo de protocolo que est
53
sendo transportado na rea de dados do protocolo. Esta codificao esta especificada em
RFC1700 (POINT-TO-POINT PROTOCOL FIELD ASSIGNMENTS).
Conforme visto anteriormente, no item 6.3, o campo Protocol informa o protocolo que
est sendo transportado, portanto na implementao basta verificar se o cdigo corresponde
ao esperado para o IP, que 0x0021, ou de forma compactada, 0x21.
Sendo o protocolo transportado reconhecido o processamento desviado para a rotina
que faz sua extrao e verificao de integridade.
O algoritmo utilizado para realizao da soma de verificao encontra-se disponvel
junto documentao de especificao do protocolo, no caso do IP, trata-se da RFC791.
O algoritmo genrico implementado para realizar o tratamento de quadros no estado
conectado segue a lgica demostrada na Figura 20. Assim que detectado um quadro vlido, ou
seja, foi identificado o flag de incio e fim, a execuo passa para o ponto onde realizada a
extrao dos caracteres de escape do quadro recebido. Este procedimento aplicado em
ambientes de comunicao serial que utilizam MODEMs para serem interligados. Os
MODEMs interceptam certos caracteres que so utilizados como caracteres de controle, assim
estes caracteres so alterados para que no sejam tratados pelo MODEM. Segundo a
especificao do protocolo PPP a regra a ser seguida a seguinte:
se caracter menor que 0x20: insere caracter de escape 0x7D mais o resultado da
operao do caracter XOR 0x20, no lugar do caracter;
se caracter igual a 0x7D: insere caracter de escape 0x7D mais o caracter 0x5D,
correspondente a operao 0x7D XOR 0x20, no lugar do caracter;
se caracter igual a 0x7E: insere caracter de escape 0x7D mais o caracter 0x5E,
correspondente a operao 0x7E XOR 0x20, no lugar do caracter.
A operao sobre os caracteres 0x7D e 0x7E so necessrias para evitar que caracteres
de dados sejam tratados como caracteres de escape, o que ocasionaria tratamento incorreto
para os dados recebidos.
Aps a extrao dos caracteres de escape, os dados estaro prontos para serem
confrontados com a soma de verificao para teste de integridade. No caso do quadro PPP a
soma de verificao abrange todos os bytes exceto os flags e os bytes do campo FCS. Se
ocorrer falha da soma de verificao o quadro descartado silenciosamente.
O prximo passo verificar qual o protocolo est sendo transportado, para que ocorra
o desvio ao tratamento adequado dos dados recebidos. Caso o protocolo no tenha tratamento
este descartado sem nenhuma notificao.
Para o protocolo IP haver mais algumas consistncias a serem realizadas antes de
disponibilizar seus dados para tratamento. A primeira a ser realizada a soma de verificao
do datagrama IP, o qual engloba somente o cabealho, sem incluir a rea de dados. O
algoritmo para realizao desta soma encontra-se disponvel junto a documentao de
referncia do protocolo, em RFC791. O passo seguinte verificar se o campo de endereo IP
destino o endereo do mdulo. Do mesmo modo que os tratamentos anteriores, caso algum
destes testes no sejam vlidos o tratamento cancelado, no sendo realizado nenhum tipo de
notificao.
54
switch ( ESTADO ) {
MODEM: //trata strings do modem
break;
CONECTADO:
if ( FRAME ) {
//extrai caracteres de escape
...
//calcula soma de verificao
...
if ( FRAME != VALIDO ) {
//descarta silenciosamente
...
}
else {
switch ( PROTOCOLO ) {
case LCP:
...
case IPCP:
...
case PAP:
...
case CCP:
...
case IP:
...
}
}
}
}
Figura 20 Algoritmo de tratamento para quadros
Cabe ressaltar que o tratamento do cabealho IP esta restrito aos campos necessrios
para esta implementao, portanto no esto sendo implementados todos os tratamentos que o
protocolo permitiria, tais como fragmentao de dados, tratamento de dados urgentes e outros
servios que implementam o tipo de transporte desejado para o datagrama.
6.4.1 Extraindo dados do datagrama IP
Os dados recebidos em um datagrama IP vlido devem ser tratados conforme o campo
Protocol, o qual especifica o tipo de protocolo que o mesmo esta transportando em sua rea
de dados. O tratamento realizado de acordo com a lista a seguir, conforme documentado em
RFC790:
0x01: protocolo ICMP;
0x06: protocolo TCP;
0x11: protocolo UDP.
Caso seja identificado o protocolo ICMP o fluxo desviado para o cdigo que realiza
o tratamento especfico deste protocolo. Esta implementao incluiu o tratamento para as
seguintes opes previstas no protocolo ICMP:
ECHO REQUEST: mensagem requisitando retorno de resposta para a origem da
mensagem;
ECHO REPLY: atendimento de pedido de resposta para origem.
Este protocolo torna possvel a utilizao de aplicativo para detectar se uma
determinada estao ou servidor encontra-se ativo. Este recurso simples mas de grande
utilidade permite identificar se determinado IP pode ser atingido ou no, atravs do envio de
uma mensagem utilizando o protocolo ICMP.
55
Esta implementao optou por incluir este recurso para que fosse possvel diagnosticar
de forma simples o funcionamento do mdulo prottipo.
6.4.2 Tratamento de mensagem UDP
Um pacote UDP detectado quando o datagrama IP contiver em seu campo de
cabealho Protocol o cdigo 0x11. Neste ponto inicia-se mais uma etapa de verificao de
integridade de dados e verificao de porta destino da mensagem. A soma de verificao
realizada utilizando-se o mesmo algoritmo empregado na verificao do datagrama IP. Os
seguintes campos so utilizados nesta soma:
soma em complemento de um do cabealho UDP mais seus dados;
soma em complemento de um de pseudocabealho montado no momento da
verificao, contendo os seguintes dados: 4 bytes do IP da origem, 4 bytes do IP
do destino, 1 byte com zero, 1 byte com o cdigo do protocolo, no caso 0x11 e 2
bytes com o tamanho do pacote UDP.
A implementao deste teste garante que somente pacotes vlidos sejam tratados. O
protocolo UDP permite que esta verificao no seja executada, nos casos em que o tempo de
processamento na validao de pacotes ocasione degradao de desempenho. Em certas
aplicaes, dados invlidos no causam prejuzo ao processamento da informao, onde o
fluxo deve prioritariamente ser mantido contnuo, tais como transmisso de vdeo
conferncias e sinais de udio.
Antes de dar prosseguimento ao tratamento dos dados transportados no pacote UDP,
deve-se verificar o campo destination port, no cabealho UDP, a fim de confirmar que se
tratam de dados destinados a porta que o mdulo prottipo esta ouvindo.
Para efeito de demonstrao de funcionamento, foi implementado no mdulo
prottipo, uma resposta automtica para datagramas que sejam enviados a este. Assim para
todo o datagrama que chegar haver uma resposta que envia uma seqncia fixa de dados,
indicando que os dados foram recebidos e que o fluxo de envio foi implementado. Os dados
recebidos so mostrados no display grfico por alguns instantes a fim de facilitar o
reconhecimento dos mesmos e confirmar seu recebimento de forma adequada.
6.4.3 Tratamento de mensagem TCP
Este sem dvida o objetivo principal deste projeto, permitir que um sistema
microprocessado manipule pacotes TCP/IP de forma a permitir sua interao com a Internet e
assim permitir sua integrao a rede mundial de comunicao.
O protocolo TCP em conjunto com o IP so os protocolos que sustentam as principais
funcionalidades atendidas neste meio de comunicao: a garantia de entrega e o servio de
entrega sem conexo.
Ao detectar a presena de um pacote TCP a ser tratado, a execuo desviada para o
fluxo adequado. Neste ponto inicia-se algumas verificaes de integridade e porta destino das
informaes.
A soma de verificao do datagrama TCP envolve a soma em complemento de um de
todos os dados do datagrama em unidades de 16 bits de tamanho. Se o datagrama contiver
numero de bytes impar, um byte deve ser acrescentado para efeito de soma com o contedo
56
zero, mas no deve ser enviado com o datagrama. Esta soma tambm inclui a montagem de
um pseudodatagrama que inclui os seguintes dados:
4 bytes com o endereo IP da origem;
4 bytes com o endereo IP do destino;
1 byte com valor zero;
1 byte com o cdigo do protocolo, no caso, 0x06;
2 bytes com a tamanho do datagrama TCP.
Estes dados so montados em tempo de execuo e realizado a soma, com o mesmo
algoritmo utilizado para a soma do cabealho. Para efeito de clculo o contedo do valor do
campo contendo a soma de verificao recebida deve ser salvo em uma varivel auxiliar e este
campo deve ser zerado.
Aps realizado a soma de verificao faz-se o teste da porta para qual os dados esto
sendo enviados, se corresponde a porta do prottipo. Caso algum destes testes falhem, o
tratamento interrompido e os dados so descartados silenciosamente.
A partir deste ponto o tratamento passa a ser realizado em funo da mquina de
estados especificada para o protocolo TCP. Assim, o primeiro passo verificar o estado atual
em que se encontra a mquina local, e a partir deste estado tomar a iniciativa adequada com
relao ao pacote que esta sendo tratado.
Conforme citado anteriormente, no item 6.2, em funo das limitaes impostas pelo
ambiente de teste, o prottipo foi projetado para funcionar como um ambiente servidor de
conexes. Este passou a esperar a iniciativa externa de conexo para que sua mquina de
estados fosse movimentada.
Seu funcionamento ativado com a abertura de um socket passivo, o qual fica apto a
receber conexes externas para uma determinada porta. Este socket entra no estado LISTEN,
a espera de uma conexo.
A mquina de estados para esta implementao sofreu uma simplificao, visando
atender a necessidade de reduo em seu tamanho e em virtude do tipo de tratamento de
dados para qual se destina. No sendo necessrio a implementao total da mquina de
estados prevista na literatura sobre o assunto. Alguns estados transitrios foram eliminados a
fim de simplificar sua implementao, sem no entanto restringir suas funcionalidades.
Os estados que foram implementados so:
LISTEN: este o estado inicial que a mquina assume sempre ao dar inicio ou ao
concluir uma conexo;
SYNRCVD: ao receber uma solicitao de conexo, partindo do estado LISTEN,
passa para este estado, aguardando a confirmao ao receber um pacote contendo
o flag ACK ligado;
ESTABLISHED: estado conectado, apto a receber e enviar dados;
CLOSEWAIT: ao receber uma solicitao de encerramento, flag FIN ligado,
passa para este estado antes de encerrar a conexo.
6.4.3.1 Implementao de temporizadores
A implementao de temporizadores no causou problemas, em virtude das limitaes
da unidade de processamento, que tem seu tempo compartilhado entre muitas outras
atividades. O otimizao da mquina de estados e a capacidade de recuperao tornaram
57
desnecessria a implementao de muitos tipos distintos de temporizadores, visando
estabelecer limites para estados especficos. Como a mquina de estados implementada
movimentada por iniciativa externa, caso esta fique em um estado invlido em relao a uma
iniciativa externa, ao dar-se incio ao processo novamente, este tornar a ser reiniciado.
Somente dois temporizadores foram implementados, um que utilizado como
temporizador de uso geral na mquina de estados TCP e outro para controle de descarte de
quadros no recebidos completos aps certo tempo.
6.4.3.2 Dando partida mquina de estados TCP
Alguns procedimentos so tomados quando se d incio o processo de conexo virtual
realizado pela mquina de estados TCP. O processo se inicia com a criao da estrutura que
armazenar as informaes que identificao a conexo em andamento chamada TCB, e
parmetros que especificam o estado da conexo. Alguns destes parmetros so:
porta origem: identifica a porta que est conectando-se ao sistema;
sequence number: identifica qual o primeiro byte do fluxo local;
acknowledgment number: identifica qual o prximo byte do fluxo remoto
esperado;
estado da conexo: identifica qual o estado da conexo.
Estes dados servem para manipular a conexo ativa e indicar mutuamente qual posio
do fluxo de dados foram recebidas corretamente.
O tratamento para sequence number e acknowledgment number deve ser dado como se
existisse um fluxo de dados percorrendo ambas as direes, cada um incrementado de
acordo com o recebimento e confirmao de recebimento de dados. Esta a tcnica que o
TCP utiliza para garantir que os dados sejam entregues ao destino.
H ainda mais um parmetro, que nesta implementao foi deixado com valor fixo.
Trata-se do valor da janela de dados, que informa o espao disponvel para receber dados.
Esta implementao no necessita recorrer a esta tcnica para controle de fluxo, pois no foi
planejado implement-la. Este recurso utilizado em ambientes de maior capacidade de
processamento, onde sistemas multitarefas podem ter um processo tratando dados recebidos
enquanto outro captura novos que esto chegando, sendo necessrio, nestes casos, administrar
a capacidade remanescente do buffer de recepo.
6.4.3.3 Estruturas de dados
A implementao dos protocolos e o tratamento destes contou com o uso de estruturas
de dados, normalmente utilizadas como tipos em ponteiros, tendo em vista que sua
manipulao no esttica. Estas estruturas representam os dados definidos na especificao
dos protocolos e estruturas auxiliares, utilizadas na verificao de somas de segurana.
A estrutura mostrada na Figura 21 representa os dados que so manipulados quando
um datagrama IP tratado. Os dados esto todos no formato char.
58
typedef struct {
unsigned char Versao_Len;
unsigned char Service;
unsigned char TotalLen[2];
unsigned char ID[2];
unsigned char FragmDesloc[2];
unsigned char TTL;
unsigned char Protocol;
unsigned char CheckSum[2];
unsigned char SourceIP[4];
unsigned char DestinIP[4];
unsigned char dados;
} DatagramaIP;
Figura 21 Estrutura de dados do datagrama IP
A incluso da campo dados no faz parte da definio do cabealho do datagrama IP,
mas foi criado por permitir uma forma mais simples de obter-se o endereo da rea de dados
que deve ser tratado pelo protocolo que esta sendo transportado pelo IP.
Para manipulao de dados numricos, como o campo CheckSum[2], foi criado uma
estrutura conforme mostrado na Figura 22. Esta estrutura permite representar no mesmo
espao de memria dois tipos diferentes de dados, de forma que seja visto como um nmero
de dois bytes e ao mesmo tempo pode ser visto como uma seqncia de caracteres. Este
formato facilita sua manipulao, pois permite tratar os dados como um nmero quando isto
necessrio e realizar a transferncia como bytes contnuos.
union NUMBER2 {
unsigned int numw;
unsigned char numc[2];
};
Figura 22 Estrutura para manipulao de dados numricos de 2 bytes
Para manipulao de dados com tamanho de 4 bytes foi criado a estrutura mostrada na
Figura 23. Esta estrutura permite manipular o campos utilizados na estrutura do protocolo
TCP.
Union NUMBER4 {
unsigned long seqn;
unsigned char seqc[4];
};
Figura 23 Estrutura para manipulao de dados numricos de 4 bytes
A estrutura do protocolo TCP mostrada na Figura 24.
typedef struct {
unsigned char SourcePort[2];
unsigned char DestinPort[2];
unsigned char SequenceNum[4];
unsigned char AckNumber[4];
unsigned char ControlBits[2];
unsigned char Window[2];
unsigned char CheckSum[2];
unsigned char UrgentPointer[2];
unsigned char Options[4];
unsigned char Dados[128];
} DatagramaTCP;
Figura 24 Estrutura de dados do datagrama TCP
59
A estrutura de dados do protocolo TCP, mostrado no Figura 24, contm dados
numricos de 4 bytes, que devem ser manipulados a cada pacote recebido e transmitido pelo
protocolo TCP. Estes campos so SequenceNum[4] e AckNumber[4]. Sua manipulao foi
simplificada utilizando-se e estrutura auxiliar que permite representar os dados como nmero
de 4 bytes e seqncia de caracteres.
Na estrutura mostrada na Figura 25, esto os dados utilizados na montagem para o
clculo da soma de verificao dos pacotes TCP. Esta estrutura manipulada somente no
momento do tratamento dos dados, no sendo enviada junto ao pacote.
typedef struct {
unsigned char SourceIP[4];
unsigned char DestinIP[4];
unsigned char zero;
unsigned char protocolo;
unsigned char TCPLen[2];
} PseudoHeaderTCP;
Figura 25 Estrutura auxiliar usada para clculo de soma de verificao TCP
Esta mesma estrutura, mostrada na Figura 25, tambm utilizada para clculo da soma
de verificao do protocolo UDP.
6.5 PORTANDO O CDIGO PARA O DESTINO
Aps implementao da lgica de funcionamento dos protocolos no ambiente 32 bits,
este foi portado para o ambiente final para o qual foi desenvolvido, ou seja, um
microcontrolador de 8 bits, descrito no captulo 5. No ambiente destino j haviam sido
implementados os recursos necessrios para o gerenciamento do hardware e controle de
interrupes.
Este ambiente conta um grupo de funes de gerenciamento responsveis pelo
controle de inicializao dos recursos, rotinas de acesso a display grfico e controle da porta
de comunicao serial RS-232, a qual seria utilizada para conexo com um microcomputador.
Inicialmente a lgica desenvolvida estava encarregada de detectar os flags de incio e
fim de um quadro PPP. Esta implementao funcionou corretamente no ambiente de
desenvolvimento durante os testes, mas demonstrou fragilidade no ambiente final, como
ficou comprovado nos primeiros testes realizados. Ocorre que no ambiente de
desenvolvimento tinha-se um sistema trabalhando com um processador infinitamente mais
veloz que o prottipo a ser utilizado. Este realizava as verificaes necessrias nos dados
recebidos muitas vezes mais rpido que o hardware de comunicao serial podia atualizar,
desta forma conseguia detectar a presena de um quadro e desviar o processamento para o
tratamento enquanto um novo quadro podia estar sendo recebido e mantido armazenado pelo
sistema operacional.
Esta lgica se mostrou ineficaz no ambiente microprocessado, ocasionando lentido e
falta de sincronismo para detectar a presena de dados adequadamente. Alm da restrio
verificada com respeito a capacidade de processamento o buffer de armazenamento de dados
para este ambiente estava limitado em 128 bytes. Na implementao original, no ambiente de
desenvolvimento, utilizou-se uma lgica que permitia a movimentao de um ponteiro
indicador de dados o qual era passado para a rotina de comunicao, assim esta podia
continuar a recepo de novos dados a partir deste ponto do buffer, enquanto no fosse
60
detectado a presena de um quadro completo. Esta lgica tambm detectava a presena de um
quadro incompleto que estivesse presente aps um quadro j completo. Neste caso os dados
quando eram transferidos para o buffer de trabalho, tambm era realizado o deslocamento dos
dados remanescentes para o incio da rea de dados, a fim de facilitar a deteco de incio e
fim de um quadro, permitindo que a recepo continua-se aps estes.
A soluo encontrada foi simplificar a forma de manipular os dados recebidos e
detectar a presena dos flags de incio e fim de quadro de uma forma mais eficiente e
adequada aos recursos computacionais existentes.
O tratamento de envio e recebimento de dados pela porta de comunicao serial RS-
232 realizada via rotina de interrupo, assim que inicializado o sistema, este ativa a
recepo que tem um vetor de interrupo fixo para tratamento de comunicao serial. Neste
vetor esto implementados os procedimentos de armazenamento dos dados que chegam e
demais controles necessrios para a correta recepo de dados.
O mtodo empregado para otimizar o processo de recepo e detectar a presena de
um quadro PPP no buffer de recepo foi utilizar a prpria rotina de interrupo para indicar
esta situao. O algoritmo empregado segue a lgica descrita no fluxograma representado na
Figura 26. Partindo-se do princpio que houve a chegada de um byte pela interface de
comunicao serial e a rotina de tratamento foi invocada, h o seguinte processamento:
1. Coloca byte recebido no buffer.
2. o primeiro byte recebido e um flag ? Se sim, ento indica incio de quadro,
inicializa relgio de recepo e indicao de nmero de bytes recebido igual a
zero.
3. Se no: Verifica se o nmero de bytes recebido maior que 2 e se trata de um
flag; Se sim, indica final de quadro e desabilita a recepo de novos dados.
4. Se no: Verifica se o nmero de bytes recebidos igual a 1 e trata-se de um flag;
Se sim, faz ponteiro de buffer apontar para o incio, faz quantidade de bytes
recebidas igual a zero, tira indicao de incio e final de quadro e reinicia relgio
de recepo.
5. O ponteiro de dados no atingiu o final do buffer ? Se no, incrementa ponteiro de
uma unidade.
Com esta lgica implementada, a deteco de um quadro foi simplificada, sendo que a
rotina responsvel pelo tratamento PPP somente invocada quando h a presena de um
quadro completo na rea de dados. O processamento fica destinado a aplicao que esta sendo
executada e a rotina que monitora os indicadores de incio e fim de quadro. Um aspecto
relevante nesta implementao a ordem em que os testes so realizados, para que o impacto
no tratamento, desta interrupo, seja o menor possvel, evitando-se testes desnecessrios.
Para isto procurou-se dispor a ordem na seqncia que privilegia a execuo sem falhas, que
se estima seja a execuo mais freqente e assim tornar o tratamento da interrupo mais
eficiente.
Outra medida tomada foi o bloqueio da recepo de novos dados enquanto no
finalizar o tratamento dos dados recm chegados. Esta medida reduziu a manipulao de
ponteiros e ampliou a permanncia do processamento dedicado ao tratamento dos dados
recebidos, pois no h novas interrupes geradas pela chegada de novos dados.
Como pode ser visto na descrio dos protocolos, estes exigem uma srie de
consistncias e verificaes que tornam seu processamento demorado. Em alguns casos pode
ocorrer de o transmissor reenviar seu dados em virtude da demora na resposta, isto traria uma
degradao de desempenho, pois, continuaria ativa a gerao de interrupo para tratamento
61
de dados recebidos, assim, bloqueando a recepo de novos dados, mesmo que haja nova
recepo, antes da concluso do tratamento dos dados recebidos anteriormente, estes no
influenciaro o processamento em andamento e ao termino deste, os dados esperados sero
enviados ao destino.
Figura 26 Fluxograma de tratamento de recepo
Isto no pode ser visto como uma limitao, mas sim como uma adequao
capacidade de processamento para o dispositivo em desenvolvimento, afinal os protocolos
foram desenvolvidos com este propsito, o de se adaptarem aos mais diversos dispositivos e
meios de comunicao utilizando-se de temporizadores, retransmisso e tcnicas de
validao.
6.5.1 Ferramentas utilizadas
Para auxiliar o desenvolvimento durante a fase de testes, foram utilizadas algumas
ferramentas que tornaram esta tarefa mais simples. O objetivo era comprovar a operao em
conformidade com as especificaes que estavam sendo implementadas.
62
A ferramenta ComLite32 (ComLit32.exe, http://www.rtcomm.com) foi utilizada
para captura dos dados que trafegavam entre a porta de comunicao do computador e o
prottipo. Esta ferramenta permite visualizar, em tempo real, os dados que estavam sendo
trocados na porta de comunicao. Sua utilizao permitiu acompanhar o desenvolvimento
durante a fase de implementao do protocolo PPP, que interage diretamente com o
hardware, adequando os dados recebidos dos nveis superiores com a interface de
comunicao serial.
A ferramenta Analyzer (Analyzer.exe, http://www.polito.it) foi utilizada para
capturar os dados que so trocados no nvel de rede. Esta aplicao um pacote analisador de
protocolos, que permite sua visualizao em alto nvel, permitindo navegar sobre os
protocolos capturados e desta forma facilitar a verificao de operao.
6.6 VERIFICAO DE FUNCIONAMENTO
Os testes de funcionamento foram permanentes durante todas as fases do
desenvolvimento. Mas um bom projeto deve sempre contar com meios de comprovar sua
operao em conformidade com o que foi planejado. Para tornar isto possvel, durante o
desenvolvimento foram concebidos meios para que testes prticos pudessem ser realizados. O
prottipo conta com uma interface grfica (LCD), que permite acompanhar a apresentao de
mensagens. Este recurso foi utilizado de forma a permitir que a troca de mensagens realizada
entre uma estao e o prottipo pudessem ser acompanhadas.
Os recursos implementados no projeto permitem atender s seguintes caractersticas:
tratamento para quadros com encapsulamento PPP (RFC1661);
tratamento para protocolos de negociao de conexo CCP, IPCP, LCP e PAP;
tratamento para datagramas com encapsulamento IPv4 (RFC791);
tratamento para pacotes UDP (RFC768);
tratamento para pacotes ICMP (RFC792);
tratamento para pacotes TCP (RFC793, RFC1180).
Os protocolos descritos foram implementados de forma otimizada, objetivando
manter-se a compatibilidade com suas especificaes, eliminado tratamentos que no trariam
contribuio para seu uso neste tipo de ambiente microprocessado.
6.6.1 Tipos de testes
A verificao de operao das funcionalidades implementadas foi realizada utilizando-
se de um microcomputador interligado ao prottipo via porta de comunicao serial. O
prottipo implementado se comporta como um servidor.
Os seguintes teste foram realizados:
atravs de uma aplicao 32 bits, utilizou-se a criao de um socket, usando o
protocolo TCP, permitindo a troca de mensagens com o prottipo;
atravs de uma aplicao 32 bits, utilizou-se a criao de um socket, usando o
protocolo UDP, e do mesmo modo, permitindo a troca de mensagens com o
prottipo;
utilizao do programa ping.exe, permitindo que mensagens ICMP fossem
trocadas com o mdulo prottipo;
63
os procedimentos acima do incio ao processo de conexo discada que permite
testar o funcionamento da implementao que trata o protocolo PPP e os demais
protocolos utilizados durante a negociao da conexo.
Estas ferramentas comerciais de largo uso, permitem comprovar a operao do
prottipo e sua compatibilidade, visto que se utilizam bibliotecas de uso habitual neste tipo de
sistema operacional de 32 bits.
6.6.1.1 Teste de conexo TCP
Durante os testes realizados na verificao de funcionamento do protocolo TCP, os
dados trocados foram capturados com o auxlio das ferramentas descritas. Na figura 27,
capturada com o auxlio da ferramenta Analyzer.exe, podemos observar que houve a
troca de 9 pacotes. O primeiro iniciou s 21:31:08.498266, pacote nmero 2. Este primeiro
pacote partiu do microcomputador conectado ao prottipo e trazia a indicao de solicitao
de conexo com a porta destino, no caso 43055. Logo a seguir o prottipo devolve um pacote
indicando aceitar a solicitao de conexo, o pacote nmero 3. O pacote seguinte contm a
resposta de confirmao, contendo um ACK. Neste momento a mquina de estados TCP do
prottipo passa para o estado conectado. A partir deste ponto notamos que enviado 3
pacotes partindo do microcomputador, pacotes 5, 6 e 7. Isto se deve por motivo de
desempenho no processamento da informao recebida pelo prottipo. No primeiro pacote
enviado por este, no haviam dados para serem manipulados, permitindo que a resposta fosse
dada mais rapidamente.
Figura 27 Captura de testes de conexo TCP
64
Foram trs pacotes enviados, o primeiro que foi recebido deu incio ao processamento
da informao, ou seja, o prottipo recebeu e passou a tratar os dados, neste momento houve a
chegada de mais dois pacotes, os quais no foram tratados, pois o prottipo estava com a
recepo de dados bloqueada enquanto no conclua o tratamento corrente. Este procedimento
foi tomado para assegurar que no ocorressem novas interrupes durante o tratamento de
uma informao, o que implicaria de degradao do tempo de resposta.
No pacote de nmero 8 o prottipo devolve a resposta esperada. Os pacotes seguintes
so: um contendo o flag de confirmao de recebimento (ACK) e outro encerrando a conexo
com o flag RESET ligado.
7 CONCLUSO
Este trabalho implementou os protocolos que so utilizados para conexo Internet
em um prottipo utilizando um microprocessador de 8 bits. Foram implementados os
protocolos TCP, UDP, IP e ICMP, tornando o prottipo utilizado plenamente funcional e apto
para conectar-se na Internet. Este recurso permitiu que houvesse interao via troca de dados,
possibilitando controlar o prottipo remotamente.
Os protocolos foram amplamente estudados a fim de buscar atendimento de requisitos
de compatibilidade e otimizao, objetivando reduzir o comprometimento no uso de recursos,
tornando sua utilizao vivel em sistema de reduzida capacidade computacional.
O projeto de implementao foi dividido em duas fases. A primeira fase foi da
construo da lgica de implementao dos protocolos em um ambiente multitarefa, contando
com ferramentas visuais para a codificao e depurao dos protocolos. A implementao foi
realizada utilizando-se a linguagem C ANSI, com a preocupao de tornar o cdigo portvel
para o ambiente final. Nesta fase foi possvel implementar a lgica de funcionamento dos
protocolos e efetuar os testes e comprovao de funcionamento. A Segunda fase foi realizada
quando o cdigo dos protocolos estavam prontos e testados. Foi necessrio portar a
codificao construda no ambiente de desenvolvimento para o sistema utilizado para
compilar o projeto para o sistema microprocessado do prottipo. Algumas adaptaes tiveram
se ser realizadas, tais como: o acesso aos recursos de comunicao serial e ordenao de
dados em estruturas em virtude do tipo de processador.
O acesso aos recursos de comunicao disponibilizados em forma de biblioteca, foram
simplificados na forma de algumas funes que permitem reduzir o nmero de parmetros
necessrios ao seu uso.
Em testes realizados no prottipo implementado foi possvel comprovar o
funcionamento pleno do projeto. Demonstrou-se com isto, a viabilidade de uso de sistemas
microprocessados de pequeno porte para conexo com a Internet, permitindo ampliar sua
utilizao sem comprometer o funcionamento em um sistema microprocessado.
A implementao realizada comprova que os protocolos implementados podem
atender necessidades variadas com flexibilidade, tornando possvel o uso de dispositivos
simples e direcionados para atender necessidades especficas, tais como: sistemas dedicados
utilizados em ambientes industriais, sistemas de monitorao, aquisio de dados, dispositivos
de pagamento eletrnicos, etc.
Novas perspectivas se abrem e possibilidades de aprimoramento do projeto realizado.
Ampliar os recursos dispondo de um servio de pginas HTTP seria um recurso possvel de
implementao. Desta forma uma aplicao sendo executada em um navegador Internet,
66
poderia acessar recursos e informaes disponibilizados pelo mdulo, permitindo interao
com este. Incluir um mdulo para controle de discagem utilizando um MODEM, ampliaria
sua gama de aplicaes. Este recurso essencial em sistemas remotos com conexo discada.
REFERNCIAS
COMER, Douglas E.; STEVENS, David. Interligao em Rede TCP/IP Volume I. Rio de
Janeiro: Campus, 1999. 672 p.
COMER, Douglas E.; STEVENS, David. Interligao em Rede TCP/IP Volume II. Rio
de Janeiro: Campus, 1999. 592 p.
DUNKELS, Adam. Minimal TCP/IP Implementation with Proxy Support. 2001.
Disponvel em: <http://www.sics.se/~adam/publications.html>. Acessado em: 22 Ago. 2001.
IREN, Sami; AMER, Paul D. The Transport Layer: Tutorial and Survey. Philadelphia,
1999. Disponvel em: <http://citeseer.nj.nec.com/iren99transport.html>. Acessado em: 1 Out.
2001.
JORDAM, Larry; CHURCHILL, Bruce. Comunicao e Redes com o PC-5 ed. Rio de
Janeiro: Axcel Books, 1994. 698 p.
NUNES, L. TELEPROCESSAMENTO. [s/l]: [s/e], 1998. 60 f. Apostila da disciplina
Teleprocessamento.
MAGUIRE, Steve. Guia Microsoft para O Desenvolvimento de Programas Sem Erros.
Rio de Janeiro: Campus, 1994. 249 p.
PETERS, James F.; PEDRYCZ, Witold. Engenharia de Software. Rio de Janeiro: Campus,
2001. 602 p.
RFC1180. A TCP/IP Tutorial. 1991. Disponvel em: <http://www.rfc.net/rfc1180.txt>.
Acessado em: 1 Out. 2001.
RFC791. INTERNET PROTOCOL. 1981. Disponvel em: <http://www.rfc.net/rfc791.txt>.
Acessado em: 1 Out. 2001.
RFC793. TRANSMISSION CONTROL PROTOCOL. 1981. Disponvel em:
<http://www.rfc.net/rfc793.txt>. Acessado em: 1 Out. 2001.
RFC790. ASSIGNED NUMBERS. 1981. Disponvel em: <http://www.rfc.net/rfc790.txt>.
Acessado em: 1 Out. 2001.
RFC768. USER DATAGRAM PROTOCOL. 1980. Disponvel em:
<http://www.rfc.net/rfc768.txt>. Acessado em: 1 Out. 2001.
RFC792. INTERNET CONTROL MESSAGE PROTOCOL. 1981. Disponvel em:
<http://www.rfc.net/rfc792.txt>. Acessado em: 1 Out. 2001.
RFC1332. INTERNET PROTOCOL CONTROL PROTOCOL. 1992. Disponvel em:
<http://www.ietf.org/rfc/rfc1332.txt>. Acessado em: 6 Nov. 2002.
68
RFC1334. PPP ATHENTICATION PROTOCOL. 1992. Disponvel em:
<http://www.ietf.org/rfc/rfc1334.txt>. Acessado em: 6 Nov. 2002.
RFC1661. POINT-TO-POINT PROTOCOL. 1994. Disponvel em:
<http://www.ietf.org/rfc/rfc1661.txt>. Acessado em: 6 Nov. 2002.
RFC1662. PPP in HDLC-LIKE FRAMING. 1994. Disponvel em:
<http://www.ietf.org/rfc/rfc1662.txt>. Acessado em: 6 Nov. 2002.
RFC1700. ASSIGNED NUMBERS. 1994. Disponvel em:
<http://www.ietf.org/rfc/rfc1700.txt>. Acessado em: 6 Nov. 2002.
RFC1877. PPP INTERNET PROTOCOL CONTROL PROTOCOL EXTENSION for
NAME SERVER ADDRESS. 1995. Disponvel em: <http://www.ietf.org/rfc/rfc1877.txt>.
Acessado em: 6 Nov. 2002.