Você está na página 1de 47

1 Introduo

Os termos interoperabilidade e interconectividade so bastante usados


hoje em dia, e muitos ainda apontam que estas duas palavras sero essenciais
no que se refere a computao dos anos 90, mas por qu?
A interconectividade refere-se a ligao fsica a ser estabelecida entre
as partes que necessitam efetuar a comunicao, ou melhor, preocupa-se com
as caractersticas fsicas, eltricas e mecnicas envolvidas neste processo de
interligao.
J o termo interoperabilidade, aponta para a capacidade de haver
troca de informaes entre as aplicaes que esto sendo processadas nos
computadores, e que estas informaes possam ser utilizadas para se atingir
objetivos comuns, como o trabalho cooperativo, integridade, segurana dos
dados e independncia de equipamentos.
Para se usufruir a interconectividade e interoperabilidade torna-se
necessrio a adoo de padres, coisas estas que at anteriormente no
existiam, prova disso que os fabricantes de hardware e desenvolvedores de
software desenvolveram cada um o seu prprio conjunto de regras.
em meio a este cenrio que surge a necessidade de interligao de
hardware e interoperao entre software. E por isso que os termos
interconectividade e interoperabilidade sero palavras chaves nos anos 90,
pois existe uma real necessidade de interligar todo este aparato tecnolgico
existente e fazer com que seja realmente produtivo.
Com esta viso, os fabricantes e desenvolvedores j procuram trabalhar
seguindo padres sugeridos por rgos internacionais como ISO, IEEE entre
outros, atingindo assim, neste momento, um certo grau de interoperabilidade e
interconectividade.
claro que a interoperabilidade total est muito distante de ser
conseguida. Para se atingir isto haveria a necessidade de que todos os
fabricantes e desenvolvedores adotassem um mesmo padro para seu
hardware e software, ou ento desenvolver algum produto que consiga
comunicar-se
com
todos
os
padres
existentes.

2 Arquiteturas de redes

Uma grande variedade de arquiteturas de redes podem ser encontradas


no mercado atualmente, e esta variedade acaba por tornar a interoperabilidade
entre as aplicaes mais difcil, visto que existem dificuldades no
relacionamento entre elas.
Este estudo faz um levantamento de algumas das arquiteturas mais
populares, buscando levantar os pontos comuns entre as mesmas, a fim de se
obter subsdios para se atingir a interoperabilidade e interconectividade.

2.1 O modelo OSI - Open System Interconnection

Em 1977, o comit tcnico 97 da ISO (International Organization for


Standardization), reconheceu a necessidade de padres para redes de
informaes heterogneas, e decidiu criar um novo subcomit (SC16) para
estudar este problema e apresentar solues para a interconexo dos mesmos
([TARO86], [ZIMM80], [REAR88] e [FOLT82]).
No final do estudo, chegou-se a um modelo denominado OSI (Open
Systems Interconnection), que deveria garantir uma estrutura para a definio,
desenvolvimento e validao de padres na nova gerao de sistemas de
informaes distribudas. O trabalho foi direcionado para definir a
funcionalidade necessria comunicao entre processos de aplicaes
localizadas remotamente em diferentes sistemas heterogneos [FOLT82].
O propsito deste modelo de referncia propor base comum para a
coordenao da padronizao do desenvolvimento de todo e qualquer produto
para a interconexo de sistemas de informao sem interferir no funcionamento
interno do sistema individual [ALVE92]. Tarouco [TARO86] tambm apresenta
que o modelo de referncia OSI foi criado com vistas a servir de base para a
definio de projetos de padronizao da interconexo de sistemas abertos. A
interconexo de sistemas abertos implica na conexo, por algum meio, de

sistemas compreendendo computadores,


operadores humanos e processos fsicos.

seus

perifricos,

terminais,

O termo sistema deve ser entendido, como sendo um conjunto de um


ou mais computadores, o software associado, seus perifricos, terminais,
operadores humanos, processos fsicos, meios de transferncia de informao
etc, que formam um todo capaz de executar processamento e/ou transferncia
de informao.
J o termo aberto (open), foi escolhido para enfatizar o fato de que, de
acordo com os padres internacionais, um sistema deveria ser aberto para
todos os outros sistemas, obedecendo os mesmos padres estabelecidos pelo
mundo. J Folts [FOLT82], apresenta que o termo aberto usado para
assegurar a habilidade de um sistema de um fabricante (ou projeto),
interconectar-se com um outro sistema de outro fabricante, de acordo com o
modelo de referncia OSI.
Quanto a estrutura do modelo de referncia OSI, a mesma
apresentada em 7 (sete) camadas hierrquicas ou nveis. Sua estruturao
pode ser vista na figura 2.1.

APLICAO
APRESENTAO
SESSO
TRANSPORTE
REDE
ENLACE
FSICO
Figura 2.1 - O modelo de referncia OSI.
Esta tcnica de estruturao permite que a rede de sistemas abertos
possa ser vista como uma composio lgica de sucessivos nveis, cada um
envolvendo o nvel abaixo e isolando-o dos nveis superiores.

A idia bsica de estruturar em camadas a de que, cada nvel fornea


informaes para os servios oferecidos pelos nveis inferiores assim como os
nveis superiores oferecem um conjunto de servios para executar aplicaes
distribudas.
Um nvel pode ser visto individualmente, conforme figura 2.2, como um
nvel (N) tendo um nvel (N+1) acima (nvel superior) e um nvel (n-1) abaixo
(nvel inferior). O nvel (N) recebe servios do nvel (N-1) e fornece servios ao
nvel (N+1).
Cada nvel contm um grupo lgico de funes que fornecem os
servios especficos para facilitar a comunicao. O grupo de funes de um
nvel cria uma unidade funcional que chamada de entidade. Uma entidade
aceita uma ou mais entradas (argumentos) e produz determinadas sadas
(valores) dependendo da natureza das funes que executa. L podem ter
duas ou mais instncias de entidades ativas dentro de cada nvel executando
as funes para o suporte da comunicao.
Existem tambm interaes entre entidades de nveis adjacentes, na
forma de requisies, indicaes, respostas e confirmaes, estas so
chamadas de primitivas. Cada primitiva pode tambm ter parmetros
associados que transportam o controle da informao necessria para suportar
a comunicao.
NVEL (N+1)

NVEL (N)

NVEL (N-1)
A: Servios do Nvel

NVEL
ENTIDADE

B
B: Prim itivas / Parm etros

Figura 2.2 - Conceito de um nvel no modelo OSI.

Existe uma entidade ativa, para cada nvel, em cada sistema envolvido
na interconexo. Entidades de um mesmo nvel se comunicam com outra
usando um protocolo exclusivo ao seu nvel que transporta o controle da
informao necessria para suportar a comunicao entre as aplicaes
cooperantes.
As informaes so trocadas entre as entidades de mesmo nvel,
atravs da utilizao de servios do nvel (N-1), que fornece uma conexo
lgica entre a entidade de nvel (N). Em contrapartida, cada nvel utiliza os
servios do nvel inferior, que so refletidos como servios (N-1), conforme
figura 2.3.

ENTIDADE
(N)

PROTOCOLO PARA
O NVEL (N)

ENTIDADE
(N)

NVEL (N)
NVEL(N-1)
CONEXO (N-1)

Figura 2.3 - Conexo (N-1).


As primitivas tambm iniciam uma ao ou levam ao resultado de uma
ao, conforme figura 2.4.
SERVIO USURIO

SERVIO FORNECIDO

SERVIO USURIO

REQUEST

INDICATION

CONFIRMATION

Figura 2.4 - Interao entre primitivas.

RESPONSE

As primitivas so:
Request - iniciada do nvel (N+1) para o nvel (N) para ativar um
servio particular.
Indication - fornecido pelo nvel (N) para levar a ativao de um
servio particular.
Response - fornecido pelo nvel (N+1) em resposta para uma
primitiva INDICATION.
Confirm - retornada para o nvel (N+1) requisitante pelo nvel (N)
sobre o servio solicitado.
Os trs nveis superiores fornecem as funes para suporte direto dos
processos de aplicaes, enquanto que os trs nveis inferiores interessam-se
com a transmisso de informao entre os sistemas-fins. O nvel de transporte
a ligao essencial destes dois grupos de funes, ele fornece integridade
fim-a-fim da comunicao, garantindo a qualidade apropriada do servio dos
trs nveis inferiores e os requisitos dos trs nveis superiores [FOLT82].
Apesar do modelo de referncia OSI ter sido apontado como a chave
para a interconexo de sistemas heterogneos, alguns autores apontam certas
necessidades no conseguidas pelo modelo.
Svobodova [SVOB90] aponta, que apesar do modelo de referncia OSI
ter sido concebido para prover uma soluo unificada para a interconexo e
interoperabilidade entre sistemas e redes desenvolvidas por diferentes
fabricantes existem alguns pontos no atingidos. Para Svobodova, o problema
da interoperabilidade global ainda no foi solucionado. Esta situao um
resultado de diversos fatores, mas o grande problema complicador a grande
heterogeneidade dos ambientes endereados pelos padres. Continua
mostrando que, em redes de computadores, heterogeneidade mostra trs
nveis bsicos e que nem todos so abrangidos pelo modelo OSI. Os trs
nveis so os seguintes:
Hardware e software que formam os sistemas a serem
interconectados;

Meio fsico e protocolos das subredes aos quais os diferentes


sistemas sero interconectados;
Protocolos de alto nvel usados para a comunicao fim-a-fim
entre os sistemas.
Conclui, apontando que a heterogeneidade de sistemas e redes no
causada somente pela incluso de mecanismos apropriados dentro do modelo
OSI, mas tambm pelo aparecimento de diferentes tipos de servios e
protocolos para um simples nvel.

2.2 A arquitetura TCP/IP - Transport Control Protocol / Internet


Protocol

Em 1973, a Agncia de Projetos de Pesquisa Avanada para Defesa


(Defense Advanced Research Projects Agency - DARPA), decidiu pela
necessidade de novos protocolos host-to-host na ARPANET. Estes novos
protocolos deveriam suportar diferentes tcnicas de comunicao. As novas
implementaes foram completadas em 1974. Em 1978, aps quatro anos de
testes e refinamentos, o Departamento de Defesa norte-americano
(Departament of Defense - DoD) promulgou verses de TCP/IP (Transmission
Control Protocol/Internet Protocol) e obrigou o seu uso como padro do DoD.
Os protocolos Internet, como mais conhecida a arquitetura TCP/IP,
so projetados para redes de pacotes, que fornecem a entrega confivel de
mensagens ou notificaes de falhas. Este modelo conduz ao uso de, no
mnimo, dois nveis de protocolo. O primeiro nvel opera de forma fim-a-fim
entre os dois hosts envolvidos em uma conversao. O segundo nvel
baseado em um protocolo de baixo nvel que trabalha na forma de passaradiante a mensagem, fazendo com que a mensagem percorra uma srie de
elementos intermedirios at chegar ao destino [LEFF88].
O TCP/IP tambm pode ser dividido em camadas, assim como o modelo
de referncia OSI, porm alguns autores trazem formas diferentes de
representao. A seguir, na figura 2.5, est a viso de Leffler.
APLICAO
TCP

UDP
IP

ICMP

INTERFACE DE REDE

Figura 2.5 - Estruturao em camadas do TCP/IP segundo [LEFF88].


Ainda segundo Leffler, o Protocolo Internet ou IP como conhecido,
um protocolo de baixo nvel e cabe a este elemento enviar a mensagem do
host origem, atravs de elementos intermedirios, para o host destino. Este
nvel corresponde ao Nvel de Rede do modelo OSI. O IP deve fornecer

servios a nvel de rede para o endereamento do host, roteamento, e se


necessrio, fragmentao e montagem dos pacotes, caso a rede no consiga
enviar a informao em um nico pacote.
O Transmission Control Protocol (TCP) e o User Datagram Protocol
(UDP) so protocolos do nvel de transporte que fornecem facilidades
adicionais ao IP. No caso do TCP, este fornece confiana, no duplicao e
fluxo de transmisso controlado. J o UDP oferece um mecanismo para
checar a integridade dos dados. Para finalizar, o Internet Control Message
Protocol (ICMP) usado para relatar erros e outras tarefas de gerenciamento
da rede, este no utilizado pelo usurio.
Os protocolos Internet so projetados para suportar sistemas e
arquiteturas heterogneas. Sistemas que usam uma variedade muito grande de
representao interna de dados. Mesmo a unidade bsica de dados, o byte,
no e o mesmo para todos os sistemas. Os protocolos de rede, no entanto,
requerem uma representao padro, esta representao obtida atravs de
octetos, um byte de oito bits.
Conforme citado anteriormente outros autores representam de forma
diferente as camadas do TCP/IP. [CHRI91] e [COME88] representam a
estrutura do TCP/IP como mostrada na figura 2.6.
A P L IC A O
TCP
IP
ARP
UDP
IN T E R F A C E D E R E D E

Figura 2.6 - Estruturao em camadas do TCP/IP segundo [CHRI91] e


[COME88].
Nesta nova representao, surge mais um elemento, o ARP (Address
Resolution Problem), que permite a um host encontrar um endereo fsico de
um host destino na mesma rede fsica, tendo somente o endereo Internet do
destino.

Um sistema de comunicao dito com suporte de servios de


comunicao universal se permitir que qualquer host possa se comunicar com
qualquer outro host. Para se estabelecer este sistema de comunicao
universal, necessrio estabelecer um mtodo de identificao de
computadores aceito globalmente [COME88].
Partindo desta premissa, o endereo dos host Internet um nmero de
32 bits (4 octetos), que identifica a rede em que o host est localizado e o
prprio host naquela rede. O endereo da rede atribudo por uma agncia
central e o endereo do host na rede atribudo pelo administrador da rede.
possvel que um host esteja ligado a vrias redes, isto implica que ele possuir
mltiplos endereos.
Cada host conhecido por um nmero da ARPANET IMP em cada rede
em que estiver conectado e por um nmero de porto naquele IMP (Interface
Message Processor). O IMP e os endereos do host ocupam um octeto do
endereo. Um dos dois octetos restantes usado para designar a rede e o
outro fica disponvel para ser usado como identificador de conexo
multiplexada.
Existem tambm algumas classes de endereos, como mostrado na
figura 2.7, que so determinadas pelos bits mais significativos. As classes so
definidas como sendo A, B e C, com os bits mais significativos assumindo 0, 10
e 110 respectivamente e usam 8, 16 e 24 bits respectivamente, para a parte de
endereo da rede.
REDE

IM P

HO S T

HO S T

L G ICO
ENDEREO ARPANET
0

REDE

HO S T

8 BIT S

24 BIT S

E N D E R E O CL A S S E A
REDE

16 BIT S

10

HO S T

16 BIT S

E N D E R E O CL A S S E B

110

REDE

HO S T

24 BIT S

8 BIT S

E N D E R E O CL A S S E C

Figura 2.7 - Classes de endereos.

Cada classe tem menos bits para a parte relativa ao endereo do host e
assim suporta menos hosts que a classe mais alta. Esta forma de codificao
suporta um grande nmero de redes de tamanhos variados, e mantendo ainda
a compatibilidade com o antigo cdigo de endereos da ARPANET, porm, a
popularidade atingida pela rede Internet est levando os seus administradores
a buscarem novas alternativas de endereamento.
A popularidade atingida pelo TCP/IP deve-se a cinco caractersticas
essenciais que a DARPA identificou como objetivos do projeto [SPAN88]:
Confiabilidade - certamente a mais importante caracterstica do
TCP/IP. O IP, como projetado, no se responsabiliza pela
confiabilidade dos dados entregues, ele simplesmente garante a
entrega para a rede apropriada. O TCP quem fornece a
confiabilidade, atravs do mtodo full duplex e comunicao
orientada a conexo entre os processos cooperantes.
Interoperabilidade - esta refere-se a habilidade de sistemas de
computadores
diferentes
comunicarem-se
entre
si.
A
interoperabilidade conseguida com trs utilitrios: FTP (File
Transfer Protocol), TELNET (servio de terminal virtual) e SMTP
(Simple Mail Transport Protocol). Estes utilitrios definem a interface
entre o software do usurio com o software dos nveis de transporte
e de rede que permite diferentes implementaes tornarem-se
compatveis.
Segurana - o IP inclui diversos campos dentro do cabealho que
permitem uma proteo seletiva da informao. No momento do
estabelecimento da conexo, as entidades devem concordar com os
nveis de segurana das informaes associada para a conexo.
Flexibilidade e habilidade para permitir a transio entre
protocolos - o uso do TCP/IP no impe regras quanto a meios ou
aplicaes para o uso. Quando o TCP/IP requer certas coisas de
outros protocolos, ele utiliza primitivas que permitem a combinao.
Isso se deve ao fato do TCP/IP ser heterogneo por natureza,
garantindo a migrao para outros protocolos.

2.3 A arquitetura SNA - System Network Architecture

SNA (System Network Architecture) uma arquitetura complexa e


sofisticada da IBM que define procedimentos e estrutura de comunicaes de
entrada e sada de um programa de aplicao e a tela de um terminal, ou ainda
entre dois programas de aplicao. SNA consiste em um conjunto de
protocolos, formatos e sequncias operacionais que controlam o fluxo de
informao dentro de uma rede de comunicao de dados ligada a um
mainframe IBM, micro computadores, controladoras de comunicao e
terminais.
A arquitetura SNA implementa um relacionamento hierrquico, tambm
chamado de mestre-escravo, o que implica em que um participante de uma
interao deve buscar permisso de um outro participante antes da interao
ser iniciada. Redes seguindo este modelo, so menos flexveis para
estabelecer relacionamentos entre entidades arbitrrias, mas so mais
controlveis pelo gerente da rede [DEIT90].
Conforme o histrico relatado em [MEIJ88], a arquitetura SNA foi
anunciada em 1974, porm sofreu diversas alteraes at ser o que hoje. No
incio era muito limitada quanto a abrangncia e funes, mas fornecia os
mecanismos bsicos necessrios para o projeto de sistemas de comunicao.
As primeiras verses ficaram conhecidas como SNA 0 e 1 e fornecia
apenas funes limitadas. O maior propsito era o de possuir uma arquitetura
bem estruturada basicamente era constituda de um computador central (host),
um ou mais controladores de canais de comunicao ligados ao host e alguns
controladores de cluster, ou seja, definia trs tipos de nodos:
.o nodo host;
.o nodo controlador de comunicao;
.o controlador de cluster.
Na verso seguinte, SNA 2 tambm em 1974, algumas melhorias
significativas foram introduzidas, tais como:

.ligao local de controladores de cluster;


.controladores de comunicao remota;
.mais um tipo nodo (Terminal);
.suporte ao chaveamento de linhas de comunicao.
Porm estas melhorias no ampliaram o escopo da arquitetura. Isto s
ocorreu com a verso, SNA 3 - 1976, tambm conhecida por Funes de
Comunicao Avanada (SNA/ACF - Advanced Communications Functions).
Nesta verso eram permitidos que vrios hosts fossem interligados atravs do
controlador de comunicao local.
A verso SNA 4 - 1979, removia algumas restries que existiam nas
verses anteriores. Uma importante melhoria do ponto de vista arquitetural foi a
introduo de sesses paralelas entre hosts.
Em 1982, foi anunciado um produto chamado de Comunicao
Avanada de Programa a Programa (APPN - Advanced Program to Program
Communication), e em 1983 foi anunciado um outro produto que garantiria a
interligao de redes SNA independentes atravs de um gateway.
Assim uma rede SNA passou a consistir em um ou mais domnios, onde
um domnio se refere a todos os componentes fsicos e lgicos que esto
conectados e so controlados por um ponto comum da rede. Este ponto
comum de controle chamado de SSCP (System Services Control Point). So
trs os tipos de unidades endereveis da rede (NAU - Network Address Unit)
[ALVE92]:
.SSCP (System Services Control Point);
.PU (Physical Units);
.LU (Logical Units).

O SSCP consiste em um mtodo de acesso de comunicao operando


em um mainframe IBM. Ele contm as tabelas de endereamento da rede,
tabelas de roteamento e tabelas de traduo, que so empregadas para
estabelecer conexes entre os ns da rede e controlar o fluxo de informao.
Cada domnio contm um ou mais ns, consistindo a rede SNA em um
agrupamento de componentes de rede. Exemplos de ns SNA incluem os
controladores de cluster, controladores de comunicaes e terminais, com o
endereo de cada dispositivo na rede.
Cada n SNA contm uma unidade fsica (PU), que controla os outros
recursos contidos neste n. A unidade fsica (PU) no um dispositivo fsico,
mas um conjunto de componentes que fornece servios usados para controlar
recursos como terminais, controladoras, processadores e linhas. Ou ainda, as
unidades fsicas so representaes de dispositivos e linhas de comunicao
da rede [TILL90].
J o ltimo tipo de unidade enderevel da rede a unidade lgica
(LU), esta serve como ponto de acesso para que os usurios possam utilizar a
rede. Cada unidade fsica (PU) pode ter uma ou mais unidades lgicas, onde
cada unidade lgica tem um endereo distinto.
Existem os seguintes tipos de unidades fsicas:
.terminais;
.controladores de cluster;
.processadores front-end (FEP);
.hosts.
Sendo que os terminais e os controladores de cluster so considerados
nodos perifricos, que so aqueles que se comunicam apenas com os nodos
subreas em que esto conectados. E os processadores front-end e os hosts
so tipos de nodos subreas, ou seja, alm de se comunicarem com seus
prprios perifricos, possuem habilidade para se comunicarem com outros
nodos subreas da rede.

Com respeito a estabelecimento de sesses, [KONA83] e [ALVE92],


colocam que uma sesso na arquitetura SNA pode ser definida como a
conexo lgica entre duas unidades endereveis da rede para troca de
informao entre estas. As funes necessrias para o estabelecimento e
gerenciamento destas sesses esto contidas nos vrios nveis da arquitetura
da rede.
Assim como nas arquiteturas anteriores, SNA tambm dividida em
camadas, alguns autores diferem quanto a sua representao hierrquica. Isto
pode ser comprovado comparando a figura 2.9, que traz as vises de [SY 87]
e [TILL90], com a figura 2.10, que mostra a viso de [KONA83].
SERVIO TRANSAO
SERVIO APRESENTAO
CONTROLE FLUXO DADOS

USURIO FINAL
SERVIO APRESENTAO
CONTROLE FLUXO DADOS

CONTROLE TRANSMISSO

CONTROLE TRANSMISSO

CONTROLE PATH

CONTROLE PATH

CONTROLE LIGAO
CONTROLE FSICO
Figura 2.9 - Representao do modelo
SNA por [SY87] e [TILL90]

CONTROLE LIGAO
Figura 2.10 - Representao do modelo
SNA por [KONA83]

2.4 A arquitetura XNS - Xerox Network Services

A Xerox Network Services uma arquitetura de rede desenvolvida pela


Xerox Corporation em meados de 1970. Seu objetivo, na poca, era interligar
os escritrios da companhia ao sistema de computadores.
XNS um sistema aberto, podendo ser encontrado hardware e software
que o suportam em diversos ambientes e plataformas operacionais. Sua
operao similar a do TCP/IP, tanto na estruturao quanto nos servios
oferecidos, como servios orientados conexo ou no, por exemplo.
Uma comparao entre a estruturao de camadas da arquitetura XNS
com o modelo de referncia ISO-OSI pode ser visto na figura 2.11. Nesta
representao, so apresentados vrios componentes que compem o nvel de
transporte da XNS, porm, interessante observar que, no so todos os
componentes que trocam informaes com os processos de usurios, isto
porque alguns componentes (ECHO, RIP e ERROR) neste nvel que exercem
funes prprias para manter o protocolo funcional.

APLICAO
APRESENTAO

Processos de Usurios

SESSO
TRANSPORTE
REDE

ECHO

RIP

PEX

SPP

ERROR

IDP

ENLACE
FSICO

Interface Hardware

Figura 2.11 - Estrutura da arquitetura XNS em comparao com o modelo ISOOSI.

Cada um dos componentes que compe a arquitetura XNS possui


funes especficas, as quais so interessantes conhecer. So elas:

ECHO - Echo Protocol - um protocolo que permite ao equipamento


host transmitir o pacote que acabou de receber.
RIP - Routing Information Protocol - um protocolo usado para manter
uma base de dados sobre roteamento que serve ao host para enviar os
pacotes IDP para outros hosts.
PEX - Packet Exchange Protocol - um protocolo no orientado
conexes, que disponibiliza o uso de datagramas para os processos de
usurios.
SPP - Sequenced Packet Protocol - um protocolo orientado conexo,
que permite uma confiabilidade maior que o PEX na entrega da
informao, isto devido a alguns mecanismos de controle que possui.
ERROR - Error Protocol - o protocolo responsvel pela descoberta dos
erros ocorridos na comunicao.
IDP - Internet Datagram Protocol - um protocolo no orientado
conexo, que disponibiliza um servio de entrega de pacotes para todos
os protocolos do nvel superior.
Tanto o SPP quanto o PEX so protocolos a nvel de transporte
disponibilizado na arquitetura XNS; a diferena entre ambos reside no fato de
que o SPP oferece um servio orientado conexo com troca de informaes
entre as partes envolvidas na comunicao de maneira confivel e full-duplex.
J o PEX disponibiliza um servio no orientado conexo, com as referidas
conseqncias deste tipo de servio, ou seja, no segurana da entrega das
informaes e falta de confiabilidade nos dados.
A representao 2.12 mostra a interao entre os processos de usurios
com os protocolos do nvel de transporte, bem como a comunicao do
processo de usurio diretamente com o IDP, visto que possvel.
O modelo XNS foi muito bem aceito pelos usurios e desenvolvedores,
tanto que modelos alternativos foram desenvolvidos tomando como referncia
o modelo XNS, o caso do SPX/IPX da Novell, que apresentado a seguir.

Para maiores informaes a respeito da arquitetura XNS, consultar


[STEV90].
Processo de
U surio

Processo de
U surio

SP P

Processo de
U surio

PEX

(Transporte)

(Transporte)

ID P

Interface
H ardware

Figura 2.12 - A comunicao entre processos de usurios e componentes de


transporte XNS.

2.5
A
arquitetura
SPX/IPX
Exchange/Internet Packet Exchange

Sequenced

Packet

SPX/IPX (Sequenced Packet eXchange/Internet Packet eXchange) o


protocolo de comunicao desenvolvido pela Novell para suas redes Netware.
Ele um subconjunto da arquitetura Xerox Network Services (XNS [STEV90]).
SPX/IPX similar arquitetura TCP/IP em termos de funcionalidade e
compatibilidade com os nveis do modelo ISO-OSI. A respeito desta
compatibilidade, o IPX corresponde ao protocolo de rede e o SPX ao de
transporte, como mostra a representao 2.13.

APLICAO
APRESENTAO
SESSO
SPX

TRANSPORTE

IPX

REDE
ENLACE
FSICO

Figura 2.13 - Comparao da arquitetura SPX/IPX com a arquitetura ISO-OSI.


A arquitetura em questo permite utilizar-se dos servios orientados e
no orientados conexo, sendo que o primeiro realizado por intermdio do
SPX, que garante a entrega da informao, monitorando as transmisses e
retransmitindo se os respectivos reconhecimentos no retornarem; e o
segundo servio realizado pelo IPX, que tm como funo enderear e rotear
os pacotes aos seus destinos.
A maneira como ambos atuam apresentada na figura 2.14. No caso do
SPX, o processo do usurio envia e recebe informaes diretamente deste
nvel (A), e este transfere as mensagens, depois de devidamente
seqncializadas, para o nvel inferior (B), no caso o IPX. O simples fato de

utilizar-se das funes disponibilizadas pelo SPX, com seus respectivos


parmetros, garante aplicao estar utilizando o servio orientado conexo.
E caso o desenvolvedor necessite utilizar os servios no orientados a
conexo, dever implementar em sua aplicao as funes que fazem acesso
direto ao IPX (C). Porm, neste caso, a aplicao ficar encarregada de efetuar
todo o controle para garantir a confiabilidade da informao, um vez que o IPX
apenas um entregador de mensagens, no realizando controles sobre as
mesmas.
P ro cess o d e
U s u rio
A
C

SPX
B
IP X

Figura 2.14 - Fluxo da informao entre processo de usurio, SPX e IPX.


Uma aplicao no fica restrita apenas a uma conexo ou ligao
externa, um mesmo processo pode estar com conexes abertas com n outros
processos, ou ainda despachando informaes para todos os usurios de uma
rede. Esta flexibilidade pode ser vista na representao 2.15, onde um nico
processo cliente pode estar se comunicando com um processo servidor
qualquer atravs do SPX e mantendo contato com outros processos clientes
atravs do IPX.
Como nas outras arquiteturas, o SPX/IPX disponibiliza algumas funes
para que os desenvolvedores de aplicaes possam utilizar seus servios. A
tabela 2.3 mostra estas funes, bem como seus parmetros.
As funes fazem referncia a uma estrutura de bloco de controle de
eventos (ECB - Event Control Block), a estrutura de dados mais importante
do protocolo, visto que armazena endereos, buffers de recepo e
transmisso, alm de informaes sobre a conexo local e remota.

Processo
Cliente

SPX

Processo
Cliente

SPX
IPX

Processo
Cliente

SPX
IPX

IPX

IPX
SPX
Processo
Servidor

Figura 2.15 - Comunicao entre processos clientes e servidor.

2.6 Equivalncia de servios entre as arquiteturas OSI, TCP/IP e


SPX/IPX

Com base nas funes e chamadas levantadas nos itens anteriores,


pde-se apontar para certas equivalncias entre os servios oferecidos pelas
arquiteturas OSI, TCP/IP e SPX/IPX.

Sobre os tipos de servios, fica evidenciado que as trs arquiteturas de


redes aqui mencionadas fornecem servios orientados e no orientados
conexo. Algumas de maneira mais simples e outras nem tanto.

Comparaes entre as chamadas das arquiteturas podem ser vistas


nesta e nas pginas que seguem.

ISO-OSI para TCP/IP

ISO-OSI

TCP/IP

T_CONNECT_REQUEST

ACTIVE OPEN

T_CONNECT_INDICATION

sem equivalncia

T_CONECT_RESPONSE

ACTIVE OPEN

T_CONNECT_CONFIRMATION

OPEN ID, OPEN SUCCESS

T_DATA_REQUEST

SEND sem URGENT FLAG

T_DATA_INDICATION

RECEIVE sem URGENT FLAG

T_EXPEDITED_DATA_REQUEST

SEND com URGENT FLAG

T_EXPEDITED_DATA_INDICATION

RECEIVE com URGENT FLAG

T_DISCONNECT_REQUEST

ABORT

T_DISCONNECT_INDICATION

CLOSE, TERMINATE

Tabela 2.4 - Equivalncia do modelo ISO-OSI para TCP/IP.

ISO-OSI para SPX/IPX

ISO-OSI

SPX/IPX

T_CONNECT_REQUEST
T_CONNECT_INDICATION
T_CONECT_RESPONSE
T_CONNECT_CONFIRMATION
T_DATA_REQUEST
T_DATA_INDICATION
T_EXPEDITED_DATA_REQUEST
T_EXPEDITED_DATA_INDICATION
T_DISCONNECT_REQUEST
T_DISCONNECT_INDICATION

SPXEstablishConnection
SPXEstablishConnection
sem equivalncia
sem equivalncia
SPXSendSequencedPacket
SPXListenForSequencedPacket
sem equivalncia
sem equivalncia
sem equivalncia
SPXTerminateConnection

Tabela 2.5 - Equivalncia do modelo ISO-OSI para SPX/IPX


TCP/IP para ISO-OSI

TCP/IP

ISO-OSI

PASSIVE OPEN
ACTIVE OPEN

sem equivalncia
T_CONNECT_REQUEST
T_CONNECT_RESPONSE
SEND sem URGENT FLAG
T_DATA_REQUEST
SEND com URGENT FLAG
T_EXPEDITED_DATA_REQUEST
ALLOCATE
sem equivalncia
CLOSE
T_DISCONNECT_INDICATION
ABORT
T_DISCONNECT_REQUEST
STATUS
sem equivalncia
OPEN ID
T_CONNECT_CONFIRMATION
OPEN FAILURE
T_DISCONNECT_INDICATION
OPEN SUCCESS
sem equivalncia
RECEIVE sem URGENT T_DATA_INDICATION
FLAG
RECEIVE com URGENT T_EXPEDITED_DATA_INDICATION
FLAG
CLOSING
sem equivalncia
TERMINATE
sem equivalncia
STATUS RESPONSE
sem equivalncia
ERROR
sem equivalncia
Tabela 2.6 - Equivalncia de TCP/IP para modelo ISO-OSI.

TCP/IP para SPX/IPX

TCP/IP
PASSIVE OPEN
ACTIVE OPEN
SEND sem URGENT FLAG
SEND com URGENT FLAG
ALLOCATE
CLOSE
ABORT
STATUS
OPEN ID
OPEN FAILURE
OPEN SUCCESS
RECEIVE sem URGENT
FLAG
RECEIVE com URGENT
FLAG
CLOSING
TERMINATE
STATUS RESPONSE
ERROR

SPX/IPX
SPXListenForConnection
SPXEstablishConnection
SPXSendSequencedPacket
sem equivalncia
SPXInitialize
SPXTerminateConnection
sem equivalncia
sem equivalncia
SPXOpenSocket
SPXOpenSocket
SPXOpenSocket
SPXListenForSequencedPacket
sem equivalncia
sem equivalncia
SPXTerminateConnection
sem equivalncia
sem equivalncia

Tabela 2.7 - Equivalncia de TCP/IP para SPX/IPX.


SPX/IPX para ISO-OSI

SPX/IPX
SPXEstablishConnection
SPXInitialize
SPXListenForConnection
SPXListenForSequencedPack
et
SPXSendSequencedPacket
SPXTerminateConnection
SPXCheckSocket
SPXOpenSocket

ISO-OSI
T_CONNECT_REQUEST
T_CONNECT_INDICATION
sem equivalncia
sem equivalncia
T_DATA_INDICATION
T_DATA_REQUEST
T_DISCONNECT_INDICATION
sem equivalncia
sem equivalncia

Tabela 2.8 - Equivalncia de SPX/IPX para modelo ISO-OSI

SPX/IPX para TCP/IP

SPX/IPX

TCP/IP

SPXEstablishConnection

ACTIVE OPEN

SPXInitialize

sem equivalncia

SPXListenForConnection

PASSIVE OPEN

SPXListenForSequencedPack
et

RECEIVE

SPXSendSequencedPacket

SEND

SPXTerminateConnection

TERMINATE
CLOSE

SPXCheckSocket

OPEN SUCCESS

SPXOpenSocket

OPEN SUCCESS

Tabela 2.9 - Equivalncia de SPX/IPX para TCP/IP.


interessante salientar que as equivalncias aqui levantadas so
relativas aos tipos de servios que as arquiteturas fornecem e no pela sua
forma de utilizao.

3 APIs - Applications Programs Interfaces

Assim como ocorre com as arquiteturas de redes, as APIs podem ser


encontradas em vrios tipos, de acordo com o tipo de sistema onde se esta
trabalhando.
A diversidade de tipos, formas de trabalho, alm da interao, acabam
por incidir diretamente na interoperabilidade entre as aplicaes, o que pode
levar uma aplicao atingir um alto ou baixo grau de interoperao.
Este captulo procura reunir algumas das APIs mais utilizadas, buscando
identificar caractersticas operacionais dos mesmos e detectar possveis casos
de interoperabilidade.

3.1 O mecanismo NetBIOS

Em 1984, a IBM elaborou sua primeira rede local, a IBM PC Network,


com o objetivo de interligar computadores pessoais, todos compartilhando um
mesmo meio fsico; e, projetou o NetBIOS para ser o controlador da mesma.
O termo NetBIOS derivado de Net (Network) e BIOS (Basic Input
Output System), sendo que todas as rotinas ficavam armazenadas dentro de
uma memria somente de leitura e esta, por sua vez, localizava-se na placa de
rede, chamada pela IBM como "placa adaptadora".
Atualmente, o NetBIOS pode ser encontrado sobre placas Ethernet e
Token Ring, podendo assim ser utilizado por uma maior quantia de usurios e
sistemas de redes, alm de no necessitar mais ser implementada em
hardware, podendo ser considerada como uma camada adicional de software.
Seguindo a linha de produtos compatveis, o NetBIOS mantm ligao
com o modelo de referncia ISO-OSI, como pode ser visto na figura 3.1. A
interface de servios NetBIOS pode ser encontrada englobando os nveis de
transporte e rede, ficando os nveis de aplicao, apresentao e sesso

abrangidos pelo processo do usurio e os nveis de enlace e fsico


correspondendo interface de hardware.
Quantos aos servios disponibilizados, podem ser encontrados os
servios de nomes, sesso (servio orientado conexo), datagramas (servio
no orientado conexo) e alguns comandos gerais. Existe um relacionamento
entre estes tipos de servios, que pode ser observado na figura 3.2.

APLICAO
APRESENTAO

Processo do Usurio

SESSO
TRANSPORTE

Interface NetBIOS

REDE
ENLACE
Interface de Hardware

FSICO

Figura 3.1 - Relacionamento do NetBIOS com o modelo OSI.

Processo do Usurio

NetBIOS

Servios de

Servios de

Servios de

Comandos

Sesso

Nomes

Datagrama

Gerais

Interface do Hardware

Figura 3.2 - Relacionamento entre servios NetBIOS.


O relacionamento no completo entre todos os servios, como pode
ser visto; os comandos gerais somente se relacionam com os processos dos

usurios e com a interface de hardware e o servio de nome serve como


centralizador dos servios de datagrama (no orientado conexo) e de
sesso (orientado conexo).
Servios de Nomes
Os nomes, no NetBIOS, so usados para identificar recursos e
processos, por exemplo, um processo cliente identifica um processo servidor
especfico por um nome do servidor e o servidor pode determinar para que
deve enviar as informaes atravs do nome do cliente.
Podem existir dois tipos de nomes; nico e grupo, sendo que o primeiro
identifica apenas um elemento na rede, j o segundo consiste em um conjunto
com vrios elementos da rede. Os comandos utilizados para manipular estes
nomes so aqueles apresentados na tabela 3.1.
ADD_NAME

Adiciona um nome nico

ADD_GROUP_NAME

Adiciona um nome de grupo

DELETE_NAME

Elimina um nome (nico ou de


grupo)

FIND_NAME

Encontra um nome, se existir

Tabela 3.1 - Comandos do servio de nomes.


Servios de Sesso
Estes servios fornecem ao NetBIOS servios orientados conexo,
com confiabilidade e com caractersticas full duplex. Os dados so
armazenados dentro de mensagens e cada mensagem pode ter entre 0 e
131.071 bytes. Seus comandos podem ser vistos na tabela 3.2.
Servios de datagrama
NetBIOS suporta servios no orientados conexo, com datagramas
de at 512 bytes, e como os demais equivalentes, no oferece garantias
quanto a confiabilidade dos dados transmitidos.
CALL

Solicita uma conexo - active open.

LISTEN

Aguarda solicitao de conexo - passive


open.

SEND

Envia dados da sesso.

SEND_NO_ACK

Envia dados da sesso sem reconhecimento.

RECEIVE

Recebe dados da sesso.

RECEIVE_ANY

Recebe dados da sesso vindos de qualquer


cliente.

HANG_UP

Encerra sesso.

SESSION_STATUS

Mostra status da sesso.

Tabela 3.2 - Comandos do servio de sesso.


Os datagramas podem ser enviados para um nome especfico (nico),
para grupos, ou ainda, para todos os nomes da rede. Os comandos usados
para trabalhar com esta modalidade so mostrados na tabela 3.3.
SEND_DATAGRAM

Envia datagramas.

SEND_BROADCAST_DATAGRAM

Envia datagramas na forma


broadcast.

RECEIVE_DATAGRAM

Recebe datagramas.

RECEIVE_BROADCAST_DATAGRAM

Recebe
datagramas
forma broadcast.

na

Tabela 3.3 - Comandos do servio de datagrama.


Comandos Gerais
So comandos que no se enquadram nas especificaes anteriores.
RESET

Reinicializa o NetBIOS.

CANCEL

Cancela um comando.

ADAPTER_STATUS

Busca o status da placa.

UNLINK

Elimina a ligao com o bootstrap do servidor


(para estaes diskless).
Tabela 3.4 - Comandos gerais.

O fato do NetBIOS no necessitar mais ser implementado no hardware


da rede faz com que ele volte a ser utilizado muito hoje em dia, principalmente
em aplicaes que trabalhem no esquema ponto-a-ponto.

3.2 O mecanismo RPC - Remote Procedure Call

Apesar da maioria dos sistemas possurem formas para a sua


interligao, eles no possuem um protocolo comum para isso; e at mesmo
cada subconjunto de sistemas que compartilham um mesmo protocolo, podem
ser substancialmente diferentes entre si quanto a sua utilizao. Sugere-se,
portanto, a utilizao da chamada remota de procedimento para suprir esta
falta de padronizao de protocolos [BERS87].
A chamada de procedimento uma maneira de se transferir o controle
de um processo para outro, com o retorno do controle ao processo chamador.
Associado a chamada de procedimento, encontra-se a passagem de
argumento de um processo cliente para o processo servidor. O procedimento
cliente e o servidor residem em processos separados com endereos prprios,
no permitindo o conceito de variveis globais como acontece em
procedimentos normais dentro de processos locais.
Processo

Processo

Comunic.
Local

Comunic.
Local
Comunicao

Processo

HOST B

Remota

Processo

HOST A

Figura 3.3 - Comunicao local e remota entre processos.


Em muitos sistemas, tanto o cliente como servidor esto dentro de um
mesmo processo em um determinado sistema e existe uma ligao lgica entre
eles. Esta modalidade de chamada recebe o nome de chamada local de
procedimento. Porm, se um processo de um determinado sistema solicita um
procedimento de um processo de outro sistema, d-se o nome de chamada
remota de procedimento ou RPC (Remote Procedure Call).

O objetivo principal das chamadas remotas de procedimento (RPC) o


de as tornarem to simples como as chamadas locais de procedimento. Para
tanto, alguns pontos devem ser levados em considerao, tais como:
Passagem de parmetros - A passagem de parmetros entre cliente e
servidor pode no ser transparente, visto que existem problemas para
se passar parmetros por referncia. A maioria dos autores sugerem a
passagem apenas de parmetros por valores.
Conexo (BINDING) - Consiste na conexo do sistema cliente com o
sistema remoto alvo para ter uma chamada remota executada. Ele deve
encontrar o sistema apropriado e o processo servidor naquele sistema.
Manipulao de erros - Com um procedimento local h um nmero
limitado de coisas que podem dar errado, porm ao utilizar sistemas
remotos, as possibilidade aumentam em muitas vezes, isto pelo fato dos
sistemas estarem fisicamente distantes e tornar-se um tanto complicado
recuperar-se de erros ocorridos.
Representao dos dados - Quando se utiliza uma chamada local,
tanto o cliente como o servidor esto executando em um mesmo
sistema, portanto, no existem problemas de compatibilidade de dados,
porm, isto pode no acontece quando se utiliza RPC, pois o cliente e o
servidor podem estar em arquiteturas distintas, e isso acarretar na
necessidade de converso dos dados.
Desempenho - Normalmente o desempenho da chamada remota
menor se comparada com a chamada local, porm RPC deve ser vista
como uma forma de utilizar procedimentos de outros sistemas e no
como uma sucessora das chamadas locais.

3.3 A interface Clean and Simple

A interface Clean and Simple - C & S - proposta em [COLE87], consiste


em um elemento projetado para ser uma interface de servios de transporte
universal, suportando os mais variados servios de transporte.
Esta interface compem-se, basicamente, por duas partes: a primeira
est baseada no equipamento cliente que necessitar mapear suas
solicitaes ou servios para um protocolo diferente daquele que possui em
seu equipamento; j a segunda parte reside nos equipamentos servidores figura 3.4, os quais disponibilizaro seus servios aos clientes .
Servidor TCP/IP

Rede A
Cliente

Sub Sistema de
Comunicao

Servidor OSI

Rede B
Cliente

Rede C
Cliente
Servidor SPX/IPX

Figura 3.4 - Representao da arquitetura utilizada pela interface C & S.


A maneira como a interface atua relativamente simples e pode ser
compreendida tomando como referncia a figura 3.5.
Seu funcionamento consiste em uma aplicao qualquer, desenvolvida
em um equipamento cliente, necessitar utilizar servios de um protocolo que

no o disponvel em seu equipamento, ou ento, ter acesso a uma rede que


utiliza um protocolo diferente daquele encontrado em seu ambiente.
A soluo proposta pela interface C & S consiste em identificar as partes
dependentes do protocolo desejado e alter-las, inserindo nas mesmas as
chamadas ou primitivas da interface C & S.
Aps esta alterao, executa-se a aplicao e, as chamadas
introduzidas redirecionam a parte dependente de protocolo para um mdulo da
interface residente no equipamento cliente, e este envia, na forma de
mensagem, a informao para o servidor daquele protocolo desejado e este
pode processar a solicitao ou transferir para uma outra rede.
A figura 3.5 demonstra o fluxo das aes descritas anteriormente.
Cliente

Servidor

Aplicao
Cliente

Mdulo
C&S
Cliente

Aplicao
Servidora

Sub Sistema de
Comunicao

Mdulo
C&S
Servidor

Figura 3.5 - Comunicao entre a aplicao cliente com a aplicao servidora.


A interface C & S implementa uma comunicao entre processos processo cliente e processo servidor, no caso - onde a parte dependente de
protocolo passada como uma mensagem entre os processos envolvidos na
comunicao. O protocolo que gerncia esta troca de informao recebe o
nome de IPCS (InterProcess Clean and Simple) [COLE87].
A representao 3.6 mostra como efetuada a troca de mensagens
utilizando as primitivas write e read como exemplos.

Cliente

IPCS
Write(parte_dep_protocol)

Read(parte_dep_protocol)

Servidor

Figura 3.6 - Representao do IPCS.


A interface C & S disponibiliza ao implementador uma variedade de
primitivas. Tais primitivas podem ser observadas na tabela 3.5.
Primitiva
s

Funes

getid

Retorna um handle que usado nas primitivas seguintes.


O handle pode ser usado para interromper as primitvas
open ou listen, caso seja necessrio.

open

Dado um endereo destino como parmetro, feita uma


tentativa para abrir uma chamada.

listen

Usa um endereo opcional, espera por uma requisio de


chamada.

read

Copia dados disponveis na entrada para o buffer do


usurio.

write

Envia dados de um buffer do usurio para a conexo.

close

Executa um encerramento controlado na conexo.

abort

Fecha imediatamente a conexo e inicializa todos os


recursos.

reset

Causa uma reinicializao na conexo.


Tabela 3.5 - Primitivas da interface C & S.

Caso o desenvolvedor ou usurio utilize esta interface para alterar sua


aplicao, este dever, de posse do cdigo-fonte da mesma, identificar todas
as partes dependentes de protocolo desejado e no disponibilizado no
equipamento e adicionar junto elas as respectivas primitivas oferecidas pela
interface C & S, a fim de garantir a comunicao com o servidor do protocolo
pretendido.

3.4 O mecanismo Socket

Sockets so mecanismos de comunicao entre processos


implementados no sistema UNIX 4.3BSD e que permite a comunicao entre
processos dentro de um mesmo domnio e tambm com processos em
execuo em sistemas remotos. Seu surgimento deu-se com o sistema
4.1cBSD em 1982 e ela vm sendo aprimorada com o aparecimento de novas
verses.
A interface socket fornece canais de comunicao full duplex e atua
como um elemento que recebe as chamadas vindas do processo do usurio e
transmite-as ao protocolo de comunicao e este, por sua vez, se encarrega de
despacha-la para os nveis inferiores - interface de rede e meio fsico - como
pode ser observado na figura 3.7.

Processo do Usurio

Interface de Chamadas do Sistema de


Sockets

Kernel

Protocolo de Comunicao
(TCP, UDP e outros)

Data Link Device Driver (Ethernet)

Figura 3.7 - Representao da Interface Socket em um sistema.


Na verdade, no existem conexes fsicas estabelecidas entre os pontos
que se comunicam, mas somente conexes virtuais, uma vez que os sockets

implementam pontos de conexes abstratos que apenas existem durante a


comunicao, ou seja, so criados e destrudos dinamicamente.
Sockets disponibilizam aos usurios seus servios atravs de chamadas
de sistema que devem ser adicionadas s aplicaes para que possam efetuar
a troca de informao com outros processos, locais ou remotos.
A interface sockets permite ao usurio desenvolver aplicaes que
utilizem os servios orientados conexo e no orientados conexo. Sendo
que o primeiro garante a confiabilidade e integridade dos dados enviados e o
segundo garante uma maior praticidade no envio.
Dependendo do tipo de servio desejado, deve-se utilizar certas
chamadas em detrimento de outras. As figuras 3.8 e 3.9 mostram como se
realiza a conversao entre os processos envolvidos, bem como as chamadas
que devem ser utilizadas.

Servidor

socket()
Cliente
bind()

socket()

recvfrom()

bind()

Bloqueado at receber
dados do cliente
Dados (Requisio)

sendto()

Requisio do
processo

sendto()

Dados (Resposta)

recvfrom()

Figura 3.8 - Sockets usando servio no orientado conexo.

Servidor
socket()

bind()

listen()

Cliente
accept()

socket()

Bloqueado at receber
conexo do cliente
Estabelecimento de Conexo

read()

connect()

Dados
(Requisio)

write()

Dados
(Resposta)

read()

Requisio do
processo

write()

Figura 3.9 - Sockets usando servio orientado conexo.


interessante complementar que socket abre uma real possibilidade de
se atingir a interoperabilidade entre aplicaes em ambientes distintos,
principalmente se as aplicaes envolvidas fizerem uso da arquitetura TCP/IP.
Os fatores que apontam para este sucesso so a ceitao das duas
tecnologias serem bem aceitas pela comunidade de desenvolvedores e
conseguirem facilmente interoperarem-se.
A facilidade da interoperao entre sockets e TCP/IP deve-se ao fato
deste ltimo implementar a tcnica de porto, que por sua vez utilizada pelos

sockets. Um mesmo porto consegue gerenciar mltiplos sockets e isso permite


que vrias aplicaes estabeleam conexes simultneas com o mesmo porto.
Davidson mostra, em [DAVI92], que alguns portos tm seus endereos,
ou nmeros, pr definidos e que um socket composto por um endereo IP e
um porto. Sendo assim, alguns servios bsicos podem estar associados a
determinados portos e quando a aplicao desejar fazer uso deles, basta
conectar-se ao respectivo porto. A figura abaixo mostra dois sockets
conectando-se a um porto TCP para se utilizarem do servio disponibilizado.
Socket
132.151.1.4,1055

C onexo
o

Servidor TELNET

o
o

Servidor TELNET

Socket
132.151.1.12,2111
Socket
132.151.11.1,23
(End. IP, porto)

Figura 3.10 - Sockets utilizando portos para conexo TCP/IP.


Na representao 3.10, pode-se observar que o porto 23 esta
gerenciando duas conexes, sendo que estas duas conexes esto fazendo
uso do servio de comunicao TELNET.
A facilidade de se estabelecer comunicao entre aplicaes que fazem
uso do socket e aplicaes que fazem uso do TCP/IP, abre grandes horizontes
para se atingir a interoperabilidade, visto que a aplicao socket, baseada em
TCP/IP pode interagir-se com qualquer aplicao que esteja utilizando TCP/IP,
independente do tipo de plataforma ou sistema operacional que se esteja
utilizando.
Maiores informaes sobre como implementar utilizando sockets podem
ser obtidas em [LEFF89] e [STEV90].

3.5 A biblioteca TLI - Transport Layer Interface

A TLI foi introduzida com a verso 3.0 do UNIX System V em 1986, com
a inteno de fornecer aos desenvolvedores uma interface a nvel de transporte
baseado no modelo ISO-OSI.
Consiste em um conjunto de funes e pode ser dividida em duas
partes, a biblioteca TLI e o mdulo TLI. A biblioteca TLI composta pelas
funes propriamente ditas, que so disponibilizadas aos usurios e
desenvolvedores, para que estes Incorporem-nas em suas aplicaes e o
mdulo TLI responsvel pela adequao das funes camada de transporte
disponvel no ambiente. Ela to flexvel que permite aos desenvolvedores
escrever aplicaes sem se preocuparem com o tipo de transporte que se est
utilizando [DAVI92].
interessante realar que a TLI, biblioteca e mdulo, no incorporam a
camada de transporte ao seu conjunto, sendo que este ltimo fica a cargo do
ambiente. Isto garante TLI uma flexibilidade muito grande, pois se um
desenvolvedor cria uma aplicao usando as funes da biblioteca em questo
sobre uma camada SPX, poder levar esta mesma aplicao para um
ambiente OSI ou TCP/IP sem ter que reescrever o cdigo, bastando recompilla no ambiente desejado.
Esta flexibilidade garantida pelo mdulo TLI que ao detectar uma
funo da biblioteca converte o formato da mensagem para o tipo de transporte
disponvel. Esta vantagem importantssima para se atingir a
interoperabilidade entre aplicaes.
A figura 3.11 traz o relacionamento da biblioteca TLI com o mdulo TLI,
juntamente com a aplicao e outras partes envolvidas no processo.
V-se no topo da estrutura o mdulo correspondente aplicao do
usurio incorporando a biblioteca TLI, uma vez que tal aplicao efetua
chamadas da referida biblioteca.
A seguir encontra-se stream head, que executa a converso do formato
da informao para uma forma entendida pelo nvel inferior (mdulo TLI).

Aplicao
Biblioteca TLI

Stream Head

Mdulo TLI

Mdulo Transporte

Mdulo Rede

Device Drivers

Figura 3.11 - Relacionamento da biblioteca TLI com o mdulo TLI.

O mdulo TLI atua como um conversor do formato da mensagem vinda


do nvel superior para o mdulo de transporte que se est utilizando naquele
momento.
J os mdulos de transporte, de rede e os device drivers tm a sua
atuao normalmente, gerenciando conexes, efetuando checagens e
correes, enfim, as tarefas que lhes so atribudas.

Dentre as funes que so disponibilizadas pela TLI, podem ser


encontradas aquelas que permitem o uso de servios orientados conexo e
aquelas para serem utilizadas em servios no orientados conexo. Isto
ocorre pelo fato da TLI, assim com o TCP/IP e SPX/IPX, tambm disponibilizar
estes tipos de servios, uma vez que o modelo ISO-OSI tambm o faz.

Como mencionado anteriormente, a TLI permite a utilizao dos servios


orientados e no orientados conexo. As figuras 3.12 e 3.13 demonstram
quais as funes que so utilizadas em cada caso, bem como a seqncia das
mesmas.

O nico aspecto complicador em utilizar-se da TLI reside no fato de que,


se o usurio possuir aplicaes e desejar utilizar-se da facilidades desta
biblioteca, dever trocar as instrues de sua aplicao pelas funes TLI
correspondentes, ou ento reescrever suas aplicaes usando agora as novas
funes.
Servidor
t_open()

t_bind()

Cliente
t_open()

t_alloc)

t_bind()
t_listen()
Bloqueado at receber
conexo do cliente

t_accept()

t_rcv()

t_alloc()

Estabelecimento de Conexo

Dados (Requisio)

t_connect()

t_snd()

Requisio do
processo
Dados (Resposta)
t_snd()

t_rcv()

Figura 3.12 - Funes TLI para servio orientado conexo.


Servidor
t_open()

Cliente
t_bind()

t_open()

t_alloc()

t_bind()

rcvudata()

t_alloc()

Bloqueado at receber
dados do cliente

Dados (Requisio)

t_sndudata()

Requisio do
processo

t_sndudata()

t_rcvudata()
Dados (Resposta)

Figura 3.13- Funes TLI para servio no orientado conexo.

4 Interoperabilidade e Interconectividade de sistemas

As dificuldades encontradas para se atingir a interconectividade e


interoperabilidade residem em adotar-se um padro. Infelizmente, os esforos
em se seguir padres imparciais sugeridos por orgo internacionais no tm
dado certo, visto que as definies oferecidas por estes orgos as vezes no
coincidem com as necessidades ou aspiraes do mercado; vide a tradicional
disputa ISO-OSI com TCP/IP.
No tocante a interconectividade, no existem tantos problemas, uma vez
que a comunidade de usurios e desenvolvedores parecem ter chegado a
padres mais estticos, utilizando Ethernet, Token Ring, ArcNet entre outros,
com suas respectivas topologias para efetuar a interligao entre os elementos
envolvidos no processo de comunicao.
Caso o interessado deseje interconectar ambientes de mesmo padro,
ele pode fazer isto por intermdio de uma ponte e caso deseje interconectar
ambientes com padres diferentes pode utilizar-se de um gateway, conforme
representao 4.1.

Lan Ethernet

Ponte

Lan Ethernet

Gateway
Lan Ethernet

Lan Token
Ring

Figura 4.1 - Representao de uma ponte e um gateway.

No caso de uma ponte, a informao vinda de uma rede simplesmente


transferida para a outra rede, sem que exista a preocupao de alguma
espcie de transformao no formato dos pacotes. Esta mesma facilidade no
se obtm na utilizao do gateway, uma vez que os pacotes devero ter seus
formatos alterados para o tipo correspondente ao da rede destinatria. Porm,
se houver a necessidade de quaisquer mudanas, elas sero feitas pelos
prprios equipamentos envolvidos na operao, no caso, o gateway e a ponte,
no preocupando o usurio no que tange a sua aplicao.
Esta mesma transparncia no encontrada na interoperabilidade. A
interoperabilidade utiliza a interconectividade, atuando a nvel de software,
portanto, cabe ao usurio observar e tratar as incompatibilidades entre as
partes envolvidas.
Uma prova de que as dificuldades em se atingir a interoperao so
muitas e de que os padres tambm, pode ser observada no caso dos diversos
tipos de protocolos de transportes. Podem ser encontrados no mercado uma
grande variedade, como por exemplo os protocolos de transportes padro OSI,
TCP/IP, SPX/IPX entre outros. Onde encontram-se uma compatibilidade a nvel
de servios oferecidos, mas no a nvel de formato das chamadas, conforme
pode ser constatado no captulo Arquiteturas.
Dentre as maiores dificuldades que os desenvolvedores encontram para
atingir a interoperabilidade, podem ser destacadas a maneira como as
aplicaes envolvidas efetuaro a troca de informao, qual o formato da
informao, qual o protocolo envolvido na operao, a portabilidade de uma
aplicao para um outro ambiente distinto entre tantas outras.
Diante deste amontoado de dificuldades, os desenvolvedores tm
colocado seus conhecimentos para prover mecanismos que permitam superar
estes obstculos. Alguns exemplos destes mecanismos podem ser
encontrados na literatura e mesmo em projetos prticos.
o caso, por exemplo, de se construir aplicaes gateways
responsveis por receber, converter e despachar a informao, como sugere
[ROSE90] e muitos outros autores, ou ento de se construrem primitivas que
direcionam a parte dependente de protocolo da aplicao para elementos
dedicados a determinados servios de converso, como acontece na interface

Clean and Simple [COLE87], adoo de filtros conversores para as aplicaes,


ou ainda de se criar funes universais, que independem do tipo de protocolo e
formato da informao que sero utilizados, como mostra [STEV90] sobre a
TLI.
Enfim, existem uma srie de mecanismos que buscam atingir a
interoperao, alguns conseguindo um maior grau e outros nem tanto, mas
todos buscando atingir seus objetivos.
No caso da utilizao das aplicaes gateways, a aplicao original no
ser alterada, em conseqncia, existir um mdulo extra, ou um processo,
encarregado de receber as chamadas feitas pela aplicao, efetuar a alterao
e despachar para o processo destino; alm claro de executar o processo
inverso no caso de recebimento de informaes, figura 4.2. Estas aes podem
comprometer o desempenho da aplicao, e em situaes crticas, como
processamento em tempo real por exemplo, podem comprometer a
estabilidade do sistema.

A p lic a o
A p lic a o

A p lic a o
G atew ay

HOST A

HOST B

Figura 4.2 - Utilizao da tcnica Aplicao Gateway.


Quanto interface Clean and Simple (C & S), o usurio dever alterar o
cdigo fonte da aplicao, adicionando as primitivas que a interface
disponibiliza. Aps esta atividade, necessita-se recompilar a aplicao e eleger
alguns computadores para serem os servidores de protocolos, que sero
encarregados de receberem as solicitaes, process-las e despacha-las s

redes destinatrias. Aqui o desempenho tambm pode ser afetado, visto que a
comunicao no direta entre as partes envolvidas, mas sim atravs de um
elemento intermedirio. A forma de funcionamento da C & S, bem como outros
detalhes, podem ser obtidos no captulo APIs.
Os filtros aparecem como uma boa opo. Eles tomam o cdigo fonte da
aplicao, analisam, e efetuam as alteraes que forem necessrias. O
usurio, por sua vez, recompila a aplicao e esta passa a comunicar-se
diretamente com o ponto desejado; sem ter que trafegar por um elemento
intermedirio.
O desempenho, na utilizao dos filtros, estaria garantido, porm o fator
complicador nesta situao est em se conseguir filtros que convertam as
aplicaes de forma completa, caso contrrio, o usurio dever interferir no
novo cdigo fonte gerado e adequa-lo as suas reais necessidades.
Aplicao
A

FILTRO

Aplicao
B

Comunicao

Nova
Aplicao A

Nova
Aplicao A

HOST B

HOST A

Figura 4.3 - Utilizao da tcnica de filtro.


Uma outra alternativa a utilizao da TLI, que oferece um conjunto de
funes que no esto ligadas diretamente a um protocolo; so funes
universais que podem ser mapeadas para todos os protocolos suportados pela
TLI. O desempenho fica garantido mas o usurio dever escrever novamente
todas as suas aplicaes, trocando as partes dependentes de protocolo pelas
funes TLI. Veja captulo sobre API.

Fica comprovado ento que, apesar de existirem tcnicas para se


buscar a interoperabilidade, estas no so completas; se elas no pecam pelo
desempenho, pecam pelo trabalho extra atribudo ao usurio ou vice-versa.
Conseqentemente, no existe a melhor tcnica, mas sim, a melhor
tcnica para cada caso, que deve ser analisado previamente, considerando
todas as necessidades e implicaes.

Texto gentilmente cedido por Flvio Toledo (flaviot@sti.com.br)

www.sti.com.br