rias para compatibilizar as formas de representao.

Se durante o estabelecimento da conexo de apresentao s for seecionada a unidade funcional

presentation-kernel, ento s o contexto default e os contextos negociados
como parte do DCS (defined context set) no' estabelecimento da conexo
podem ser utilizados. Se a unidade funcional gerenciamento de contexto tiver sido adicionalmente seecionada, possvel modificar o DCS ao longo
.da conexo de apresentao incluindo ou excluindo contextos do DCS.
A unidade funcional restaurao de contexto 6 usada junto com o servio de sincronizao da conexo do nvel de sesso. Nesse caso, o servio
de apresentao memoriza os DCSs ativos em cada ponto de sincronizao
emitido ao longo da conexo. Quando ocorre uma ressincronizao, essa
unidade funcional permite que a verso do DCS que estava ativa no ponto
de sincronizao usado na ressincronizao seja restaurada. De forma semelhante, no servio de gerenciamento de atividades, o servio de apresentao
guarda a verso do DCS usada antes do incio de uma atividade. Quando a
atividade termina, o DCS que estava em voga antes do seu incio restaurado.
O leitor interessado em mais informaes sobre o servio e o protocolo
do nvel de apresentao do RM-OSI deve consultar os padres JSO 8322 e
ISO 8323 ou as recomendaes do CCITT X.216 e X.226, onde encontrar
descries detalhadas dos mesmos.

Captulo 1 5
Nvel de Aplicao

Este captulo apresenta a estrutura proposta pelo modelo OSI para o

desenvolvimento de aplicaes em redes de computadores. Em seguida,
apresentada a proposta da arquitetura Internet para o mesmo problema.
Adicionalmente, so descritos resumidamente vrios padres localizados no
nvel de aplicao das duas propostas. *

1 5 . 1 - 0 Nvel de Aplicao no RM-OSI

O padro ISO 9545 (Application Layer Structure) e a emenda
(Extended Application Layer Structure) definem os conceitos, a terminologia e os modelos utilizados por todos os padres do nvel de aplicao OSI.
A recomendao ITU-T X.207 equivalente a esse padro, e foi usada como
referncia bsica nesta seo.
Como nico nvel do RM-OSI que fornece servios diretamente aos
processos de aplicao, o nvel de aplicao necessariamente prov todos os
servios OSI que podem ser- usados por esses processos para trocar informaes entre si.
O servio do nvel de aplicao, alm da transferncia de dados inclui,
entre outros, os seguintes servios:

378

379

5.1.3 - Elemento do Servio de Aplicao

15.1.5 - Funo de Controle

Um elemento do servio de aplicao (Application Service Element

SE) define um componente bsico cie uma entidade de aplicao. Os ASEs
iplementam facilidades especficas no ambiente de comunicao OSI, por
:empIo, o ACSE (Association Control Service Element) estabelece assoaoes entre entidades de aplicao, e o ROSE (Remate Operation Service
ement) permite que uma aplicao execute uma operao em um processo
: aplicao remoto.

Uma funo de controle (Control Function CF) coordena a atuao

conjunta dos componentes ASEs e ASOs no ASO onde ela reside. A funo
de controle de uma ASOI responsvel pelo fornecimento do servio OSI
que cabe ASOI. Para tal, a CF utiliza de forma coordenada os servios OSI
fornecidos pelos ASOIs e ASEIs contidos na ASOI, e os servios OSI externos ASOI, fornecidos por outras ASOIs ou pelo nvel de apresentao.

Cada ASE definido por dois padres: um define o servio por ele
rnecido e o outro o protocolo que ele utiliza para implementar o servio.
; ASEs so combinados de vrias formas para formar diferentes tipos de
tidades de aplicao.

i.1.4 - Objeto do Servio de Aplicao

Um objeto do servio de aplicao (Application Service Object
IO) uma composio usada para estruturar a camada de aplicao. Um
IO encapsula diversos agrupamentos de funes utilizadas na comunica) entre aplicaes. Cada agrupamento especfico presta um servio e utii um protocolo de aplicao especfico. Os agrupamentos so represenos por ASEs ou outros ASOs, assim, um ASO pode conter:
Um ou mais ASEs e uma funo de controle.
Um ou mais ASOs e uma funo de controle.
Um ou mais ASEs, um ou mais ASOs, e uma funo de controle.
Uma ASOI (Application Service Object Invocation) representa uma
izao especfica de parte, ou de todos os recursos de um dado ASO.
ia ASOI inclui a informao de estado que espelha seu comportamento
uma comunicao.
Uma AE um ASO em uma configurao particular onde o ASO no
tido por nenhum outro ASO. Uma AEI uma ASOI do ASO equivalente
E. A Figura 15.1 ilustra bem a situao.
Dentro de uma ASOI existem outras ASOIs ou ASEIs que corresponi aos ASOs ou ASEs que compem o ASO em questo.
A funo de controle de uma ASOI determina como seus componentes
Eis e ASOIs operam cooperativamente de modo a habilitar a ASOI a forsr um servio OSI especfico, como resultado de sua operao conjunta
as ASOIs parceiras.

Para executar suas funes, a CF de uma ASOI mantm informaes

de estado relativas coordenao local dos componentes da ASOI e relativas coordenao da nterao das ASOIs e ASEIs contidas na ASOI em
questo, com suas parceiras localizadas em outras ASOIs.

15.1.6 - Associao no Nvel de Aplicao

Uma conexo definida no RM-OSI como um servio fornecido a
usurios que esto no nvel superior. Como no existe nvel superior ao de
aplicao, no podem existir conexes nesse nvel. Em vez disso, as entidades de aplicao estabelecem associaes, para viabilizar o intercmbio de
informaes entre processos de aplicao. Uma associao uma relao
cooperativa entre entidades de aplicao formada para que possam ser intercambiadas unidades de dados do nvel de aplicao (APDUS), atravs do
servio fornecido pelo nvel de apresentao.
A recomendao X.207 define uma associao entre ASOs (ASO-association) como um relacionamento cooperativo entre duas ou mais ASOIs.
As associaes ASO so abstraes que relacionam ASOIs que esto intercambiando APDUs. As caractersticas de uma associao entre ASOs so
descritas em um contexto ASO.
Note que uma associao no nvel de aplicao um caso particular de
uma associao entre ASOIs, que utiliza o servio de apresentao para comunicao e coordenao de sua operao conjunta.

15.1.7 - Contexto de Aplicao

Um contexto ASO define o conjunto de regras que governa a comunicao entre ASOIs, e o conhecimento que elas devem compartilhar para que
possam operar cooperativamente em uma associao ASO. Um contexto
ASO inclui:
Um conjunto de regras e informaes de estado.
O nmero de ASOIs que so parceiras em uma associao ASO.
383

!
Identificao dos futuros parceiros na comunicao (por exemplo,
pelo nome ou pelo endereo).

(
I

Determinao da qualidade de servio aceitvel na conexo (por

exemplo, retardo de transferncia, taxa de erro tolervel, custo do
servio etc).

Sincronizao das aplicaes participantes.

Definio da responsabilidade na recuperao de erros.

Especificao de aspectos relativos segurana (por exemplo, autenticao, controle de acesso, integridade dos dados etc).
Seleo do modo do dilogo (full duplex ou half duplex).
Identificao de sintaxes abstratas.
S

(
( .

(.
(
(

O nvel de aplicao contm todas as funes necessrias comunicao entre sistemas abertos que no so executadas pelos outros nveis, incluindo, tanto funes executadas por programas, quanto funes executadas por seres humanos.

15.1.1 - Processo de Aplicao

Dentro de um sistema aberto OSI, um processo de aplicao uma re
presentao abstrata de um conjunto de recursos que podem ser usados para
executar uma atividade de processamento de dados especfica. S as partes
do conjunto de recursos relativas ao aspecto de comunicao so assuntos
dos padres elaborados no mbito do RM-OSI.
Os processos de aplicao so identificados global e univocamente por
seu ttulo de processo de aplicao.
Como nvel superior do RM-OSI, o nvel de aplicao prov aos processos de aplicao o acesso ao ambiente desse modelo. O ambiente OSI
definido pela ISO [ISO 92] como sendo uma representao abstrata do conjunto de. conceitos, elementos, funes, servios, protocolos etc. definidos
pelo RM-OSI e os padres especficos dele derivados que, quando aplicados, tornam possvel a comunicao entre sistemas abertos..

('

Os mdulos que compem um processo de aplicao so divididos em

duas partes. Uma delas implementa as funes de processamento de dados
particulares a uma dada aplicao; a outra, a entidade de aplicao, trata dos
' aspectos relativos ao intercmbio de informaes, ou seja, dos servios de
comunicao OSI. A Figura 15.1 mostra a estrutura do nvel de aplicao do
RM-OSI.

38

Figura 15.1: Estrutura do nvel de aplicao do RM-OSI.

15.1.2 - Entidade de Aplicao

Uma entidade de aplicao OSI (Application Entity AE), represe
um conjunto de facilidades de comunicao de um processo de aplica
especfico, por exemplo, os mdulos de um processo de aplicao que
responsveis pelo intercmbio de arquivos ou mensagens. Um processo
aplicao contm uma ou mais entidades de aplicao.
As entidades de aplicao em um processo de aplicao, se distingi
atravs do uso de um qualificador. O qualificador concatenado ao ttulo
processo de aplicao forma o ttulo da entidade de aplicao.
Uma AEI (Application Entity lnvocation) uma utilizao espec
de parte, ou de todos os recursos de comunicao de uma dada AE. A Al
usada.para.atender os requisitos de comunicao de um processo de apl
o. Processos de aplicao trocam informaes por meio de AEIs que u
zam os protocolos do nvel de aplicao e os servios do nvel de apres
taco.

. A durao da associao ASO, e a especificao da forma como ela

pode ser estabelecida e encerrada.
Um contexto de aplicao um tipo especfico de contexto ASO. O
contexto de aplicao descreve o comportamento de uma associao ASO
especfica.

15.2 - Padres ISO para Servios de Aplicao

Os servios de aplicao so organizados em elementos de servio de
aplicao de uso geral e elementos de servio de aplicao especficos.
Os elementos de servio de uso geral implementam uma srie de funes bsicas que so utilizadas pelas entidades de aplicao e por outros
elementos de servio. A ISO padronizou, entre outros, os seguintes elementos de servio de uso geral: ACSE (Association Control Service Element),
RTSE (Reliable Transfer Service Element), ROSE (Remote Operations
Service Element) e CCR (Commitment, Concurrency and Recovery).
Vrios padres tm sido definidos para fornecer servios especficos
em nvel de aplicao. Alguns exemplos so o X.400, que define um servio
de tratamento de mensagens, entre eles o correio eletrnico, o FTAM (File
Transfer, Access and Management) para manipulao de arquivos, e o
X.500 que define um servio de diretrio.
Uma entidade de aplicao no definida por um padro de aplicao
nico. Uma entidade de aplicao, conforme j mencionado, tipicamente 6
composta por vrios ASEs, cada qual definido por um padro diferente. A
forma como os ASEs cdmbinm-se, interagem uns com os outros, e com os
nveis inferiores, define o protocolo de aplicao. A Tabela 15.1 [Dickson
92] lista os principais padres utilizados no nvel de aplicao. Alguns desses padres so descritos nos itens a seguir.

15.2.1 - ACSE (Association Control Service Element)

Cada tipo diferente de aplicao demanda uma combinao diferente
de ASEs para formar o protocolo de aplicao especfico. O ACSE o elemento de servio que gerncia as associaes, estando presente na grande
maioria das aplicaes OSI. Ao contrrio das conexes dos nveis inferiores,
que tm propsito geral, cada associao especificamente definida para
uma dada tarefa. Embora as aplicaes estabeleam associaes com diferentes objetivos, algumas operaes bsicas tm de ser sempre executadas.
O ACSE padroniza essas operaes.

384

Tabela 15.1: Padres do nvel de aplicao

Nome

ISO

Elementos de Servio de Aplicao

ACSE Association Control Service Element
RTSE Reliable Transfer Service Element
ROSE Remote Operations Service Element
CCR Commitment, Concurrency and Recovery
"MHS Message Handling Systems
EDS Electronic Directory Services
FTAM File Transfer, Access and Management .
VT Virtual Terminal
JTM Job Transfer Mampuiation
DTP Distributed Transaction Processing
MMS Manufacturing Message Specification
CMIP Commoii Management Information Protocol
RDA Remote Database Access

1S08649 / 1SO8650
ISO906 Parts 1 e 2
(SO9072 Parts 1 e 2
ISO9804 / ISO9805
ISO 10021 Parts 1-7
IS09594 Parts 1-8
ISQ8571 Parts 1-4
1SO9040/ISO9041
IS08831 /1S08832
lSO10026PartsT-3
1SO9506 Parts 1 e 2
IS09595 / IS09596
ISO DIS 9579 Parts 1-2

X.217/X.:
X.218/X.:
X.219/X.:

1S08613 Parts 1-8

IS09735

T.411-T.4

CCTTT

X.400 -X.
X'.500~X.;

X.710/X/

Sintaxes Usadas no Nvel de Aplicao

ODA |Open Document Architecture
ED Eletronic Data Interchange

Existe uma correspondncia de um para um entre uma associao

nvel de aplicao, uma conexo de apresentao e uma conexo de sess
Quando uma associao a nvel de aplicao estabelecida (ou encerrac
as conexes de apresentao e sesso que lhe do suporte so estabeleci
(ou encerradas) simultaneamente. A Figura 15.2 mostra a relao das pri:
tivas de servio que estabelecem uma associao em nvel de aplicao, c
as que estabelecem as conexes de apresentao e sesso respectivame
associadas.

Observando a Figura 15.2, podemos notar que muitos dos parmet

fornecidos pelo usurio, quando emite a primitiva de servio solicitand
abertura de uma associao, so mapeados diretamente em parmetros i
servios de apresentao e sesso. Cabe ressaltar que a Figura 15.2 no e
completa (a primitiva A-ASSOCIATE.request tem mais de 20 parmetre
mostrando apenas alguns dos parmetros dos servios em questo.
O ACSE acrescenta semntica da conexo de apresentao, que
suporte associao, a possibilidade de identificao de objetos atravs
nomes. Cada entidade de aplicao possui um ttulo que identifica o serv
por ela oferecido. Cabe salientar que o ttulo independente de qualq
considerao sobre endereamento e roteamento. Ele simplesmente
nome. Um usurio (iniciador) ao desejar estabelecer uma associao, d<
identificar o tipo de servio que deseja atravs de seu ttulo e solicitar (
seja estabelecida uma associao entre ele e uma entidade de aplicao, e

cutando na rede, que fornea o servio desejado. O ACSE deve ser capaz de
mapear o nome no endereo de apresentao (SAP de apresentao) da entidade de aplicao de destino, o respondedor. O servio de diretrio, que ser
descrito posteriormente, o responsvel pelo gerenciamento dos nomes e
dos atributos a eles associados. O ACSE utiliza o servio de diretrio para
mapear o ttulo de uma entidade de aplicao em um dos seus atributos, o
seu endereo de apresentao (seletor de apresentao + seletor de sesso +
seletor de transporte + endereo de rede). De posse do endereo de apresentao, o ACSE estabelece uma conexo de apresentao com o respondedor,
e abre o processo de negociao do contexto de aplicao que ser usado na
associao. Os usurios iniciador e respondedor fazem suas propostas para o
contexto de aplicao, resultando dessa negociao o contexto que ser
adotado na associao.

Um adendo definio do servio do ACSE acrescentou, ao servio

original, a funo de autenticao da identidade dos usurios de seu servio.
O adendo acrescentou primitiva A-ASSOCIATE, parmetros que so usados para transportar informaes usadas para autenticao.

15.2.2 - RTSE (Reliable Transfer Service Element)

Imaginemos a seguinte situao: no final da transferncia de um arquivo com 10 Mbytes, em uma rede cuja taxa de transmisso de 9.600 bps,
a rede pra momentaneamente de operar, s voltando a funcionar 30 minutos depois. A transferncia desse exemplo demora aproximadamente 2 horas
e meia. Em aplicaes com essas caractersticas, bastante desejvel que a
transferncia interrompida possa ser posteriormente retomada a partir do
ponto onde foi suspensa. No Captulo 13, vimos que essa facilidade fornecida pelo nvel de sesso em seu servio orientado conexo. Vimos tambm, o quanto complexa a utilizao desse servio.
O objetivo do RTSE fornecer um servio que, embora no seja to
geral quanto o do nvel de sesso, fornea uma interface simples e seja capaz de transferir unidades de dados de tamanho arbitrrio de forma confivel
entre entidades de aplicao. O RTSE fornece mecanismos genricos que,
em casos onde uma falha do sistema de comunicao interrompe a conexo
inicialmente utilizada na transferncia de dados, permitem o restabelecimento da transferncia de dados do ponto onde foi suspensa, em uma nova
conexo.
O RTSE utiliza o ACSE, para estabelecer e encerrar associaes, e alguns dos mecanismos de sincronizao e gerenciamento de tokens e de atividades fornecidos pelo servio de sesso (atravs do servio de apresentao), para garantir a confiabilidade nas transferncias de dados. A Figura
15.3 mostra as primitivas de servio trocadas pelo RTSE com seus usurios,
com o ACSE e com o servio de apresentao.

Figura 15.2: Estabelecimento de conexes de apresentao e sesso para dar suporte a uma
- associao de aplicao.

O ACSE fornece um servio de encerramento da associao ordenado,

com os dados em trnsito sendo entregues antes da desconexo. As conexes de apresentao e sesso que do suporte associao so encerradas
junto com ela. O ACSE permite adicionalmente que uma associao seja
abortada. Nesse caso pode haver perda dos dados em trnsito.

386

Aps utilizar o ACSE para estabelecer uma associao entre entidades

de aplicao, o RTSE permite a troca de dados na forma de APDUs
(Application Protocol Data Units) RTSE. Quando uma APDU confirmada
pelo RTSE (reconhecimento positivo passado atravs da primitiva RTTRANSFER.confirm), o usurio tem a certeza de que a unidade de dados foi
entregue corretamente ao destinatrio. Quando o RTSE no consegue transferir a APDU, ele sinaliza essa impossibilidade para seu usurio atravs de
um reconhecimento negativo, tambm passado atravs da primitiva RTTRANSFER.con.firm.

387

(
tra entidade de aplicao (AE executora), especificando uma operao a
executada. A entidade executora tenta executar a operao e, opcionalme
comunica entidade solicitante o efeito da tentativa. A resposta, qua
existir, ser: o resultado,'se a execuo da operao foi bem-sucedida;
erro, se houve uma falha durante a execuo da operao; ou, uma rejeu
se a operao no foi executada (por exemplo, porque no existe
processo de aplicao de destino). A funo do ROSE coordenar as
teraes solicitao/resposta entre as entidades de aplicao, que acontei
no contexto de uma associao de aplicao.

\
(
(
{

Como pode ser observado, o ROSE pode ser usado como suporte
mecanismo RPC (Remote Procedure Call), que um dos mecanismos r
usados na construo de aplicaes distribudas. O RPC ser apresentade
Seo 15.3.3.1.

i
(
(

Figura 15.3: Primitivas de servio trocadas pelo RTSE com seu usurio, com o ACSE e com
o nvel de apresentao.

c
(
(
(
(

{
(
(
(

A transferncia de cada APDU realizada em uma atividade distinta

no nvel de sesso. O RTSE segmenta a APDU em blocos de dados, iniciando uma atividade de sesso, antes de comear a transferncia dos blocos. Na fase de transferncia de dados, o envio de cada bloco de dados seguido pela emisso de um ponto de sincronizao secundrio e pela espera
de sua confirmao. Ao final da transferncia de todos os blocos de dados
de uma APDU, a atividade de sesso encerrada. Se existir outra APDU a
transmitir, o RTSE abre uma nova atividade de sesso, repetindo o procedimento.
O RTSE utiliza o ACSE para encerrar uma associao de forma ordenada, sem perda dos dados em trnsito. Como mencionamos anteriormente,
existe tambm a alternativa de abortar a associao, nesse caso, com possvel perda de dados.

(
(

15.2.3 - ROSE (Remote Operations Service Element)

O ROSE foi elaborado para facilitar o desenvolvimento de aplicaes

distribudas interativas. O principal servio fornecido pelo ROSE a solicitao de execuo de uma operao em um sistema aberto remoto. A entidade de aplicao (AE solicitante) envia uma solicitao de execuo para ou-

(
(

388

Alm do suporte para RPC, o ROSE implementa a noo de lin

operations (tambm denominado de callback). O ROSE permite que um
argumentos de uma solicitao de execuo de operao (operao
contenha o nome de uma operao (operao filha), cuja execuo deve
solicitada como parte da execuo da operao original. Por exemplo [S
90], imaginemos uma operao denominada Busca que possui dois ai
mentos: o nome de um diretrio e o nome de uma operao que deve
executada em cada um dos arquivos desse diretrio. Para imprimir todo;
arquivos de um diretrio remoto em uma impressora local, bastaria cole
no segundo argumento da operao Busca, a operao ImprimirArq. A c
rao Busca poderia ser usada igualmente para listar os arquivos de um d
trio remoto na tela. Nesse caso, o segundo argumento seria uma opera
ListaArq. Em ambos os casos, a operao Busca l os arquivos de um d
trio remoto e, para cada arquivo encontrado, solicita a execuo da opi
o contida no segundo argumento, passando como argumento o nome
arquivo lido. Nestes exemplos, a operao Busca solicita que a operac
lha seja executada pela entidade de aplicao que solicitou a sua execui
A utilizao-das linked operations do ROSE depende da classe da
sociao acordada entre as entidades iniciadora (entidade que emitii
primitiva A-ASSOCIATE.request do ACSE) e respondedora (entidade i
emitiu a primitiva A-ASSOCIATE.response do ACSE). Nas associaes
Classe 1, o ROSE s permite que a entidade iniciadora solicite a execui
de operaes remotas. Nas associaes de Classe 2 s o acolhedor pi
emitir solicitaes. E, nas associaes de Classe 3 ambos podem emitir
licitaes. A classe de uma associao um atributo do contexto de apli
o, que definido quando a associao de aplicao estabelecida.
A Figura 15.4 ilustra a utilizao do ROSE em uma associao
Classe 3. Note, na Figura 15.4, que uma operao filha pode chamar out
operaes. Nessa figura a entidade de aplicao AE1 solicita entidade A

que execute a operao A. Durante a execuo da operao A, AE2 solicita

que AE1 execute a operao B (B filha de A). A entidade AE1, ao executar a operao B solicita que AE2 execute a operao C, que filha de B e
neta de A.

15.2.4 - CCR (Commitment, Concurrency and Recovery)

O CCR fornece mecanismos que permitem que duas entidades de aplicao distintas coordenem seu processamento, no sentido de garantir que a
execuo de determinadas operaes s ocorra quando ambas as entidades
estiverem prontas para execut-las. O CCR prov tambm mecanismos que
permitem a recuperao dos dados processados para um estado consistente,
quando ocorre alguma falha durante a execuo do procedimento.
No CCR uma ao atmica definida como sendo uma operao de
processamento indivisvel. Os dados manipulados durante o processamento
da ao atmica so denominados dados delimitados (bounded data). O valor desses dados modificado de forma consistente. Se ocorrer algum erro
durante o processamento da ao atmica o valor que os dados delimitados
possuam antes do incio do processamento da ao restaurado.
O CCR adota o modelo mestre/escravo para o relacionamento das duas
entidades de aplicao envolvidas no processamento de uma ao atmica.
O intercmbio de informaes entre o mestre e o escravo baseia-se no procedimento denominado two-iase-commitment, ilustrado na Figura 15.5.

Figura 15.4: Mecanismo linked operations no ROSE.

A interao entre as duas entidades envolvidas na execuo de uma
operao remota caracterizada por uma classe de operao ROSE. A
classe de operao define se o modo de operao sncrono (o solicitante
aps invocar Uma operao aguarda a resposta da tentativa de execuo antes de invocar outra operao), ou assncrono (o solicitante pode invocar
vrias operaes sem ter recebido os resultados de solicitaes anteriormente feitas). A classe de operao define tambm o modo de resposta, que
pode ser um. dos seguintes:
Sempre comunicado o resultado.
O resultado s comunicado em caso de falha na execuo.
O resultado s comunicado em caso de sucesso na execuo.
O resultado no comunicado.
O leitor interessado em mais informaes sobre o ROSE, deve consultar os padres ISO 9072-1 (ITU-T X.219) e ISO 9072-2 (ITU-T X.229) que
descrevem respectivamente, o servio e o protocolousados pelo elemento de
servio ROSE.

390

A primeira fase do procedimento comea quando o mestre informa ao

escravo que ser iniciado o processamento de uma ao atmica. Durante o
processamento, o mestre e o escravo podem trocar dados entre si. Quando
termina o processamento da ao atmica, o mestre pergunta ao escravo se
ele est preparado para atualizar os dados delimitados. Se o escravo responder que sim, a primeira fase encerrada e o procedimento entra na segunda
fase. Se ele responder que no, a ao retorna (roll-back) para seu incio.
Na segunda fase do procedimento two-fase-commitment, o mestre
atualiza os dados em seu sistema local e solicita ao escravo que faa o
mesmo. Cabe salientar que o mestre atualiza os dados, mas matem uma cpia dos valores dos dados delimitados antes da atualizao. Ao terminar a
atualizao dos dados, o escravo envia uma mensagem para o mestre avisando se a atualizao foi bem-sucedida ou no. Em caso positivo, o mestre
desfaz-se da cpia dos valores iniciais dos dados delimitados. Em caso negativo, a ao retorna para o seu incio, fazendo com que o mestre e o escravo restaurem os valores iniciais dos dados delimitados. Embora no tenham
aparecido na Figura 15.5, foram definidas no servio CCR primivas para
comandar o reincio de ao atmica primitiva C-ROLLBACK, e para
disparar o procedimento de recuperao dos dados delimitados primitiva
C-RECOVER. Cabe ressaltar entretanto, que o procedimento adotado para
restaurar os dados no faz parte do padro CCR, sendo responsabilidade do
processo de aplicao especfico defini-lo.

391

Uma mensagem no MHS consiste em um envelope e um contedo. No

contedo so armazenadas as informaes que o remetente deseja enviar ao
destinatrio. Se a mensagem for interpessoal (IPM) o contedo consiste em
um cabealho e um corpo. O corpo contm os dados propriamente ditos, podendo ser composto por vrias partes, que podem conter dados representados de diferentes formas, como por exemplo, texto, imagens, dados binrios
etc. O cabealho contm campos que identificam o destinatrio (pode ser
especificado mais de um destinatrio), o remetente, o assunto etc. O MHS
tambm pode ser usado para transferir outros tipos de mensagens, por
exemplo, o corpo de uma mensagem pode carregar uma unidade de dados
em um sistema EDI, como mencionamos. O envelope consiste em informaes que indicam como localizar o destinatrio da mensagem, o nvel de
prioridade da mensagem, alm de outras que so usadas internamente pelo
sistema de correio eletrnico para rotear e entregar a mensagem.
Figura 15.5: Execuo de uma aao atmica sob a coordenao do CCR.

O CCR tambm pode ser usado para coordenar a atualizao de dados

feita por vrias aes atmicas concorrentes. A coordenao baseia-se na
serializao da execuo das aes concorrentes. O CCR s permite que
uma ao se inicie quando no existir nenhuma outra em andamento. 0 que
facilmente implementado j que o servio CCR s atende a um par de entidades de aplicao, interagindo no contexto de urna nica associao de
aplicao.
Para tratar os casos onde mais de dois usurios esto envolvidos em
uma aplicao distribuda, a ISO desenvolveu um outro padro denominado
Distributed Transaciion Processing DTP (ISO 10026).

15.2.5 - Servio de Tratamento de Mensagens X.400

O correio eletrnico a mais popular das aplicaes de redes de computadores. A recomendao X.400 do ITU-T, que define o MHS (Message
Handling Systems), especifica um sistema de tratamento de mensagens que
pode ser usado na realizao de um sistema de correio eletrnico. O padro
correspondente da ISO o que define o MOTIS Message Oriented Text
Interchange Systems (ISO 10021).
No X.400, como em outros sistemas de correio eletrnico baseados em
computadores, os usurios trocam informaes na forma de mensagens, podendo o sistema, opcionalmente, avisar ao remetente da entrega ou do recebimento da mensagem. O MHS pode ser usado para troca de correspondncia interpessoal ou para troca de documentos comerciais. Por exemplo,
aplicaes Electronic Data Interchange EDI podem utilizar o MHS em
suas comunicaes.
392

Uma mensagem pode ser temporariamente armazenada ao longo do

caminho, durante sua transmiso no MHS, dependendo da ocupao do
meio de transmisso e da disponibilidade do destinatrio para receb-la. A
operao store-and-forward do MHS apresenta como grande vantagem o
fato de no exigir que o remetente e o destinatrio estejam simultaneamente
disponveis para que seja possvel transferir informaes entre eles. O remetente pode submeter mensagens a qualquer momento e no precisa esperar
at que o destinatrio esteja disponvel para aceitar a entrega. Da mesma
forma, o destinatrio pode ler as mensagens a ele entregues no momento que
achar mais adequado, no precisando interromper outras atividades, como
ocorre, por exemplo, em uma chamada telefnica.
O MHS definido em termos dos componentes funcionais mostrados
na Figura 15.6. O sistema consiste em um MTS (Message Transfer System)
e de vrios UAs (User Agents). Um UA atua como uma caixa postal do
usurio, auxiliando-o na criao, envio e recepo de mensagens. O usurio
pode ser uma pessoa ou um processo de aplicao. Existe ura UA por
usurio do sistema de correio eletrnico.
O MTS uma coleo de MTAs (Message Transfer Agents) que atuam
cooperativamente. Cada UA ligado a um nico MTA. O MTA recebe e
entrega mensagens entre os UAs a ele conectados diretamente, e transfere
para outros MTAs as mensagens endereadas aos UAs que no esto diretamente ligados a ele. As mensagens so transferidas entre MTAs no modo
store-and-forward. Quando o caminho a ser seguido por uma mensagem
est temporariamente interrompido, ou quando a mensagem corrompida
por erros de transmisso, o MTA faz vrias tentativas de transmisso, dentro
de um intervalo de tempo limitado (por exemplo, 48 horas). Se dentro do
intervalo ele no conseguir entregar a mensagem, ela descartada e uma
notificao enviada para o remetente.
393

Figura 15.6: Modelo fimcicmal do MHS.

O roteamento das mensagens feito nos MTAs baseia-se em endereos

hierrquicos usados para identificar os usurios. O X.400 define um
esquema global para definio de nomes e de endereos, onde cada usurio
identificado de forma no ambgua por um endereo. Os endereos no
MHS consistem nos seguintes campos:
Nome do Pas: cdigo com dois caracteres (ISO 3166) ou com trs
caracteres (CCITT X.121) que identifica o pas onde est o usurio.
Nome ADMD: nome do domnio administrativo ao qual est conectado o usurio,1
Nome PRDM: nome do domnio privado ao qual est conectado o
usurio.
Nome da Organizao: nome da organizao onde o usurio encontrado.
Nome da Unidade na Organizao: nome da unidade dentro da organizao onde o usurio encontrado.
Nome Pessoal: nome do usurio.

' No esquema de interconexo internacional do MHS, os MTAs so interconectados e

organizados em domnios. Um ou mais MTAs, zero, um ou mais MSs. e zero, um ou mais UAs
gerenciados por uma organizao constituem um domnio. Existem dois nveis de domnios: o ADMD
(Administrative Management Domain) geralmente administrado por organizaes que Fornecem servios
de transmisso ao pblico, e o PRDM (Private Management Domain) gerenciado por corporaes

394

Para operar na forma descrita at aqui, tanto o MTA quanto o UA teriam que ser sistemas confiveis e de alta disponibilidade. Embora seja razovel esperar que a mquina onde executado um MTA atenda a esses requisitos, o mesmo no se aplica s mquinas onde so executados os UAs.
Por exemplo, o requisito de disponibilidade inviabilizaria a execuo de
UAs em computadores pessoais, que usualmente ficara desligados noite e
nos fins de semana. A soluo adotada para contornar esse problema foi a
introduo de uma nova entidade, o MS (Message Store). A tarefa do MS
agir como intermedirio entre o UA e o MTA. Quando deseja entregar uma
mensagem a um usurio a ele conectado por intermdio de um MS, o MTA
simplesmente coloca a mensagem no MS. Quando o UA do usurio entrar
em funcionamento (por exemplo, o computador pessoal onde o UA executa
ligado), ele apanha a mensagem no MS e a entrega ao usurio. O processo
inverso tambm intermediado pelo MS. Quando um UA recebe do usurio
uma solicitao para enviar uma mensagem, ele a coloca no MS. Esse procedimento de submisso indireta permite que a mquina onde executada a
MTA possa executar outras tarefas, visitando periodicamente o MS para retirar as mensagens nele colocadas para transferncia.
O modelo usado pelo MHS uma verso eletrnica do sistema de correio postal, onde o papel dos UAs desempenhado pelos carteiros, o dos
MSs, pelas caixas postais e o dos MTAs, pelas agncias postais. A verso de
1988 do MHS utiliza os elementos de servio ACSE, RTSE, e ROSE para
implementar seus servios.
O leitor interessado em mais detalhes sobre o MHS deve consultar a
srie de recomendaes X.400 ou os padres ISO 10021-1 a ISO 10021-7,
listados na Tabela 15.2.

' Tabela 15.2: Padres M H S

CCITT
X.400
X.402
X.403
X.407
X.408
X.411
X.413
X.419
X.420
X.435

iso
10021-1
10021-2
1002)-3
10021-4
10021-5
10021-6
,10021-7

Titulo
Service and System Overview
Overall Architecture
Conformance Testiri"
Abstract Service Definition Conventions
Encoded Information Type Conversion Rules
MTS Service Definition
Message Store Service Definition
Protoco! Specificatons
Interpersona! Messaging System
D1 Messaging

395

15.2.6 - Servio de Diretrio X.500

Um diretrio' um banco de dados, mantido conjuntamente por urna
coleo de sistemas abertos distribudos, com informaes sobre um conjunto de objetos reais (instncias de entidades de aplicao, usurios, mquinas
etc.) desses sistemas. Os usurios do diretrio, que podem ser pessoas ou
processos de aplicao, podem ler ou modificar a informao nele armazenada, caso tenham permisso para tal.
Os comits de padronizao reconhecendo a importncia do servio de
diretrio eletrnico em qualquer sistema de comunicao de grande porte,
elaboraram a srie de padres X.500, publicada em 1988, e os padres ISO
9594 Partes 1 a 8, que atingiram o status de padres internacionais (IS) em
990.
O servio de diretrio responsvel pelo gerenciamento de nomes e
atributos a eles associados. Como um exemplo de atributo, recordemos que
na discusso sobre o endereamento no elemento de servio ACSE, vimos
que um dos atributos que deve ser associado a um nome o endereo de
apresentao da entidade.
A funo mais utilizada do servio de diretrio a recuperao do endereo de entidades com base em seu nome lgico. Um nome lgico deve
ser facilmente manipulado e memorizado por seres humanos, e independentemente da localizao da entidade. Como um exemplo de recuperao do
endereo de entidades com base em seu nome lgico, podemos citar o MHS
que, como vimos, tem seus nomes compostos pelo nome do pas, pelos nomes de organizaes e pelo nome pessoal; porm,'para que uma mensagem
seja entregue, o nome deve ser mapeado no endereo de apresentao do
usurio, que uma cadeia de octetos dependente da localizao e da estrutura da rede onde ele est conectado.
muito comum encontrar pessoas e outros objetos que so conhecidos
por vrios nomes. O servio de diretrio associa um nome nico a cada um
dos seus objetos. permitindo que eles sejam localizados por nomes alternativos e abreviaes. O diretrio pode armazenar, adicionalmente, listas de
distribuio, que consistem em listas de nomes de pessoas ou outros objetos
que pertencem a um grupo.
O servio de diretrio pode ser utilizado em procedimentos de controle
de acesso, centralizando a administrao das informaes. O diretrio pode
ser usado para armazenar a senha (password) de um usurio especfico, ou
chaves usadas em sistemas de criptografia, devidamente protegidas contra
violaes. A Figura 15.7 mostra um exemplo [Dckson 92] onde o usurio B
utiliza o servio de diretrio para autenticar a senha do usurio A.
396

Sucesso ou Falha (4)

Figura 15.7: Autenticao de um usurio atravs da verificao de senha.

Uma vantagem do esquema ilustrado na Figura 15.7, que a identidade

de um usurio pode ser autenticada por diferentes aplicaes, que no precisam armazenar as senhas de seus clientes. Outra vantagem que quando o
usurio deseja modificar sua senha, s preciso atualizar um nico ponto, o
diretrio.
As caractersticas de uma aplicao remota tambm podem ser armazenadas nos atributos associados a seu nome no servio de diretrio. Antes
de tentar uma comunicao com uma entidade de destino muitas vezes necessrio conhecer algumas de suas caractersticas. O servio de diretrio
pode prover essas informaes.
A DIB (Directory Information Base) contm todas as informaes que
podem ser obtidas atravs do servio de diretrio. A DIB composta por
instncias de objetos chamadas entradas. Cada entrada consiste em um ou
mais atributos. Cada atributo composto por dois campos: um deles armazena o tipo do atributo e o outro contm um ou mais valores. O tipo do atributo define a forma como deve ser interpretada a informao armazenada no
campo valor. A presena e o tipo dos atributos de uma entrada dependem da
classe do objeto que a entrada instancia. Por exemplo, 'as entradas com instncias de objetos da classe "entidade de aplicao", incluem os seguintes
atributos: nome, endereo de apresentao (endereo do PSAP), descrio,
contextos de aplicao usados etc.
Cada entrada na DIB possui um RDN (Relative Distinguished Name).
O RDN um conjunto de valores de atributos especiais (distinguished
values). Usualmente, apenas o valor de um atributo define o RDN de uma
entrada. Em alguns casos especiais, porm, necessrio usar o valor de mais
de um atributo para identificar uma entrada. Por exemplo, o RDN de uma
entrada com informaes sobre o Brasil "C = BR", onde C o nome do
atributo cujo valor distingue entradas com instncias de objetos da classe
397

pas, e BR o valor (distinguished value) do atributo C na entrada da DIB

que corresponde ao Brasil.

a) Interao com indicao

As entradas da DIB so organizadas hierarquicamente na forma de uma

rvore invertida, a DIT (Directory Information Tree). O primeiro nvel da
rvore, a raiz, no possui um RDN explcito, pois a nica entrada em seu
nvel na DIT. O nome que distingue uma entrada no diretrio, seu DN
(Distinguished Narne), consiste em todos os RDNs no caminho entre a raiz e
a entrada a ele associada no diretrio. Note que o RDN deve distinguir uma
entrada de seus irmos na DIT. Por exemplo, o DN do departamento de informtica da PUC-Rio seria "C = BR, O = PUC-Rio, OU = inf". Onde o
RDN "C = BR" identifica o pas, o RDN "O = PUC-Ri" a organizao e o
RDN "OU = Inf" a unidade na organizao.
O servio de diretrio distribudo, sendo composto por vrios DSAs
{Directory Service Agents). Cada DSA gerncia uma parte do diretrio. Um
usurio do servio de diretrio definido como sendo uma pessoa ou um
processo de aplicao. Um usurio tem acesso ao diretrio atravs de um
DUA (Directory User Agent). Existe um DUA para cada usurio do servio
de diretrio. O DUA comunica-se com um DSA, atendendo a solicitaes de
seu usurio, para ter acesso a informaes no diretrio. Se a informao estiver disponvel no DSA, ele responde devolvendo a informao solicitada
ao DUA, que ento a entrega ao usurio. Se o DSA no possuir a informao solicitada, ele pode:

b) Interao com encadeamento

Devolver uma indicao (referral), com o endereo de apresentao

de outro DSA que contm, ou pelo menos est mais prximo da informao desejada. Nesse caso o DUA emite uma nova solicitao
para o novo DSA, como pode ser observado na Figura 15.8-a.
Contactar um segundo DSA repassando a solicitao. Nesse caso
vrios DSAs podem ser consultados em srie para que a solicitao
do usurio seja atendida, como mostra a Figura 15.8-b. Essa abordagem denominada encadeamento (channg).

c) Consulta mltipla simultnea

d) Consulta mltipla sequencial

Contactar outros DSAs, repassando a solicitao feita pelo DUA.

Essa abordagem possui duas variaes: na primeira os vrios DSAs
so consultados simultaneamente (Figura 15.8-c), na segunda vrios
DSAs so consultados, porm um de cada vez (Figura 15.8-d).
Um grupo de DSAs administrados por uma mesma autoridade e res-ponsveis pelo gerenciamento de uma poro da rvore de informaes
contida no diretrio, denominado DMD (Directory Management Domain).
Como no MUS, existem dois nveis de DMD: os. ADDMDs (administrative),
gerenciados por prestadores de servios pblicos de telecomunicao; e os
PRDMDs (private), gerenciados por organizaes privadas.

Figura 1S.S: Interao entre DUA e DSA.

399
398

O leitor interessado em mais detalhes sobre o servio de diretrio deve

consultar a srie de recomendaes X.500 do CCITT, ou os padres da ISO
correspondentes, ISO 9594 Partes 1 a 7, listados na Tabela 15.3.
Tabela 15.3: Padres do Servio de Diretrio
CCITT
X.500
X.50I
X.509
X.511
X.518
X.519
X.520
X.521

ISO
9594-1
9594-2
9594-8
9594-3
9594-4
9594-5
9594-6
9594-7

Ttulo
Overview of Concepts, Models and Service
Models
Authenticaion Framework
Abstract Service Definiton
Procedures for Distributed Operation
Protocol Specifications
Selected Atribute Types
Selected Object Classes
Figura 15.9: Modelo de operao do FTAM.

15.2.7 - FTAM (File Transfer, Access and Management)

O FTAM, descrito nos padres ISO 8571 Partes l a 4, permite que seus
usurios tenham acesso a arquivos em sistemas remotos. O FTAM permite
que os arquivos sejam transferidos como uma unidade, ou que tenham acesso por partes em operaes de leitura e escrita,- e que operaes de criao,
remoo e manipulao dos atributos de arquivos remotos possam ser realizadas.
O FTAM opera com base em associaes no nvel de aplicao, que
envolvem uma entidade FTAM iniciadora, que fornece o servio FTAM
para o usurio cliente, e uma entidade FTAM respondedora, que gerncia o
acesso ao sistema de arquivos remoto (Figura 15.9). O sistema de arquivos
virtual um modelo abstraio usado para descrever um sistema de arquivos2
de forma independente das caractersticas de implementao, fornecendo
uma interface homognea para o acesso a qualquer implementao particular de um sistema de arquivos real. Todas as definies e especificaes do
protocolo FTAM dizem respeito ao sistema de arquivos virtual. Cada sistema aberto que se proponha a fornecer o servio FTAM deve responsabilizar-se pela implementao de uma funo de mapeamento das operaes do
sistema de arquivos virtual, em operaes no seu sistema de arquivos real.
Cabe destacar que a implementao da funo de mapeamento est fora do
escopo do padro FTAM.

- Um sistema de arquivos na terminologia FTAM uma coleo organizada de arquivos,

incluindo seus atributos e nomes, residindo em ura sistema aberto especfico.

400

Na verso inicial do FTAM, o sistema de arquivos virtual s conti

arquivos. Um adendo ao padro, que atingiu o status de padro internacit
em 1991 [Dickson 92], introduziu o conceito de objetos FTAM: arqui
diretrios de arquivos e links. Na terminologia FTAM um diretrio de
quivos consiste em um mecanismo utilizado para agrupar arquivos, tini
diretrios de arquivos, segundo uma estrutura lgica, na forma de uma i
re. Um link um ponteiro para um outro objeto, que pode ser um arquive
um diretrio. O objeto diretrio de arquivos tem a funo de permitir qui
objetos sejam identificados por um nome de caminho (pathname), de fo
similar realizada em vrios sistemas reais, como por exemplo no UNI
no MS-DOS. O objeto link fornece um mecanismo simples que permite
um objeto aparea em mais de uma posio da rvore do sistema de arqui
sem que seja necessrio duplic-lo.

As propriedades de um arquivo FTAM so descritas pelos valore;

seus atributos. O atributo nome do arquivo identifica o arquivo de forma
ambgua. Esse atributo foi substitudo pelo atributo pathname no ade
Ftlestore Management [Dickson 92], Outros exemplos de atributos so: 1
de aes permitidas (leitura, escrita,, insero etc), lista de controle de ai
so, tamanho, data e hora de criao, identificao do criador etc.
Um arquivo, est vazio ou ento possui um contedo. O contede
arquivo consiste em um conjunto ordenado de unidades de dados. O Fl.
adotou a estrutura em rvore para organizar o acesso a seus arquivos. C
n da estrutura associado a, no mximo, uma unidade de dados. O FT.

>ennite que um arquivo seja decomposto em subrvores denominadas

ADU (File Access Data Units), que definem a unidade de acesso ao arquio. Se a estrutura em rvore do arquivo tiver apenas um nvel (o n raiz e
ima nica unidade de dados) o arquivo' dito ser no-estruturado. Se a arme tiver dois nveis (a raiz e vrias folhas) a estrutura se assemelha a de
m arquivo sequencial (flat).
7

O FTAM define uma srie de aes que podem ser executadas era um
rquivo. As aes podem afetar o arquivo como um todo, modificando apeas seus atributos (por exemplo, criao, remoo, e modificao de atribu)s), ou podem afetar partes do contedo do arquivo (por exemplo, leitura,
isero ou remoo de uma FADU em um arquivo).
Como mencionamos anteriormente, uma entidade de aplicao tem
:esso aos servios FTAM estabelecendo uma associao com outra entida; que fornea o acesso a um sistema de arquivos. A associao aps estabecida denominada associao FTAM. Uma associao FTAM atravessa
rios estgios, denominados regimes FTAM, nos quais diferentes servios
to fornecidos. No regime de associao de aplicao so estabelecidas e
icerradas as conexes. Durante o estabelecimento da associao uma srie
: parmetros so negociados entre o iniciador e o respondedor, entre eles, o
30 de servio que ser utilizado (transferncia, acesso, gerencamento).
esse regime so executadas algumas das operaes nos diretrios (ou gru)s de arquivos), como por exemplo, cpia, remoo e movimentao de
>jetos nos diretrios. No regime de seleo de arquivo especificado
slecionado ou criado) o arquivo ou objeto sobre o qual devem ser efetuaiS as operaes subsequentes. Nesse estgio podem ser executadas operares que manipulam os atributos do objeto (leitura e modificao) e operaes de cpia e movimentao de um objeto para uma localizao diferente
i sistema de arquivos. No regime de abertura de arquivo o arquivo
erto para operaes de acesso ou remoo de FADUs. No regime de
insferncia de dados, que iniciado aps o acesso a uma FADU, os dados
D transferidos para a FADU (acesso de escrita) ou da FADU (acesso de
tura). Note que os regimes so aninhados, sendo o regime de associao
aplicao o mais externo e o de transferncia de dados, o mais interno.
) longo de uma associao FTAM, a sequncia de aes solicitadas pelo
ciador define a sequncia de regimes que so atravessados na associao.
Maiores detalhes sobre o FTAM podem ser encontrados nos padres
3 857): Parte 1 (General Description), Parte 2 (Vjrtuai Filestore Definin) e Parte 4 (File Protocol Specification).

15.2.8 - Gerencamento de Redes OSI

O gerencamento de redes fornece mecanismos para monitorao, controle e coordenao da utilizao de recursos em um ambiente OSI. O gerencamento de redes OSI o tema dos pades ISO, e das recomendaes do
CCITT correspondentes, listados na Tabela 15.4.

Tabela 15.4: Padres para gerenciamento de redes

ISO
7498-4
10040
9595
9596
10165-1
10165-2
10165-4
10165-5
10164-1
10164-2
10164-3
10164-4
10164-5
10164-6
10164-7
10164-8
10164-9
10164-10
10164-11
10164-12
10164-13

CCITT
X.700
. X.701
X.710
X.711
X.720
X.721
X.722
X.723
X.730
X.731
X.732
X.733
X.734
X.735
X.736
X.740
X.741
X.742
X.737
X.745
X.738

Ttulo
Management Framework
Systems Management Overview
CMISE
CMIP
Management Information Model
Defmitions ot" Management Information
Gudelnes for Definition of Managed Objects
Generic Management Information
Object Management Function
State Management Function
Attributes for Representing Relationships
Alarm Reporting Management Function
Event Report Management Function
Log Management Function
Security Alarm Management Function
Security AuditTrail Function
Objects and Attributes for Access Control
Accounting Meter Function
Workload Monitoring Function
Test Measurement Function
Measurement Summarizatton Function

Os documentos que definem o gerencamento de redes OSI dividem

essa tarefa em cinco reas funcionais. O gerencamento de falhas define os
recursos que permitem a deteco, o isolamento, e a correo da operao
irregular dos componentes do ambiente OSI. O gerencamento de contabilizao prov os meios para que possa ser medida a utilizao dos recursos
gerenciados e para que possam ser calculados os custos dessa utilizao. O
gerencamento de configurao define os meios Utilizados para identificar,
coletar dados, supervisionar e controlar a configurao dos componentes do
ambiente OSI, no sentido de garantir a operao contnua do servio de co403

municao. O gerenciarnento de desempenho fornece os mecanismos utilizados para avaliar o comportamento dos recursos gerenciados e calcular a
eficincia das atividades de comunicao (por exemplo, o percentual de utilizao da capacidade de transmisso do meio de comunicao). Por fim, o
gerenciarnento de segurana enderea os aspectos relativos segurana no
acesso aos recursos utilizados no ambiente OSI.
O modelo de gerenciarnento OSI define um sistema integrado de gerenciarnento, que composto de agentes, gerentes e objetos gerenciados. A
Figura 15.10 mostra dois sistemas abertos interligados, um atuando como
agente e o outro como gerente.

Figura 15.10: ArquiCetura do modelo de gerenciarnento OSI.

O gerente coleta informaes sobre os objetos gerenciados junto aos

agentes, processa as informaes e, se for necessrio, solicita aos sistemas
agentes que executem operaes de gerenciarnento a fim de controlar o
funcionamento dos objetos gerenciados. O agente coleta informaes
relativas ao funcionamento dos objetos que gerncia, armazena essas
informaes na MIB (Management Information Base) e realiza operaes de
gerenciarnento sobre esses objetos atendendo a solicitaes enviadas pelo
gerente. Adicionalmente, o agente envia ao gerente notificaes geradas
404

pelos objetos g e' : " c l a d o s > o u notificaes sobre a ocorrncia de falhas no

funcionamento" 'K ob J et s gerenciados. Um objeto gerenciado uma
representao de r^ recur So real do ambiente OSI sujeito ao gerenciarnento.
Alguns exemplo S ^ u n i a entidade de uma camada, uma conexo, ou um
equipamento de v omurnCa o. Um objeto gerenciado definido por seus
atributos pelas c ? P e r a ^ e s q u e capaz de executar, pelas notificaes que
pode emitir e pe' ! i e u Racionamento com outros objetos gerenciados. O
conjunto dos obj e t O S erenciados constitui a MIB, que o repositrio
conceituai da fnfo | , m a ' a o ^ gerenciarnento de um sistema aberto.
O SMAP (S / s t e m Management Application Process) o software local
responsvel pela i ?xecu ^ 0 das funes de gerenciarnento dentro de um sistema aberto OSI t;om P ut;i dor, roteador etc). O SMAP utiliza os servios de
oerenciamento f^f"60'"05 pela entidade da camada de aplicao (SMAE)
nara ter acesso a(S P ararr,e tros que definem o comportamento dos recursos
do sistema com <-' '3Je^Vo de executar funes de gerenciarnento dentro das
reas funcionais i^ t a c ' a s anteriormente, coordenando sua operao com a de
em
outros SMAPs \cip^z^
outros sistemas abertos. O SMAP pode deaS
uni es
sempenhar tanto
* ^ de agente quanto as de gerente. A SMAE
(Svstems Mana^e'1116111 ^Pplication Entity) a entidade do nvel de aplicar.-,^ esponsavei
,mnnev.i yCAAATJ
' nte rcmbio de informaes de gerenciarnento com
ao
outros sistemas ^ ^MAfc residente no sistema agente comunica-se com a
SMAE residente j1 s * stetlla gerente atravs do protocolo de aplicao CMIP
Common Manac<<5nient ^ormation Protocol). O CMIP usado para transportar as onerac^ S ^ e Ser&nciamento3 e os resultados da execuo das operaes No modt?' 0 d e efenciamento OSI, cada camada gerenciada por
uma entidade de >1minad:> LME (Layer Management Entity). O LME de
uma determinada c a m a " a responsvel pelo mapeamento dos objetos de gerenciarnento abst*^ 0 8 ' antlazenados na MIB, em objetos e eventos reais.re,
i Ans gerncia
Lld
lativos a camada W b
Como outro^ entidades de aplicao, a SMAE definida como um
conjunto de ASE ^ inter ~ re ' ac ionados. Dois dos elementos utilizados so os'
ASEs de propsi^ 0 g e r a l toSE e ACSE. Um outro ASE que pode ser utilizado no SMAE - - ^ ^ Dentre os componentes do SMAE destacam-se
dois ASEs que f/> r n e c e m servios especficos de gerenciarnento de redes.
So eles o SMA?^ e C ^ I S E - O SMASE (System Management Application Service Eler/' ent ' ) lmPlementa funes bsicas nas reas funcionais de
Gerenciarnento de? ^ a ' n a s ' te contabilizao, de desempenho, de configurao e de se^uran^' ^ ^ ^ S E define a semntica e a sintaxe abstrata da in,

_ x

<el e

3 e x e m n i 0
" o u s a d a s para modificar atributos dos objetos gerenciados, />et usada
,
,, ,
' i' Dutos . aclHin usada para comandar a execuo de uma ao em um objeto
F
para ler o valor dos at..._,4,.
.
, ,
i
/ l"." ulau ' lI > Para criar e destruir instncias de objetos gerenciados, e event repon
J
gerenciado, create c dei

.'
, ,
, 0riu o ut ute .notificando a ocorrncia de uni evento em um objeto gerenciado.
que e passada, do a g e n t e
405

formao transferida nas unidades de dados do protocolo de gerenciamento

de aplicaes (Management Application Protocol Data Units MAPDUs).
Nas funes que requerem intercmbio de informaes de gerenciamento
com outros sistemas, o SMSE utiliza o CMISE. O CMISE fornece uma
coleo de funes bsicas de gerenciamento, comuns s cinco reas funcionais, comunicando-se com CMISEs residentes em outros sistemas para
intercambiar operaes de gerenciamento e notificar a ocorrncia de eventos.
O leitor interessado em informaes detalhadas sobre o gerenciamento
de redes OSI deve consultar os padres ISO, ou as recomendaes do
CC1TT, listadas na Tabela 15.4.

1 5 . 3 - 0 Nvel de Aplicao Internet TCP/IP

Na arquitetura Internet TCP/IP as aplicaes, especificadas em documentos denominados RFCs (Request For Cornments), so implementadas de
forma isolada. No existe um padro que defina como deve ser estruturada
uma aplicao, como no RM-OSI. As aplicaes trocam dados utilizando diretamente a camada de transporte (Figura 15.11), atravs de chamadas padronizadas, por exemplo atravs das APIs apresentadas no Captulo 12.

Modelo OSI

Alm de compartilhar o mesmo conjunto de primitivas de transporte,

muitas das aplicaes Internet TCP/IP adotam o modelo cliente/servidor.
Nesse modelo, a denominao servidor refere-se a qualquer aplicao que
oferea um servio a outra aplicao, servio que pode ser requisitado atravs da inter-rede. Os servidores aceitam solicitaes, que chegam pela interrede, executam o servio solicitado e enviam de volta o resultado aplicao solicitante. Uma aplicao torna-se um cliente quando envia uma solicitao a um servidor e espera por uma resposta.
A seguir faremos uma apresentao resumida das principais aplicaes
disponveis na arquitetura Internet TCP/IP, apresentadas na Figura 15.11.

15.3.1 - DNS (Domain Name System)

O DNS um esquema de gerenciamento de nomes, hierrquico e distribudo. O DNS define a sintaxe dos nomes usados na Internet, regras para
delegao de autoridade na definio de nomes, um banco de dados distribudo que associa nomes a atributos (entre eles o endereo IP) e um algoritmo distribudo para mapear nomes em endereos. O DNS especificado
nas RFCs 882, 883 e 973.
As aplicaes normalmente utilizam um endereo IP de 32 bits no sentido de abrir uma conexo ou enviar um datagrama IP. Entretanto, os usurios preferem identificar as mquinas atravs de nomes ao invs de nmeros.
Assim, necessrio um banco de dados que permita a uma aplicao encontrar um endereo, dado que ela conhece o nome da mquina com a qual deseja se comunicar.
Um conjunto de servidores de nomes mantm, o banco de dados com os
nomes e endereos das mquinas conectadas Internet. Na realidade este
apenas um tipo de informao armazenada no domain system (sistema de
domnios). Note que usado um conjunto de servidores interconectados, ao
invs de um nico servidor centralizado. Existem atualmente tantas instituies conectadas Internet que seria impraticvel exigir que elas notificassem uma autoridade central toda vez que uma mquina fosse instalada ou
trocasse de lugar. Assim, a autoridade para atribuio de nomes delegada a
instituies individuais. Os servidores de nome formam uma rvore, correspondendo estrutura institucional. Os nomes tambm adotam uma estrutura
similar.

Figura 15.11: Aplicaes Internet TCP/IP.

406

Um exemplo tpico o nome Copacabana.Inf.Puc-Rio.Br. Esse o

nome de uma mquina que fica no laboratrio do Departamento de Informtica da PUC do Rio de Janeiro. Para encontrar seu endereo Internet, pode
ser necessrio o acesso a at quatro servidores de nomes. Inicialmente deve
ser consultado um servidor central, denominado servidor raiz, para descobrir
407

onde est o servidor Br. O servidor Br o responsvel pela gerncia dos

nomes das instituies brasileiras ligadas Internet. O servidor raiz informa
como resultado da consulta o endereo IP de vrios servidores de nome para
o nvel Br (pode existir mais de um servidor de nomes em cada nvel, para
garantir a continuidade da operao quando um deles pra de funcionar).
Um servidor do nvel Br pode ento ser consultado, devolvendo o endereo
IP do servidor Puc-Rio. De posse do endereo de um servidor Puc-Rio
possvel solicitar que ele informe o endereo de um servidor Inf, quando, finalmente, pode-se consultar o servidor Inf sobre o endereo da mquina Copacabana. O resultado final da busca o endereo Internet correspondente
ao nome Copacabana.Inf.Puc-Rio.Br.
Cada um dos nveis percorridos referenciado como sendo um domnio. O nome completo Copacabana.Inf.Puc-Rio.Br um nome de domnio.
Assim como tambm so nomes de domnios, os nomes dos nveis superiores: Inf.Puc-Rio.Br, Puc-Rio.Br, e Br.
Na maioria dos casos, no necessrio ter acesso a todos os domnios
de um nome para encontrar o endereo correspondente, pois os servidores de
nome muitas vezes possuem informaes sobre mais de um nvel de domnio
(por exemplo, um servidor de nomes pode conter informaes sobre os domnios Br e Puc-Rio), o que elimina uma ou mais consultas. Alm disso, as
aplicaes normalmente tm acesso ao DNS atravs de um processo local
(servidor para as aplicaes e um cliente DNS), que pode ser implementado
de modo a guardar os ltimos acessos feitos e, assim, resolver a consulta em
nvel local. Essa abordagem de acesso, atravs de um processo local, simplifica e otimiza a tarefa das aplicaes no que tange ao mapeamento de nomes
em endereos, uma vez que elimina a necessidade de implementar, em todas
as aplicaes que fazem uso do DNS, o algoritmo usado para percorrer a rvore de domnios, descrito anteriormente.
O DNS no se limita a manter e gerenciar endereos Internet. Cada
nome de domnio um n em um banco de dados, que pode conter informa.es definindo vrias propriedades. Por exemplo, o tipo da mquina e a lista
de servios fornecidos por ela. O DNS permite que seja definido um alias
(nome alternativo) para o n. Tambm possvel utilizar o DNS para armazenar informaes sobre usurios, listas de distribuio ou outros objetos.
O DNS particularmente importante para o sistema de correio eletrnico (tema da Seo 15.3.5). No DNS so definidos registros que identificam a mquina que manipula as correspondncias relativas a um dado
nome, identificando assim onde um determinado usurio recebe suas correspondncias. O DNS pode ser usado tambm para definio de listas para
distribuio de correspondncia.

408

15.3.2 - FTP (File Transfer Protocol)

O FTP [Postei 85] permite que um usurio em um computador tr;
fira, renomeie ou remova arquivos remotos; ou crie, remova e modifique
retrios remotos. O FTP s permite a transferncia de arquivos comple
Antes de executar qualquer operao o usurio solicitante (cliente) envia
nome (login name) e sua senha para o servidor, que impede a execuc
qualquer operao, caso o usurio no tenha sido registrado.
A operao do FTP baseia-se no estabelecimento de duas cone*
entre o cliente (mdulo FTP que est solicitando o acesso a arquivos re
tos) e o servidor (mdulo FTP que fornece o acesso a seus arquivos loc
[Comer 91], como mostrado na Figura 15.12. Uma conexo, denomin
conexo de controle, usada para transferncia de comandos; e a outra,
nominada conexo de transferncia de dados, usada para a transferi
dos dados. A conexo de controle permanece aberta enquanto durar a ses
FTP. Durante uma sesso podem ser transferidos vrios arquivos, cada
deles em uma conexo de transferncia de dados estabelecida especif
mente para tal.

Figura 15.12; Conexes FTP de controle e de transferncia de dados.

O FTP permite que sejam transferidos arquivos do tipo texto ou bi
rio. Os arquivos do tipo texto so manipulados como sendo compostos
uma cadeia de caracteres ASCII ou EBCDIC. Os arquivos do tipo bina
so vistos como sendo formados por uma sequncia de octetos, que ,
transferidos sem qualquer converso. O FTP toma providncias para cc
patibilizar o cdigo de caracteres, os delimitadores de fim de linha e
quando transfere arquivos entre mquinas onde os dados tm representai
diferentes.

A arquiterura TCP/IP define, adicionalmente, um outro protocolo que

fornece um servio simplificado de transferncia de arquivos, o TFTP
(Trivial File Transfer Protocol) [Sollins 81]. O TFTP restringe sua operao
simplesmente a transferncias de arquivos, no implementando mecanismos
de autenticao e operando em uma nica conexo. O TFTP utiliza o UDP
para o transporte de blocos de dados de tamanho fixo. Como o servio fornecido pelo UDP no garante a entrega dos blocos ao destinatrio, o TFTP
utiliza o procotolo de bit alternado para transmitir seus blocos.

15.3.3 - NFS (Network File System)

O NFS [SUN 89], desenvolvido pela Sun Microsystems, permite que
um sistema tenha acesso a arquivos localizados remotamente de um modo
integrado e transparente. O NFS fornece a iluso que os discos, impressoras,
ou outros dispositivos, fisicamente localizados em um sistema remoto, esto
diretamente conectados ao sistema local.
As aplicaes que executam em uma mquina onde instalado um cliente NFS (Figura 15.13), simplesmente "acham" que a mquina possui
alguns dispositivos adicionais. Esses dispositivos virtuais adicionais so
montados (associados) em dispositivos fisicamente localizados em outras
mquinas. O NFS permite, por exemplo, que estaes que no possuam
dispositivos de armazenamento (diskless), ou que possuam dispositivos com
pouca capacidade, armazenem informaes de modo transparente em
equipamentos que possuam espao disponvel. Um outro benefcio desse
mecanismo permitir que usurios trabalhando "em mquinas diferentes
possam compartilhar o acesso a arquivos comuns.

. O NFS cria um sistema de arquivos virtual que estende o sistema de

arquivos local. O sistema de arquivos virtual possui entradas identificando
os arquivos remotos, de forma no ambgua, no servidor NFS onde eles esto fisicamente localizados. A Figura 15.13 mostra como o NFS incorporado a um sistema.
Quando uma aplicao que est executando em uma mquina realiza
uma chamada ao sistema operacional para abrir um arquivo, para ler ou
gravar dados em um arquivo, o mecanismo que controla o acesso ao sistema
de arquivos intercepta a operao e verifica se o acesso local ou remoto.
Se o acesso for local, o redirecionador entrega a operao para o sistema de
arquivos local, que responsabiliza-se por sua execuo. Se o acesso diz respeito a um arquivo localizado em um dispositivo remoto, o redirecionador
entrega a solicitao ao cliente NFS, que a envia, utilizando o protocolo de
transporte UDP, ao servidor NFS. O servidor processa o pedido e envia os
resultados para o cliente NFS, que os entrega aplicao.
Do ponto de vista do programador, o NFS no acrescenta nenhum procedimento especfico para o acesso a arquivos remotos. Assim, quando o
NFS instalado em uma mquina, os programas fazem o acesso aos arquivos remotos com as mesmas chamadas de procedimentos que utilizam para
ter acesso aos arquivos locais.
O NFS, ao contrrio das outras aplicaes Internet, no implementado por um nico utilitrio, sendo dividido em trs componentes: o protocolo
NFS propriamente dito, uma ferramenta genrica que controla a execuo de
chamadas a procedimentos remotos (Remote Procedure Call RPC), e uma
terceira ferramenta que compatibiliza formatos diferentes de representao
de dados denominada XDR (Externai Data Representation). A diviso foi
realizada para permitir que o RPC e o XDR pudessem ser utilizados em
outras aplicaes. Os mecanismos RPC e XDR so descritos nos itens que
se seguem.

15.3.3.1 - RPC (Remote Procedure Call)

Figura 15.13: Arquitetura de um cliente NFS.

410

O mecanismo RPC [SUN 88] foi projetado para facilitar o desenvolvimento de aplicaes distribudas baseadas no modelo de interao clienteservidor. O mecanismo usado da seguinte forma [Comer 91]: no mdulo
cliente, o programador declara alguns dos procedimentos como sendo remotos, forando o compilador a incorporar chamada de procedimento, o cdigo que repassa os argumentos da chamada ao cliente RPC. No mdulo
servidor, so implementados os procedimentos a serem compartilhados, que
so declarados como procedimentos servidores. Quando o programa cliente
faz uma chamada a um procedimento remoto, os argumentos da chamada
so entregues ao cliente RPC, que compe uma mensagem e a envia ao ser411

vidor, passando ento a aguardar o retorno do resultado. O servidor RPC, ao

receber uma mensagem invocando a execuo de um procedimento, dispara
sua execuo e, ao seu trmino, envia os resultados obtidos de volta para o
cliente RPC. O cliente RPC, ao receber de volta a mensagem com o resultado da execuo do procedimento remoto, entrega esses resultados ao processo de aplicao, colocando-os nos respectivos argumentos da chamada de
procedimento. Do ponto de vista do processo de aplicao, o procedimento
executado como se fosse local. O RPC esconde todos os aspectos do
intercmbio de mensagens relativos execuo remota do procedimento.

15.3.3.2 - XDR (Externai Data Representation)

A ferramenta XDR [SUN 87] permite que os programadores escrevam
aplicaes distribudas onde so intercambiados dados entre mquinas que
os representam de forma distinta, sem que seja necessrio escrever procedimentos para compatibilizaras representaes.
A soluo adotada na ferramenta XDR foi a definio de uma representao independente de qualquer mquina que usada para codificar os
dados intercambiados.
Quando deseja transmitir dados, um programa de aplicao chama os
procedimentos XDR que convertem a representao local para a representao de transferncia e, em seguida, transmite os dados convertidos. O processo que recebe os dados chama os procedimentos XDR, que convertem a
representao de transferncia para a representao local especfica.
Os programadores no precisam acrescentar ao cdigo dos seus programas as chamadas aos procedimentos XDR. Ao invs disso, eles enviam
ao compilador XDR as instrues do programa, nas quais declaram os dados
que devero ser transformados, e o compilador automaticamente acrescenta
ao cdigo do programa as chamadas aos procedimentos XDR que so necessrias.

15.3.4-TELNET
O protocolo TELNET [Postei 83] permite que um usurio utilizando
uma mquina A estabelea uma sesso interativa com uma mquina (B) na
rede. A partir da, todas as teclas pressionadas na mquina A so repassadas
para a mquina B como se o usurio estivesse utilizando um terminal ligado
diretamente a ela. Os comandos digitados na mquina A so processados na
mquina B, e o resultado de sua execuo enviado de volta para ser exibido no monitor da mquina A.

412

O mdulo cliente do TELNET permite que o usurio identifique a mquina a qual deseja se conectar pelo nome ou por seu endereo IP. A secunda opo torna possvel o estabelecimento de conexes remotas em ambientes onde no seja possvel fazer a associao entre nomes e endereos IP
(por exemplo, quando o servidor de nomes est inoperante).
O protocolo TELNET construdo com base em trs ideias principais:
o conceito de terminal virtual de rede, o princpio de negociao de opes,
e o tratamento equivalente de terminais e processos.
Quando uma conexo TELNET estabelecida, assume-se que ambas
as extremidades esto ligadas a um terminal virtual de rede (Network Virtual Terminal- NVT). Um NVT um dispositivo lgico que fornece uma
representao padronizada de um terminal. Essa abordagem elimina a necessidade das mquinas participantes da conexo conhecerem as caractersticas do terminal utilizado por seus parceiros. Tanto o servidor, quanto o
cliente, mapeiam as caractersticas e convenes de seus terminais locais nas
caractersticas do NVT, e assumem que seu parceiro na conexo faz o
mesmo.
O princpio da negociao de parmetros permite que os usurios envolvidos em uma conexo negociem opes que definem o comportamento
do terminal virtual. Dentre as opes negociadas esto o formato de representao dos caracteres utilizados, e o modo de operao (half-duplex ou
full-duplex).
Uma vez que o protocolo TELNET trata os terminais e o processo remoto de forma equivalente e simtrica, o cliente no precisa ser necessariamente um terminal, podendo ser um processo de aplicao qualquer. Uma
outra implicao da simetria da conexo que ambas as extremidades da
conexo podem tomar a iniciativa da negociao de opes, o que no seria
possvel em uma arquitetura cliente/servidor bsica, onde o servidor passivo, ou seja, s entra em funcionamento em resposta a solicitaes feitas
pelo cliente.
A Figura 15.14 ilustra o funcionamento de uma conexo TELNET.
Quando o programa TELNET comea a ser executado em uma mquina, ela
passa a funcionar como cliente TELNET, junto com o comando que dispara
a execuo do TELNET, o usurio informa o nome, ou o endereo IP. da
mquina qual deseja se conectar. Uma conexo TCP estabelecida, e a
mquina de destino assume o papel de servidor TELNET. Uma vez estabelecida a conexo, todas as teclas pressionadas pelo usurio so capturadas
pelo cliente TELNET e enviadas, atravs da conexo TCP, ao processo servidor TELNET na mquina remota. O servidor processa as teclas e envia de
volta para o cliente os caracteres que devem ser mostrados no vdeo do terminal.
413

em seu spool (rea do dispositivo de armazenamento), junto com o horrio

do armazenamento e a identificao do remetente e do destinatrio. A transferncia da mensagem executada por um processo em background, permitindo que o usurio remetente, aps entregar a mensagem ao sistema de correio eletrnico, possa executar outras aplicaes.

Figura 15.14: Conexo TELNET,

15.3.5 - SMTP (Simple Mail Transfer Protocol)

O SMTP o protocolo usado no sistema de correio eletrnico na arquitetara internet TCP/IP. A Figura 15.15 mostra os componentes conceituais
utilizados no sistema de correio eletrnico.

O processo de transferncia de mensagens, executando em background,

mapeia o nome da mquina de destino em seu endereo IP, e tenta estabelecer uma conexo TCP com o servidor de correio eletrnico da mquina de
destino. Note que o processo de transferncia atua como cliente do servidor
de correio eletrnico. Se a conexo for estabelecida, o cliente envia uma
cpia da mensagem para o servidor, que a armazena em seu spool. Caso a
mensagem seja transferida com sucesso, o servidor avisa ao cliente que recebeu e armazenou uma cpia da mensagem. Quando recebe a confirmao
do recebimento e armazenamento, o cliente retira a cpia da mensagem que
mantinha em seu spool local. Se a mensagem^ por algum motivo, no for
transmitida com sucesso, o cliente anota o horrio da tentativa e suspende
sua execuo. Periodicamente, o cliente acorda e verifica se existem mensagens a serem enviadas na sua rea de spool e tenta transmiti-las. Se uma
mensagem no for enviada por um perodo, por exemplo de dois dias, o
servio de correio eletrnico devolve a mensagem ao remetente, informando
que no conseguiu transmiti-la.
Em geral, quando um usurio se conecta ao sistema, o sistema de correio eletrnico ativado para verificar se existem mensagens na caixa postal
do usurio.4 Se existirem, o sistema de correio eletrnico emite um aviso
para o usurio que, quando achar conveniente,, ativa o mdulo de interface
com o usurio para receber as correspondncias.
Uma mensagem SMTP divide-se em duas partes: cabealho e corpo,
separados por uma linha em brancp. No cabealho so especificadas as informaes necessrias para a transferncia da mensagem. O cabealho
composto por linhas, que contm uma palavra-chave seguida de um valor.
Por exemplo, identificao do remetente (palavra-chave "to:" seguida do seu
endereo), identificao do destinatrio, assunto da mensagem etc. No corpo
so transportadas as informaes da mensagem propriamente dita. O formato do corpo livre e as mensagens so transferidas no formato texto.

Figura 15.IS: Arquitetura do correio eletrnico SMTP.

Um usurio, ao desejar enviar uma mensagem, utiliza o mdulo interface com o usurio para compor a mensagem e solicita ao sistema de correio
eletrnico que a entregue ao destinatrio. Quando recebe a mensagem do
usurio, o sistema de correio eletrnico armazena uma cpia da mensagem
414

Os usurios do sistema de correio eletrnico so localizados atravs de

um par de identificadores. Um deles especfica o nome da mquina de destino e o outro identifica a caixa postal do usurio. Um remetente pode enviar
simultaneamente vrias cpias de uma. mensagem, para diferentes destinatrios utilizando o conceito de lista de distribuio (um nome que identifica
4
A caixa postal do usurio uma rea no spool do servidor de correio eletrnico usada para
armazenar as mensagens cie um usurio especfico.

415

um grupo de usurios). O formato dos endereos eletrnicos SMTP o seguinte:

nome local nome do domnio
onde o nome do domnio identifica o domnio ao qual a mquina de destino
pertence (esse endereo deve identificar um grupo de mquinas gerenciado
por um servidor de correio eletrnico). O nome local identifica a caixa postal do destinatrio.
O SMTP especifica como o sistema de correio eletrnico transfere
mensagens de uma mquina para outra. O mdulo interface com usurio e a
forma como as mensagens so armazenadas no so definidos pelo SMTP.
O sistema de correio eletrnico pode tambm ser utilizado por processos de
aplicao para transmitir mensagens contendo textos.

15.3.6 - WWW (World-Wide Web)

O WWW foi desenvolvido para permitir o acesso a informaes organizadas na forma de um hpertexto,5 que engloba documentos armazenados
em servidores espalhados por toda a inter-rede.
Um programa cliente WWW executa no computador do usurio [Lee
94]. Quando entra em execuo, ele mostra um objeto WWW, normalmente
um documento com texto e possivelmente imagens, onde algumas das frases
e imagens so destacadas (highlighted). A seleo de uma rea destacada
(por exemplo, por um clique do mouse), denominada ncora, faz com que o
programa cliente busque outro objeto WWW (relacionado ncora), possivelmente localizado em uma outra mquina, um servidor WWW. O objeto
recuperado normalmente um outro hipertexto, podendo o processo cie navegao prosseguir at que a execuo do programa cliente seja encerrada.
Existem vrios tipos de clientes WWW. Como a informao transmitida na rede num formato lgico padro, cada cliente pode interpret-la do
modo mais natural possvel para uma dada plataforma, utilizando de forma
otimizada as fontes, cores e outros recursos de interface com o usurio disponveis na plataforma.
Os objetos WWW, que podem ser menus, documentos (hipertextos),
imagens etc. so endereados atravs de strings denominados URIs

(Universal Resource Identifiers). Por exemplo, o URI da pgina principal

projeto WWW
http://info.cern. ch/hypertextAVWW/TheProject. html
O prefixo http indica o espao de endereamento e define a interpn
o do restante do string. No exemplo, deve ser usado o protocolo H T
contendo o restante do string, o endereo do servidor que deve ser cont
tado e um substring que deve ser entregue ao servidor para que ele possa
calizar um determinado objeto.
A sintaxe URI permite que os objetos sejam endereados no ape;
via HTTP, mas tambm por outros protocolos para acesso de informai
em redes (FTP, Gopher etc). Permite tambm que extenses para n c
protocolos possam ser desenvolvidas.
O HTTP (Hypertext Transfer Protocol) um protocolo usado p,
transferncia de informaes no WWW. Os dados transferidos'pelo HT
podem ser texto no estruturado, hipertextos, imagens, ou qualquer ou
tipo de dados. O HTTP pode ser usado para fazer acesso a documentos <
um conjunto no limitado e extensvel de formatos. Para que isso seja pos
vel, o cliente, ao solicitar a transferncia de uma cpia de um objeto, err
uma lista com os formatos que pode manipular. O servidor responde envi
do o objeto solicitado codificado em um dos formatos informados pt
cliente,
O HTTP um protocolo Internet semelhante ao FTP. Ele utiliza ui
conexo TCP para cada transferncia de objeto. A conexo s mantida e
quanto dura a transferncia.
Apesar da habilidade do HTTP em negociar formatos, o WWW post
uma linguagem bsica para intercmbio de hipertextos, denominada HTJV
(Hypertext Markup Language). A linguagem HTML compatvel com o p
dro SGML (Standard General Markup Language). Um documento HTIV
vlido, acompanhado das declaraes SGML que definem o HTML Dl
(Document Type Definition), pode ser analisado sintaticamente por u
parser SGML.
A Figura 15.16-a mostra o n WWW da PUC do Rio de Janeiro, e
Figura 15.16-b o n com informaes sobre a ps-graduao, aps uma n
vegao atravs da ncora "ps-graduao".

ND modelo conceituai de dados WWW, um hipertexto um documento composto por um

conjunto de ns (fragmentos de informao em diversas mdias, por exemplo, imagem, texto etc.)
interligados por elos definidos por um par de ncoras. As ncoras podem ser um n ou uma regio dentro
de"urn n.

416

41

a) Home page da PUC do Rio de Janeiro

15.3.7 - SNMP (Simple Network Management Protocol)

O sistema de gerenciamento de redes da arquitetura Internet TCP/IP
opera na camada de aplicao e baseia-se no protocolo SNMP (Simple Network Management Protocol). Os padres que definem a estrutura de gerenciamento de redes Internet so descritos nos documentos: RFC 11,55
Stracture of Management Information; RFC 1156 Management Information Base; e RFC 1157 Simple Network Management Protocol.
Como no esquema de gerenciamento OSI, os processos que implementam as funes de gerenciamento Internet atuam como agentes ou gerentes.
Os agentes coletam junto aos objetos gerenciados as informaes relevantes
para o gerenciamento da rede. O gerente processa as informaes recolhidas
pelos clientes, com o objetivo de detectar a presena de falhas no funcionamento dos componentes da rede (hosts, gateways, processos executando os
protocolos de comunicao e t c ) , para que possam ser tomadas providncias
no sentido de contornar os problemas que ocorrem como consequncia das
falhas.

b) Pgina com informaes sobre a ps-graduao

\ ISJ. J.

NCSAMosfllc:DDCumanlVlBW

Um objeto gerenciado representa um recurso, que pode ser um sistema

hospedeiro (estao de trabalho, servidor de terminais etc), um gateway ou
um equipamento de transmisso (modems, pontes, concentradores etc).
Cada objeto gerenciado visto como uma coleo de variveis cujo valor
pode ser lido ou alterado.
O gerente envia comandos aos agentes, solicitando uma leitura no valor das variveis dos objetos gerenciados (get e response), ou modificando
seu valor (pui). A modificao do valor de uma varivel pode ser usada para
disparar indiretamente a execuo de operaes nos recursos associados aos
objetos gerenciados (por exemplo, uma reiniciao). Na troca de informaes entre o gerente e o agente, so aplicados mecanismos de autenticao
para evitar que usurios no autorizados interfiram no funcionamento da
rede. A troca de mensagens entre o gerente e o agente definida pelo protocolo SNMP. O SNMP define o formato e a ordem que deve ser seguida no
intercmbio de informaes de gerenciamento.
As informaes sobre os objetos gerenciados so armazenadas na MIB
(Management Information Base), que contm informaes sobre o funcionamento dos hosts, dos gateways, e dos processos que executam os protocolos de comunicao (IP, TCP, ARP e t c ) . A MIB especificada em ASN. 1.

Figura 15.16: Exemplos de documentos WWW.

418

O funcionamento do SNMP, ilustrado na Figura 15.17, baseia-se na

troca de operaes que permitem que-o gerente solicite que o agente lhe informe, ou modifique, o valor de uma varivel de um objeto na-MIB. O
SNMP define tambm uma operao (trap), que permite que um agente informe ao gerente a ocorrncia de um evento especfico.
419

Captulo 1 6
Figura 15.17: Modelo de gerenciamento SNMP,

Com o objetivo de permitir o uso do esquema de gerenciamento OSI

em redes que adotam a arquitetura Internet TCP/IP, foi definido o protocolo
de gerenciamento CMOT (CMIP Over TCP/IP). O CMOT utiliza o servio
CMIS (Common Management Information Service) e o protocolo CMIP
(Common Management Information Protocol) funcionando sobre uma conexo TCP/IP. O CMOT descrito na RFC 1095.

Sistemas
Operacionais
de Redes
Quando foram construdos os primeiros computadores, seus usurios
programavam as aplicaes em linguagem de mquina, interagindo diretamente com o hardware (Figura 16.1 -a). Logo percebeu-se que algumas tarefas bsicas se repetiam nas mais diversas aplicaes. Por exemplo, transferncia de dados entre a memria e os dispositivos de entrada ou sada
(impressoras, unidades de armazenamento etc). Foi a partir da que surgiram os sistemas operacionais (Figura 16.1-b). Podemos definir um sistema
operacional (SO) como sendo um software composto de um conjunto de rotinas que fornecem servios bsicos de uso geral que simplificam a utilizao dos recursos de hardware de uma mquina. As rotinas ou mdulos que
compem um SO fornecem servios como: gerenciamento do uso do processador, alocao dos processos (programas em execuo) na memria principal, controle do acesso aos dispositivos de entrada e sada, alocao de informaes nos dispositivos de armazenamento (gerenciamento do sistema de
arquivos) etc.
Inicialmente, os computadores eram mquinas carssimas que centralizavam em um nico ponto o processamento das aplicaes de vrios usurios, e muitas vezes de toda uma organizao. Com a reduo do custo do
hardware, e a introduo dos microcomputadores no cenrio da informtica,
a estrutura centralizada cedeu lugar a uma estrutura totalmente distribuda.
Nessa estrutura diversos equipamentos dos mais variados portes processam
informaes de forma isolada, o que acarreta uma srie de problemas, que

420

421

foram discutidos no Captulo 1. Dentre os problemas apresentados, destacou-se a duplicao desnecessria de recursos de hardware (impressoras,
discos etc.) e de software (programas, arquivos de dados etc).

a) Interao direta das aplicaes dos usurios com o hardware

b) Interao indireta das aplicaes dos usurios com o hardware atravs do sistema
operacional

Do ponto de vista do hardware dos computadores, a modificao necessria para viabilizar sua ligao rede foi a introduo de um dispositivo
de entrada e sada adicional, responsvel pela interface do computador com
o sistema de comunicao: nos computadores atuais a placa de interface de
rede.
A referida modificao no hardware implicou na necessidade de ajustar os sistemas operacionais para o novo ambiente de processamento, que
tornou possvel a troca de informaes entre as estaes interligadas, e a
utilizao de recursos de hardware e software remotos.
Note que, quando surgiram as redes, os computadores, antes funcionando isoladamente, j possuam seus respectivos sistemas operacionais locais SOL. Portanto, uma premissa bsica do software introduzido para
fornecer os novos servios, foi perturbar o menos possvel o ambiente local,
principalmente na interface que esse ambienteoferecia a seus usurios.
Nesse contexto surgiram os sistemas operacionais de redes (SOR)
como uma extenso dos sistemas operacionais locais, complementando-os
com o conjunto de funes bsicas, e de uso geral, necessrias operao
das estaes, de forma a tornar transparente o uso dos recursos compartilhados, como mostra a Figura 16. l-c. Dentre as funes do sistema operacional
de rede destaca-se, assim, o gerenciamento do acesso ao sistema de comunicao e, consequentemente, s estaes remotas para utilizao de recursos
de hardware e software remotos.

c) Adio das funes do sistema operacional de rede s funes dos sistemas operacionais locais

Figura 16.1: Sistemas Operacionais.

Nesse cenrio surgiram as redes de computadores, onde um sistema de

comunicao foi introduzido para interligar os equipamentos de processamento de dados {estaes de trabalho), antes operando isoladamente, com o
objetivo de permitir o compartilhamento de recursos.

422

16,1 - Conceito de Redireeionador

Como salientado nos pargrafos anteriores, transparncia um requisito fundamental dos sistemas operacionais de redes. Nesse sentido, os
SORs devem atuar de forma que os usurios utilizem os recursos de outras
estaes da rede como se estivessem operando localmente. A soluo encontrada para estender o sistema operacional das estaes da rede, sem modificar sua operao local, foi a introduo de um mdulo redireeionador. O
redireeionador funciona interceptando as chamadas feitas pelas aplicaes
ao sistema operacional local, desviando aquelas que dizem respeito a recursos remotos para o mdulo do sistema operacional de rede, responsvel pelos servios de comunicao, que providencia o acesso ao dispositivo remoto (Figura 16.2). Para as aplicaes do usurio, a instalao do sistema operacional de rede percebida apenas pela adio de novos recursos {recursos
virtuais) aos que elas possuam anteriormente. A interface utilizada pelas
aplicaes para ter acesso aos recursos, tanto locais quanto remotos, permanece, assim, inalterada.

423

Nas estaes que possuem o mdulo cliente, o SOR, ao receber ut

pedido de acesso a um recurso localizado em outra estao da rede, mon(
uma mensagem contendo o pedido e a envia ao mdulo servidor da esta
onde ser executado o servio. Na estao remota, o SOR recebe a menst
gem, providencia a execuo do servio solicitado, monta uma mensagei
com o resultado da execuo (nos casos onde o pedido envolve a devolu
de dados podem ser necessrias mais de uma mensagem), e a envia de volt
para o SOR na estao requerente. Quando o SOR na estao que requisito
o servio recebe a mensagem transportando a resposta, ele faz sua entrega
aplicao local.
a) Sistema operacional local

b) Sistema operacional local acrescido das

funes de comunicao do sistema
operacional de rede

Figura 16.2: Adio das funes de comunicao ao sistema operacional local.

O redirecionador, como apresentado, foi o mecanismo bsico sobre o

qual foram desenvolvidos os sistemas operacionais de rede. Entretanto,
como veremos ao longo deste captulo, ele no a nica forma utilizada pelas aplicaes para interagir com o sistema operacional de rede e, atravs
dele, com os recursos de hardware e software de outras estaes na rede.

Note que as funes necessrias ao SOR nos mdulos clientes so dife

rentes das funes nos mdulos servidores. No mdulo cliente, o SOR re;
tringe-se praticamente a fornecer servios de comunicao de pedidos para
servidor e a entregar as respostas s aplicaes. No mdulo servidor, alr
das funes de comunicao, vrios outros servios so executados, com
veremos na Seo 16.4. Um desses servios o controle do acesso aos re
cursos compartilhados por vrios usurios atravs da rede, para evitar, pc
exemplo, que um usurio no autorizado apague arquivos que no lhe pei
tencem.
Resumindo, podemos classificar os mdulos de um SOR instalados na
estaes em dois tipos:
1. SORC: mdulo cliente do sistema operacional.

16.2 - Arquiteturas Peer-to-Peer e Cliente-Servidor

A interface entre as aplicaes e o sistema operacional baseia-se, usualmente, em alteraes solicitao/resposta, onde a aplicao solicita um
servio (abertura de um, arquivo, impresso de um bloco de dados, alocao
de uma rea de memria etc.) atravs de uma chamada ao sistema operacional. O sistema operacional, em resposta chamada, executa o servio solicitado e responde, informando o status da operao (se foi executada com sucesso ou no) e transferindo os dados resultantes da execuo para a aplicao, quando for o caso.
No modo de interao Cliente-Servidor, a entidade que solicita um
servio chamada cliente e a que presta o servio o servidor. A interao
cliente-servdor constitui-se no modo bsico de interao dos sistemas operacionais de redes. As estaes que disponibilizam a outras estaes o acesso a seus recursos atravs da rede, devem possuir a entidade (ou mdulo)
servidor. As estaes que permitem que suas aplicaes utilizem recursos
compartilhados com outras estaes, devem possuir a entidade (ou mdulo)
cliente.

424

2. SORS: mdulo servidor do sistema operacional.

Na Arquitetura Peer-to-Peer, em todas as estaes o sistema operacio
nal de redes possui os dois mdulos: SORC e SORS. A Figura 16.3 ilustra
arquitetura, mostrando os mdulos cliente e servidor complementando (
sistema operacional local das estaes da rede.

Figura 16.3: Arquitetura Peer-to-Peer.

42E

i)

Na arquitetura cliente-servidor, as estaes da rede dividem-se em estaes clientes, que s possuem as funes do mdulo cliente acopladas ao
seu sistema operacional local, e em estaes servidoras. As estaes servidoras necessariamente possuem as funes do mdulo servidor e podem,
opcionalmente, possuir tambm as funes do mdulo cliente
(possibilitando, por exemplo, que um servidor seja cliente de outro, caso tpico da relao entre servidores de impresso de arquivos, que sero apresentados na Seo 16.4). A arquitetura cliente-servidor possui duas variaes, definidas pela forma como so utilizados os servidores.
Na arquitetura cliente-servidor com servidor dedicado, as estaes
servidoras necessariamente incluem um mdulo SORS e, opcionalmente, um
mdulo SORC, que, se existir, s pode ser usado pelo mdulo SORS para
permitir que este seja cliente de outro servidor. Nessa arquitetura, geralmente, as estaes servidoras no permitem usurios locais, sendo integralmente dedicadas ao atendimento de pedidos enviados pelas estaes clientes atravs da rede (Figura 16.4).

Figura 16.4: Arquitetura cliente-servidor com servidor dedicado.

Na arquitetura cliente-servidor com servidor no dedicado, as estaes servidoras possuem um sistema operacional local que estendido por
um mdulo SORS e um mdulo SORC, O mdulo SORC pode ser usado
tanto pelo SORS, quanto pelas aplicaes dos usurios locais da estao
servidora. Assim, os recursos locais das estaes servidoras so compartilhados tanto pelos usurios atendidos pelo sistema operacional local (que
tambm podem ter acesso a servios de outros servidores) quanto pelos usurios remotos que fazem pedidos ao SOR atravs da rede. Voltamos a salientar que, como a estao servidora possui um mdulo SORC, seu SORS pode
ser cliente de outra estao servidora, como em alguns servidores dedicados.
A Figura 16.5 ilustra a arquitetura mostrando o relacionamento entre os mdulos SORC, SORS e SOL nas estaes clientes e servidoras.
426

( )

> )

J
<)
- )
").
.')

Figura 16.5: Arquitetura cliente-servidor com servidor no dedicado.

)
)

16.3-Mdulo Cliente

)
)

Algumas premissas bsicas nortearam a introduo do mdulo cliente

no sistema operacional de rede. Uma delas, discutida na introduo deste
captulo, foi a transparncia. Vimos que a soluo adotada foi a introduo
de um redirecionador que manteve inalterada a interface usada pelas aplicaes, aproveitando-a para permitir, inclusive, o acesso aos dispositivos remotos. Uma outra.foi manter a utilizao dos recursos (memria, processador etc.) dos clientes em nveis tais que o usurio no fosse atrapalhado em
suas tarefas locais.

A Figura 16.6 mostra, como exemplo, um diagrama com os componentes de um mdulo cliente DOS em uma rede local de computadores. Nessa
figura, o redirecionador intercepta a interrupo INT 21 (em hexadecimal),
usada pelas aplicaes DOS para solicitar a execuo de servios. Quando o
redirecionador detecta que o acesso diz respeito a um recurso remoto, ele
repassa a solicitao para o driver de protocolo.
O driver de protocolo, que consiste usualmente em uma implementao
dos protocolos de comunicao (do nvel LLC ao nvel de transporte) usados
para controlar a transferncia de dados na rede, adiciona as informaes de
controle de seus protocolos mensagem e, em seguida, entrega a mensagem
ao driver da placa de interface de rede. O driver da placa usualmente implementa a interface de acesso ao hardware da placa de rede, comandando a
placa a enviar, atravs do meio fsico, a mensagem do mdulo cliente para o
mdulo servidor, em uma estao remota.

)
).
)
)
)
)

i
)
),
)
>
)
)
)
)
)
)

427

gerncia de bancos de dados, o suporte para impresso, a traduo de nomes

simblicos em endereos fsicos, a concentrao de terminais, a monitorao
de redes, a criptografia, o correio eletrnico e os servios de comunicao.
Nesta altura o leitor j deve estar confuso com tanta definio do que
vem a ser servidor. O pior que a literatura em geral bastante confusa com
relao a esse tema. Vamos tentar esclarecer um pouco o seu uso, pelo menos no contexto deste livro. Definimos mdulo servidor como a entidade do
SOR que torna disponveis os recursos de uma estao aos usurios da rede.
Chamamos de estao servidora, na arquitetura cliente-servidor, a estao
que possui pelo menos o mdulo servidor em seu SOR. A partir de agora
estaremos chamando de servidor de X ao subrndulo do mdulo servidor de
um sistema operacional de rede (SORS) que implementa o servio X.

Figura 16.6: Estrutura de uma estao Cliente DOS e de um Servidor Dedicado.

Na estao remota onde reside o mdulo servidor, o pedido recebido
pela placa de rede entregue ao driver de protocolo pelo driver da placa. O
driver de protocolo entrega, finalmente, a mensagem ao sistema operacional
de rede do servidor. O sistema operacional do servidor executa o pedido e
entrega a resposta ao driver de protocolo para que ele a envie de volta para o
mdulo cliente. Quando a resposta chega estao do mdulo cliente, ela
repassada pelo driver da placa para o driver de protocolo, e por este para o
redirecionador, que, finalmente, entrega a resposta ao processo de aplicao.
Na Seo 16.5 os componentes aqui apresentados sero novamente
discutidos, s que no contexto do modelo Se referncia OSI.

16.4 - Mdulo Servidor

Uma das funes bsicas das redes locais que viemos constantemente
frisando o compartilhamento de. recursos caros e especializados
(equipamentos, programas, bancos de dados, ou vias de comunicao), isto
, servios.
Vrios servios so.usuais para todas as aplicaes, fazendo com que
mdulos de propsito especfico dos SORS fossem projetados de forma a
melhor oferec-los. Estaes que possuem tais mdulos, chamados por
simplificao de servidores, so distinguidas das outras estaes pelo software de suporte ao servio e algum hardware especial que contenham. Entre
os servios mais oferecidos podemos citar: o armazenamento de arquivos, a
428

Servidores podem ser tambm clientes de outros servidores da rede.

Por exemplo, um servidor de impresso pode ser cliente de um servidor de
arquivos, ao fornecer servios aos seus prprios clientes. Servio de correio
eletrnico um outro exemplo de servidor que muitas vezes realizado utilizando os servios de armazenamento de arquivo de um outro servidor.
Nesta seo citaremos alguns servidores, salientando os servios que
podem oferecer. Nosso objetivo dar apenas uma noo das funes que
podem ser realizadas, razo pela qual faremos uma explanao introdutria,
sem descrever detalhes dos servidores e nem discutir implementaes. No
decorrer do captulo citaremos algumas referncias especializadas, que podero ser consultadas dependendo do interesse de cada leitor.

16.4.1 - Servidor de Arquivos

O servidor de arquivos tem como funo oferecer a seus clientes os
servios de armazenamento e acesso a informaes, e de compartilhamento
de discos.
Servidores de arquivos controlam unidades de disco ou outras unidades
de armazenamento, sendo capazes de aceitar pedidos de transaes das estaes clientes e atend-los utilizando seus dispositivos de armazenamento de
massa. Gerenciam assim, um sistema de arquivos, que pode ser utilizado
pelo usurio em substituio ou em adio ao sistema de arquivos existente
na prpria estao.
Em geral, o sistema de arquivos possui uma estrutura hierrquica de dir
retrios, proteo de arquivos individuais e de diretrios atravs de palavraschave (proteo especial para direitos de acesso conforme definido pelo
usurio: acesso pblico, acesso por grupo ou acesso privado), chaves para
atualizao simultnea e segura de arquivos, e vrias outras caractersticas,

429

como, por exemplo, a garantia da integridade de dados em caso de falhas do

sistema ou de acessos concorrentes.
Um servidor de arquivos geral aquele que capaz de aceitar transaes independente do sistema operacional do cliente, ou seja, independente
da estrutura de arquivos utilizada pelo cliente. Nesse caso, existe um sistema
de arquivos padro da rede, utilizado pelo servidor de arquivos, nos quais os
vrios arquivos das demais estaes da rede devem ser convertidos (pelos
protocolos no nvel de apresentao) para a comunicao com o servidor.
Sendo adotada essa soluo, todos os arquivos da rede so potencialmente
acessveis a todas as estaes, independente das estruturas de arquivos individuais [Duarte 85].
A soluo apresentada para o servidor de arquivos no pargrafo anterior tem a vantagem da generalidade, mas, s vezes, de difcil implementao, pois exige das estaes um processamento para a converso de sistemas. Muitas vezes essa capacidade de processamento no est disponvel
nas estaes (principalmente em redes para a interconexo de microcomputadores). Nesse caso o servidor de arquivos dever funcionar muito mais
como um servidor de discos (ou memria de massa), sendo capaz de armazenar vrias estruturas de arquivo diferentes (por exemplo, arquivos DOS,
UNIX etc), mas sem qualquer tipo de compartilhamento entre os vrios sistemas. O processamento exigido das estaes ser praticamente nenhum.
A comunicao de um cliente com o servidor de arquivos pode ser totalmente transparente ou no, isto , o servidor pode tornar totalmente transparente para o cliente a localizao de um arquivo; ou ento caber ao cliente o conhecimento da localizao do arquivo e da troca de primitivas com o
servidor.
Nada impede que uma rede possua mais de um servidor de arquivos.
Nesse caso, se a transparncia de localizao desejada, algum esquema de
gerenciamento de arquivos distribudos necessrio. Esse esquema deve
prover globalmente as mesmas funes de um servidor individual no que diz
respeito a direitos de acesso, proteo, integridade de dados etc.
O servidor de arquivo pode ser dividido em trs subsistemas funcionais: o subsistema de gerncia de arquivos, o subsistema de cache de disco e
o subsistema de controle de acesso compartilhado e segurana.
O subsistema de gerncia de arquivos controla todo acesso fsico aos
meios de armazenamento. Alguns servidores implementam o seu prprio
subsistema de gerncia de arquivos a fim de obter melhor eficincia e mais
segurana, enquanto outros utilizam os servios do sistema operacional lacai. O subsistema de cache de disco aumenta a eficincia do servidor acessando o disco em grandes blocos de dados, mantendo-os em memria RAM,
tentando assim diminuir o nmero de acessos fsicos s unidades de armaze430

namento. O subsistema de acesso compartilhado e segurana controla o

acesso simultneo aos arquivos, permitindo que eles sejam compartilhados e
utilizados concorrentemente. So usados dois modelos bsicos para controlar o acesso aos arquivos: os modelos share levei e user levei.
No modelo share levei cada recurso compartilhado e cada direito de
acesso possui uma ou mais senhas de acesso. O dono do recurso responsvel por administrar suas senhas. Qualquer pessoa que conhea a senha pode
utilizar o recurso com o direito de acesso a ela associado. Um exemplo de
um sistema que utiliza esse modelo de segurana o Windows for
Workgroups.
No modelo user levei cada usurio possui uma senha pessoal, que autoriza seu acesso ao sistema, e cada recurso possui uma lista de permisses
de acesso. S os usurios que pertencem lista de permisses esto autorizados a utilizar o recurso segundo o tipo de acesso a ele (usurio) disponibilizado. No modelo user levei, cabe ao administrador do sistema gerenciar o
cadastro de usurios e as listas de permisses dos recursos compartilhados.
Um exemplo de sistema operacional que adota esse modelo de segurana o
NetWare 3.11.
Cabe ainda ressaltar que os modelos share levei ou user levei apresentados para controlar o acesso aos recursos gerenciados pelo servidor de arquivos, so tambm utilizados em outros servidores, por exemplo o de impresso, para gerenciar o acesso a seus recursos.
16.4.2 - Servidor de Banco de Dados
As aplicaes baseadas no acesso a bancos de dados^ podem utilizar um
sistema gerenciador de bancos de dados (SGBD) executado no cliente, que
usa um servidor de arquivos para armazenar os arquivos dos bancos de dados, como mostra a Figura 16.7. Essa soluo alm de tornar muito difcil a
manuteno da integridade da base de dados, acessada por vrios clientes,
ainda pode degradar o desempenho da rede, como veremos mais adiante.
Alternativamente, poderamos pensar em uma soluo, onde parte das
funes do SGBD fosse executada no servidor, que agora assumiria no
apenas as funes de armazenamento de um servidor de arquivos, mas tambm funes de processamento de consultas, sendo por isso denominado
servidor de bancos de dados. A utilizao de servidores de bancos de dados
permite a centralizao de funes como controle de concorrncia e manuteno de consistncia dos bancos de dados, viabilizadas pelo processamento orientado a transaes implementado nesses servidores.

431

Um outro aspecto positivo da utilizao de servidores de bancos de dados o aumento do desempenho das aplicaes e da rede. Para entender o
porqu desse aumento no desempenho, vejamos o exemplo de uma transao onde so lidos os registros de um banco de dados, sendo alguns deles
seleconados por um critrio qualquer, para gerao de um relatrio. Inicialmente, veremos o que acontece quando a aplicao utiliza um gerenciador de bancos de dados (SGBD) local, operando como cliente de um servidor de arquivos. Posteriormente veremos o que acontece quando o SGBD
local utiliza um servidor de bancos de dados.

aplicao. De posse dos registros seleconados a aplicao gera o relate

A Figura 16.8 ilustra esse tipo de implementao.

Figura 16.8: Servidor de bancos de dados.

Figura 16.7: Gerenciamento de bancos de dados com servidor de arquivos.

Utilizando um servidor de arquivos, como na Figura 16.7, para executar a referida tarefa, o SGDB local tem que ler todos os registros da base de
dados residente no servidor de arquivos. Para tal, ele solicita que o servidor
de arquivos abra o(s) arquivo(s) da base de dados em questo, e transfira,
atravs da rede, todos os registros para a estao cliente. Aps receber os
registros, o SGBD local aplica o critrio de seleo e entrega aplicao
cliente os registros seleconados. A aplicao cliente ento imprime o relatrio.
Se, por outro lado, for utilizado um servidor de bancos de dados, o
SGBD local primeiramente codifica o pedido do usurio, por exemplo, em
uma consulta em SQL (Structured Query Language) com o critrio de seleo definido pela aplicao. Em seguida, ele envia a consulta para o SGBD
servidor. O servidor de bancos de dados ao receber o pedido, processa a
consulta, lendo todos os registros do banco de dados, localmente, selecionando-os de acordo com o critrio definido. Aps seleconados os registros
relevantes, o SGBD servidor os envia ao SGBD cliente, que os entrega

432

Dois aspectos explicam o aumento do desempenho da aplicao qr.

do utilizado um servidor de bancos de dados. O primeiro deles a til
o da rede, que no segundo caso s transporta registros que efetivame
iro compor o relatrio. Nesse caso, o ganho no desempenho no se
tringe a aplicao em questo, mas estende-se a todas as aplicaes que e
jam utilizando a rede para intercambiar dados. O segundo aspecto a ser
servado, a possibilidade de concentrar os investimentos no hardware
servidor (processador, memria cache etc), implicando em uma velocid
de processamento maior do que no caso onde a seleo dos registros re
zada no cliente, usualmente uma mquina de menor capacidade de proc
samento que o servidor. O custo extra do software e hardware do servi
pode ser facilmente justificado pelo seu compartilhamento.

16.4.3 - Servidor de Impresso

O servidor de impresso tem como finalidade oferecer servios de
presso a seus clientes, possuindo um ou mais tipos de impressora aor.
dos, cada um adequado qualidade ou rapidez de uma aplicao partcula

Existem vrias formas para implementar um servidor de impresso

forma mais simples baseada na pr-alocao da impressora. Nesse case
cliente envia um pedido ao servidor, manifestando o desejo de uso de u
impressora especfica. Caso essa impressora esteja disponvel, ela en
alocada ao cliente at que este a libere (ou ento at que se esgote o teu

mximo de utilizao, conforme negociao na alocao). Caso a impressora

no esteja disponvel, o cliente avisado e colocado, se de seu desejo, em
uma fila de espera.
Uma outra forma de implementarmos um servidor de impresso utilizando a tcnica de spooling. Nesse caso, o cliente ao invs de pedir a alocao de uma impressora, envia diretamente ao servidor o documento a ser
impresso. Esse documento colocado em uma fila de espera, sendo impresso quando a impressora estiver disponvel. A fila de impresso pode ser realizada em arquivos localizados nos discos existentes no servidor de impresso, ou ento atravs de arquivos de um servidor de arquivos, localizado ou
no na mesma estao do servidor de impresso. Nesse ltimo caso, o
cliente envia seu documento ao servidor de arquivos e um pedido ao servidor de impresso para a impresso do arquivo determinado. O servidor de
impresso, amando como cliente do servidor de arquivos, solicita que ele lhe
envie o arquivo para impresso, quando tiver uma impressora disponvel
para tal.

16.4.4 - Servidor de Comunicao

Muitas vezes interessante podermos ligar dispositivos sem inteligncia s redes, ou mesmo livrar o dispositivo a ser ligado dos procedimentos
de acesso rede. Nos dois casos necessria uma estao especial de frente
que ser responsvel pela realizao de todos os procedimentos de acesso
rede, bem como da interface com os dispositivos dos usurios, agindo como
um concentrador. As funes realizadas por essa estao especial definem o
que chamamos de servidor de comunicao.
E bastante usual a utilizao de servidores de comunicao para ligao de terminais de pequena capacidade rede, como tambm para ligao
de computadores de grande porte rede. A ligao do servidor ao computador ou terminal pode ser realizada de vrias maneiras: desde linhas assncronas de baixa velocidade e protocolo de comunicao bem simples, at
canais de entrada/sada com protocolos bastante complexos.
Conforme vimos no Captulo 11, gateways so estaes da rede que
oferecem servios de comunicao com outras redes, se constituindo em um
caso especial de servidor de comunicao.

16.4.5 - Servidor de Gerenciamento

A monitorao do trfego, do estado e do desempenho de uma estao
da rede, assim como a monitorao do meio de transmisso e de outros sinais, necessria para o gerenciamento da rede, de forma a possibilitar a
434

deteco de erros, diagnoses e resolues de problemas, tais como falhas,

diminuio do desempenho etc.
Algumas redes realizam essa monitorao em cada n, podendo esses
ns enviar seus relatrios a quaisquer outros. Os padres de gerenciamento
SNMP da arquitetura Internet TCP/IP e CMIS/CMD? da ISO definem elementos de controle em cada estao (agentes), que so responsveis pela
monitorao de parmetros de controle, deteco de condies de erro etc.
Esses mesmos padres especificam um outro elemento, o gerente, que o
responsvel pelo processamento das informaes de gerenciamento. Na primeira modalidade onde o gerenciamento distribudo, as funes de gerente
definidas nesses padres so executadas em vrias estaes da rede. Outras
redes, entretanto, dedicam uma estao servidora especial para essa monitorao, o servidor de gerenciamento de rede.
O uso de um servidor de gerenciamento no libera as estaes de realizarem medidas de diagnose e desempenho, e estatstica de controle. Essas
funes devem ser realizadas individualmente pelas estaes, com relatrios
sendo enviados periodicamente ao servidor. Ao servidor caber a anlise
desses dados e a obteno e anlise de dados globais da rede, para tomada
de decises quanto ao dimensionamento da rede, tarifao, isolamento de
falhas etc. Muitas vezes tal servidor capaz de receber todos os pacotes que
transitam pela rede, mesmo aqueles no endereados a ele (por exemplo, em
redes que oferecem endereamento promscuo). Dados que exigem segurana devem, nesse caso, sofrer algum tipo de criptografia em nveis superiores de protocolo nas estaes de origem. No modelo de gerenciamento
centralizado, utilizando a terminologia dos padres de gerenciamento da
ISO e da arquitetura Internet TCP/IP, teramos vrios agentes distribudos
nas vrias estaes da rede, e um ou mais gerentes implementados em um ou
mais servidores de gerenciamento.

16.4.6 - Outros Servidores

J vimos em captulos anteriores, exemplos de outros tipos de servidores. Os gateways foram um deles. Outro exemplo o servidor de nomes,
responsvel pela funo de converso de nomes simblicos em endereos
numricos, fornecendo ao usurio uma transparncia das localizaes e endereos dos servios oferecidos pela rede, como vimos quando foram discutidos o servio de diretrio da X-500 e o DNS da Internet no Captulo 15.
Outros exemplos de servidores encontrados em redes locais, so: o
servidor de fac-smle, o concentrador de telefones, os servidores de arquivos de voz e vdeo, os servidores de CD-ROM etc.

435

16.5 - Os Sistemas Operacionais de Redes e o

Modelo OSI
Para que uma estao possa operar em uma rede de computadores devem ser instalados recursos de hardware e software que complementam seus
dispositivos e seu sistema operacional local. Em uma rede local, o hardware
adicional necessrio se constitui, em geral, em uma placa de interface de
rede e do driver de dispositivo (device driver) que controla seu funcionamento. O software adicional, que definimos como sistema operacional de
rede, engloba os seguintes componentes: um conjunto de mdulos implementando os protocolos e as aplicaes cliente-servidor de uso geral e um
ou mais drivers com implementaes de protolocos de comunicao.' CTton.trole da placa de rede realizado pelo driver de dispositivo que se comunica
com o SOR atravs de uma interface bem definida. Esses componentes so
mostrados na Figura 16.9. Na figura, cada componente posicionado no nvel do RM-OSI correspondente s funes que o componente implementa no
suporte s aplicaes dos usurios.

16.5.1 - Placa de Interface de Rede

A placa de interface de rede (Network Interface Card NIC)
ponsvel pela conexo do hardware'da estao ao meio fsico de transmi
e, consequentemente, pela transmisso e recepo dos sinais que trate
no meio fsico. Usualmente, nas placas de rede so armazenados e exec
dos os algoritmos que disciplinam o acesso ao meio de transmisso. As
na placa de rede.esto as funes dos nveis fsico e de controle do acess
meio (subcamada MAC na arquitetura IEEE 802).

16.5.2 - Drivers da Placa de Rede

Um programa qualquer que deseje utilizar uma placa de rede dir
mente para transmitir ou receber dados, precisa lidar com detalhes espei
cos de cada tipo de placa (endereos de entrada/sada, cdigos de contro
de status). Essa aplicao teria que ser reescrita, ou reconfigurada, para c
tipo diferente de placa que viesse a utilizar. Com o objetivo de diminuir t
dependncia utilizado o driver de dispositivo (device driver) da plac
interface de rede. O driver de dispositivo, que normalmente fornec
junto com a placa de rede pelos fabricantes, de um lado lida com os aspei
especficos da operao da placa de rede, e do outro, fornece um conju
de chamadas mais fceis de usar e menos dependentes da tecnologia
placas de rede. Note que, apesar do driver de dispositivo simplificar a tai
de transmitir dados usando a placa de rede, as aplicaes continuam tei
que ser escritas especificamente para utilizar a interface definida por
determinado tipo de driver de dispositivo. Por exemplo, nada impede i
fabricantes distintos de placas de rede Ethernet implementem drivers
dispositivos com diferentes interfaces. Foi visando eliminar essa depend
cia de aspectos de implementao que alguns fabricantes acordaram
desenvolver interfaces comuns.

16.5.2.1 - NDIS (Network Driver Interface Specification)

Figura 16.9: Relao entre os componentes de um sistema operacional de rede e o

RM-OSI.

436

A NDIS, desenvolvida em conjunto pela 3Com e Microsoft, define

conjunto de comandos, chamados primitivas NDIS, que padronizam a int
face oferecida pelos drivers de placa de rede.
A NDIS permite que sejam utilizados um ou mais drivers de protoci
(arquitetura multiprotocolar) e uma ou mais placas de rede em uma esta:
como mostra a Figura 16.10. Um driver de protocolo pode- estar ligadc
mais de um driver MAC (driver da placa de rede), mas um driver MAC
pode estar associado a um nico driver de protocolo. A associao entre

drivers de protocolo e MAC feita atravs de ura procedimento de ligao

[binding).
Para permitir que um driver MAC possa indiretamente ser associado a
rm entre vrios drivers de protocolo, foi definida uma camada intermediria
;hamada vector. Os drivers MAC so ligados camada vector que ligada
os drivers de protocolo. Nesse caso, quando um quadro recebido por um
iriver MAC, ele o entrega camada vector, que tenta, sequencialmente, enxegar o quadro a cada. um dos drivers de protocolo, at que um deles o
icei te.

driver de MLID para transmitir pacotes. Como permite a instalao de mais

de um driver MLID, a LSL executa tambm a funo de relay, repassando
os quadros que recebe de um driver de protocolo (SAP de enlace) para um
dos drivers MLIDs (SAP de nvel fsico) instalados na estao, e vice-versa.

Figura 16.11: Arquitetura multiprotocolar ODI.

''igura 16.10: Arquitetura multiprotocotar NDIS.

16.5.2.2 - ODI (Open Data Link Interface)

A Novell e a Apple Computer visando tambm diminuir a dependncia
:ntre as implementaes dos drivers de placa e de protocolo, elaboraram a
)DI (Open Data Link Interface). A ODI foi alm da padronizao da interace MAC, definindo duas interfaces e a camada LSL (Link Support Layer),
;omo mostra a Figura 16.11. A MLI (Multiple Link Interface) define a interace entre as camadas MAC (do driver da placa) e LLC da arquitetura IEEE
02.2. Os drivers de placa compatveis com essa interface so denominados
ALID (Multiple Link Interface Driver) na especificao ODI. A MPI
Multiple Protocol Interface) define a interface entre as camadas de enlace e
ede OSI (LLC e rede na arquitetura. IEEE 802). A LSL (Link Support
vayer) foi definida para permitir a utilizao de um ou mais drivers de proocolo (arquitetura multiprotocotar), e de um ou mais drivers de placa
MLIDs), simultaneamente. A LSL implementa o servio de multplexao
10 nvel de enlace, permitindo que vrios drivers de protocolo utilizem um
138

16.5.3 - Drivers de Protocolo

Nos drivers de protocolo fica o cdigo das vrias opes de protocolos
de comunicao disponveis na estao. Alguns exemplos de drivers de
protocolo so: o TCP/IP, o SPX/IPX, e o NetBIOS. Os drivers de protocolo
definem a interface usada pelas aplicaes distribudas para intercmbio de
dados.

16.5.3.1 - T C P / I P

Um driver TCP/IP constitui-se de uma implementao do protocolo de

nvel de rede Internet Protocol, e do protocolo de nvel de transporte
Transmission Control Protocol, ambos definidos na arquitetura Internet. O
leitor atento deve ter notado na Figura 16.9 a semelhana da configurao
do sistema operacional de rede com a arquitetura Internet. Na descrio da
camada de aplicao Internet, feita no Captulo 1.5, vimos que o nvel de
transporte definia a interface usada para programao das aplicaes distribudas, como transferncia de arquivos (FTP), utilizao de arquivos remo-

Aia

tos (NFS), intercmbio de mensagens (SMTP) etc. Nos SOR os drivers de

protocolo definem a. interface de programao. Entretanto, a grande motivao do uso do driver TCP/DP pelos sistemas operacionais de redes, que ele
permite a interligao da rede local com outras redes locais, metropolitanas
ou geograficamente distribudas, desde que sejam todas compatveis com a
arquitetura Internet TCP/IP.

(com as funes de transmisso sendo executadas por outro driver de pr.

colo, como faz a Novell).

16.5.3.2 -PX/SPX

Voltando a falar sobre a implementao de uma interface NetB

existem hoje inmeras verses, por exemplo, as implementadas sobre a L
Classe 1, sobre o TCP/IP, sobre o SPX/IPX etc.

O driver IPX/SPX contm os protocolos bsicos dos sistemas operacionais de redes da Novell. Os protocolos IPX/SPX baseiam-se em protocolos que fazem parte da pilha de protocolos XNS (Xerox Network Systems)
desenvolvida pela Xerox.
O protocolo IPX (Internetwork Packet Exchange) o protocolo usado
peia Novell para o nvel de rede. O IPX fornece um servio datagrama noconfivel a seus usurios (normalmente o SPX), isto , seus pacotes so
transmitidos sem que seja necessrio estabelecer conexes e no so reconhecidos pelo destinatrio. Os endereos IPX so formados por trs componentes: o endereo da rede onde est conectada a estao, o endereo da estao na rede e o endereo de uma porta (socket) que identifica o processo
que est executando na estao que enviou ou que ir receber o pacote. O
IPX implementa um esquema de roteamento inter-redes (todas elas usando o
IPX), baseado em tabelas de rotas localizadas nos gateways.
O SPX (Sequenced Packet Protocol) o protocolo usado pela Novell
para o nvel de. transporte do RM-OSI. O SPX implementa um servio de
circuito virtual, ou seja, mecanismos de controle de erro, de fluxo e de sequenciao. O SPX utiliza o'algoritmo janela deslizante (slnding-wndow),
descrito no Captulo 8, para realizar as funes de controle de erros e de
fluxo.

Como j mencionado, o NetBIOS no um protocolo, mas sim i

interface que fornece s aplicaes de rede um servio de transmisso c
fivel orientado conexo, um servio de nomes para identificar seus iu
rios na rede, e opcionalmente um servio de transmisso de datagrama r
confivel.

Em sistemas MS-DOS, uma aplicao que deseje usar os servios

NetBIOS pode faz-lo ativando a interrupo 5C (em hexadecimal), pass
do o endereo da estrutura que contm o NCB (Network Control Bio
como um parmetro. Toda comunicao de uma aplicao com o NetBIO
feita atravs do NCB. Antes de chamar o NetBIOS a aplicao deve rnoi
um NCB e preencher os campos de entrada apropriados; a resposta
NetBIOS recebida pelos campos de resultado apropriados, tambm ene
trados no NCB. A Tabela 1.6.1 mostra os campos da estrutura NCB. Co
pode ser notado, a interface de programao do NetBIOS de baixo nvel

Tabela 16.1: NCB (Network Control Block) do NetBIOS

Campo

NCB..RETCODE

NCBJ.SN

NB_NUM
NCB.BUPFER
NCB_LENGTH

16.5.3.3-NetBIOS
O NetBIOS (Network Input/Output System) uma interface para programao de aplicaes distribudas. O NetBIOS foi desenvolvido inicialmente pela Sytec, em uma implementao residente em uma placa IBM PC
Network! A interface NetBIOS foi introduzida pela IBM em 1984 e usada
pela Microsoft no sistema operacional de rede MS-Net. Atualmente a maior
parte dos fornecedores de sistemas operacionais de redes (IBM, Novell,
Microsoft, 3Com etc.) incluem a interface NetBIOS em seus produtos, implementada em um driver de protocolo, ou implementada por um emulador

440

Tam Descrio

NCB_COMMAND

NCB_CAU.NAME
NCBJAME
NCBJSTO
NCB_STC>
NCB_POST
NCB_LANA_NUM
.MCB_CMD_CPLT
NC8_RESERVE'

Cdigo do comando NetBIOS desejado

Cdigo de retorno do cornando

Nmero da sesso local (retornado por CALL ou LISTEN)

Identifica um nome local (retornado por ADD [CROUP] NAME)
Ponteiro para um buffer de dados (segmenfcdfset)
7
Tamanho do buffer de dados
16 Identifica o nome do destinatrio (aplicao remota)
16 Identifica o nome do remetente (aplicao local)
1 Valor do timeout para recepo
1 Valor do timeout para transmisso'
1
4

4 Rotina callback executada ao final de um comando assncrono

1 LAN Adapter Number - identificao da placa adaptadora de rec
1 Status do comando (FFh - Pendente, OOh - Sucesso, outros - Erro)
14 rea reservada

Os comandos NetBIOS dividem-se em quatro categorias, dependen

do tipo de servio que fornecem: comandos de servios genricos, comand
4

e suporte a nomes, comandos de suporte ao servio de datagrama, comanos de suporte ao servio orientado conexo.
Os comandos de suporte a nomes, listados na Tabela 16.2, permitem
ue as estaes associem nomes lgicos a SAPs do nvel de transporte. Os
ornes so utilizados para identificar os usurios do NetBIOS.

abela 16.2: Comandos de suporte a nomes do NetBIOS

Comando

Cd

Descrio

ADD GROUP NAME 36h Adiciona um nome de grupo na tabela de nomes local
ADD NAME

Tabela 16.4: Comandos de suporte ao servio orientado conexo do NetBIOS

Comando

Cd

Descrio

CALL

10h Cria uma conexo lgica com u m a aplicao local ou remota

CHAIN SEND

17h Envia dois bufers de dados atravs de uma sesso estabelecida

HANGUP

12b Finaliza uma conexo lgica

LISTEN

llh

RECEIVE

15h Recebe dados atravs de uma conexo lgica especfica

RECEIVE ANY

16h Recebe dados de qualquer conexo lgica existente

Espera pedidos de conexes lgicas

SEND

14h Envia dados atravs de uma conexo lgica

SESSION STATUS

34h Recebe informaes de estado de todas as conexes lgicas ativas

30h Adiciona um nome na tabela de nomes local

DELETE NAME

3 l h Remove um nome da tabela de nomes local

FIND NAME

F8h Determina a localizao de um nome na rede

Os comandos de suporte ao servio de datagrama, listados na Tabela

5.3, so usados pelas estaes para enviar datagramas para uma estao de
;stino, ou para todas as estaes da rede (difuso), e para receber datagra!as de outras estaes da rede.

Os comandos de servios genricos so usados pelas estaes para

executar servios que no esto diretamente associados com o gernciamento de nomes, ou com a transmisso e recepo de dados. Por exemplo, o
cornando reset reinicia o NetBIOS, apagando a tabela de nomes, abortando
todas as conexes abertas etc. Os comandos de servios genricos do
NetBIOS so listados na Tabela 16.5.

Tabela 16.5: Comandos de servios genricos do NetBIOS

ibela 16.3: Comandos de suporte ao servio de datagrama do NetBIOS

Comando
Comando

Cd

RECEVE BROADGAST
23h
DATAGRAM

Descrio
Recebe um datagrama de qualquer estao da rede

RECEIVE
DATAGRAM

21 h Recebe um datagrama de uma estao especfica da rede

SEND8U0ADCAST
DATAGRAM

22h Envia um datagrama para todas as estaes da rede

SEN D
DATAGKAM

20h Envia um datagrama para uma estao especfica, da rede

Os comandos de suporte ao servio orientado conexo so usados

;la estao para estabelecer e encerrar conexes NetBIOS, e para trocar
idos nas conexes previamente estabelecidas. Um usurio A, que deseja
iScutar" pedidos de conexo, executa o comando listen. Quando outro usuio executa o comando call informando o nome de A, estabelecida uma
mexao NetBIOS entre eles, permitindo que a partir da, eles troquem da3S, at que um deles desfaa a conexo, executando o comando hang-up. A
abela 16.4 lista os comandos desse servio do NetBIOS.

ADAPTER STATUS

Cd

Descrio

33h Obtm informaes sobre uma interface de rede local ou remota

CANCEL

35h Cancela comandos pendentes

RESET

32h Limpa as tabelas de nomes e sesses

16.5.4 - Protocolos e Aplicaes Clente-Servidor

Como vimos na Seo 16.2, as interaes entre as aplicaes em redes
locais de computadores baseiam-se no modo de interao cliente-servidor.
Os protocolos e as aplicaes cliente-servidor utilizam os drivers de
protocolos de transporte, para intercambiar dados atravs da rede. Toda interao entre um cliente e um servidor consiste em uma sequncia bem definida de troca de unidades de dados que transportam requisies de servios e respostas. A troca de mensagens transparente para os usurios que
utilizam os servios da rede, quer atravs do redirecionador, quer atravs de
utilitrios fornecidos com o sistema operacional de rede. A seguir so apre-

443
12

sentados resumidamente dois exemplos de protocolos usados em sistemas

operacionais de rede para dar suporte a interaes cliente-servidor.
16.5.4.1 - SMB (Server Message Blocks)

A comunicao entre os mdulos do sistema operacional de rede cliente e servidor nos sistemas fornecidos pela Microsoft e IBM baseiam-se no
intercmbio de SMBs. Quando o mdulo cliente do sistema operacional de
rede intercepta uma chamada feita por uma aplicao para acessar um recurso remoto, ele monta um SMB, colocando nele os parmetros que identificam o servio desejado, e o envia (usualmente atravs do NetBIOS) ao
mdulo servidor que controla o recurso em questo. Quando o servidor recebe um SMB carregando um pedido, ele executa o servio solicitado,
monta outro SMB com a resposta e o envia de volta ao cliente. Os SMBs
variam de acordo com o comando que transportam. Alguns exemplos desses
comandos so: Start e End Connection (estabelecem e encerram uma conexo entre um cliente e um servidor); Create e Remove Directory (criam e
removem entradas no diretrio do servidor); Create, Delete e Rename Files
(criam, removem e renomeiam arquivos nos diretrios); Open, Close, Read
Byte Block, Write Byte Block, Lseek, Lock Byte Block, Unlock Byte Block
(usados para abrir e fechar arquivos, ler e escrever blocos de dados nos arquivos, e bloquear/liberar o acesso a blocos de dados nos arquivos); Create
Spool File, Spool Byte Block, Close Spool File (para criar arquivos no spool
do servidor de impresso, transferir dados para esses arquivos e fech-los);
Send Single Block Message, Send Broadcast Message, Send Start, Text e
End of Multi-Block Message (para comandar a transmisso de mensagens);
Forward User Name (para solicitar ao servidor que receba mensagens endereadas a um usurio).

mensagem NCP carregando um nmero de sequncia identifica os pedid.

permite que o cliente possa associar uma resposta ao pedido corresponde
O nmero de sequncia incrementado a cada solicitao. Outro campe
mensagem carrega um cdigo que identifica o tipo de servio solicitado
um cliente a um servidor. So exemplos de servios que podem ser solic
dos por pedidos carregados em mensagens NCP: estabelecimento e en
ramento de conexes entre clientes e servidores, manipulao de diretrii
arquivos, manipulao de semforos para sincronizar a utilizao com
rente de recursos, modificao de parmetros de controle de segurana e
presso de dados.

O NCP permite que os objetos (usurios, grupos de usurios, servi

res etc.) sejam associados a nomes e possam armazenar atributos que d
nem suas propriedades. As informaes sobre os objetos so armazena
em um banco de dados do servidor de arquivos denominado bindery, O N
utiliza o bindery para implementar servios de nomes, contabilizao de
de recursos e mecanismos de segurana.

As conexes entre clientes e servidores so identificadas por um

mero de conexo, que utilizado pelo NCP para controlar os pedidos fe
e os recursos utilizados por um dado cliente, e para verificar se o usu;
tem permisso para executar os pedidos que faz.

16.5.4.2 - O NetWare Shell e o NCP (NetWare Core Protocol)

O NetWare Shell um redirecionador usado em sistemas operacionais

de rede da Novell. O NetWare Shell implementado como uma casca (shell)
que fica acima do sistema operacional local, redireconando os pedidos relativos a recursos remotos para os servidores, e repassando para o SOL os
pedidos de acesso a recursos locais. O protocolo usado na interao entre os
clientes e servidores NetWare o NCP.
O NCP utiliza o servio de datagrama fornecido pelo IPX para transmitir suas mensagens, implementando seu.prprio mecanismo de controle de
conexes. O mecanismo de controle de erro utilizado no NCP baseia-se no
reconhecimento de cada pacote IPX transmitido. S uma solicitao NCP
pode estar pendente em um determinado instante do tempo. Um campo da
444

Captulo 1 7
Segurana em
Redes de
Computadores

Este captulo tem por objetivo propiciar ao leitor uma introduo ao

vastssimo tema que o estudo da segurana em redes de computadores.
Para tal, inicialmente sero definidos alguns conceitos bsicos. Em seguida,
discutiremos a proposta da ISO para a segurana em redes de computadores,
baseada na Arquitetura de Segurana apresentada no padro ISO 7498-2.
Em seguida discutiremos o padro "Trasted Computer System Evaluation
Cri teria" [DoD 85], elaborado pelo Departamento de Defesa dos EUA, que
define um esquema de classificao do nvel de segurana oferecido por um
sistema de computao. Esse documento, devido a cor de sua capa, acabou
ficando conhecido como "Livro Laranja". Por fim, teceremos alguns comentrios sobre o aspecto segurana no contexto da arquitetura de redes Internet
TCP/IP.

447