PERSEGUINDO A
ARQUITETURA DAS CAMADAS
MAIS ALTAS
Capítulo 4
Patterns in Network Architecture
2
Introdução
O Futuro da Internet (2012.1)
Citações
3

Você tem Telnet e FTP. O que mais você precisa?
– Alex McKenzie, 1975

Se o Terminal Virtual está na camada de
apresentação, onde está a fonte de alimentação?
– Al Reska, 1979

Estas citações revelam que as camadas superiores
sempre foram misteriosas e não muito claras.
O Futuro da Internet (2012.1)
Estrutura Geral
4


Será que existe alguma estrutura geral para
organizar as funções das camadas superiores, como
existem para as camadas inferiores?
As camadas inferiores se organizaram muito mais
rapidamente:
 Em
1975 já era comum ouvir falar nas camadas de
transporte, rede, enlace de dados e física.
 As duas camadas inferiores são dependentes do meio
físico e as duas superiores (ou do meio) são
independentes do meio físico e fim-a-fim.
O Futuro da Internet (2012.1)
Dificuldade em Estruturar as Camadas
Superiores
5




Aparentemente nenhuma estrutura ou decomposição
parece se aplicar.
Parte disto foi devido à ausência de aplicações e, em
um certo sentido, em muitas aplicações!
No início havia poucas aplicações (3-4) acessadas
através de “sockets bem conhecidos”. Embora desde
cedo tenha sido reconhecida a necessidade de algum
tipo de diretório.
Mas, no geral os protocolos de aplicação eram
produtos pontuais, com características únicas para cada
aplicação.
O Futuro da Internet (2012.1)
O Modelo OSI
6



O trabalho para o OSI enfrentou o problema e por
um tempo parecia que tivesse feito progresso.
Mas, embora tenham identificado alguns elementos
de uma estrutura geral, alguns passos errados na
arquitetura tornaram o projeto das aplicações
obscuros e um excesso de generalidade que
requeria implementações complexas para as
aplicações mais simples.
Foram divisões internas que mataram o OSI.
O Futuro da Internet (2012.1)
Roteiro
7






Este capítulo procura juntar o entendimento recente do
que torna característico estes protocolos.
Todos os problemas estão resolvidos?
Longe disto, mas com o arcabouço a ser apresentado
teremos uma visão mais clara e a possibilidade de
avançarmos.
Relacionamento entre redes e sistemas distribuídos.
Redes não é “tudo” e não pode ser considerado que
inclua toda a computação distribuída.
Temos que entender bem a fronteira e o
relacionamento entre elas.
O Futuro da Internet (2012.1)
8
Um Pouco de História
O Futuro da Internet (2012.1)
As Camadas Superiores da ARPANET
9

Preocupação inicial não era com as aplicações e
sim em:
 Construir
a rede e
 Identificar o que daria para ser feito com
computadores com arquiteturas tão diferentes!
 Como colocar software de rede relativamente
complexo em sistemas com os recursos já bastante
limitados?
O Futuro da Internet (2012.1)
ARPANET: Diversidade das máquinas
10

Comprimento das palavras (em bits):


Sistemas operacionais:


16, 18, 24, 32, 36 (dois tipos), 48, 64, etc.
Pelo menos uma dúzia com modelos bem distintos para E/S,
processos, sistemas de arquivos, proteção, etc.
Diretriz inicial: prover acesso através da rede a cada
um destes sistemas como se fosse um usuário local.

Primeiras aplicações: acesso a terminal, transferência de
arquivos, submissão de jobs para execução.
O Futuro da Internet (2012.1)
Telnet
11





Foi o primeiro protocolo de terminal virtual.
Não era uma aplicação de login remoto, mas um
protocolo de driver de terminal.
O login remoto é uma aplicação construída usando o
Telnet.
Os projetistas perceberam que ele não era apenas um
protocolo para conectar hosts a terminais, mas que
poderia ser usado também como um mecanismo de
comunicação entre processos orientado a caractere:
midleware.
Poderia ser usado para conectar duas aplicações que
tivessem sido escritas para interagir com humanos.
O Futuro da Internet (2012.1)
Telnet: NVT (Network Virtual Terminal)
12



Representação canônica de um terminal básico.
Definia um terminal rudimentar modo “rolagem” com
pouquíssimos atributos.
O terminal e o host convertem suas representações locais
para a representação usada pelo NVT e vice versa.
O Futuro da Internet (2012.1)
Telnet: Mecanismo de Negociação
13



Mecanismo simétrico: permitia que a solicitação de
um fosse a resposta ao outro.
No estabelecimento da conexão cada lado anuncia
o que pretende e o que não pretende fazer
(WILL/WONT),
E aquilo que espera que o outro lado faça ou
deixe de fazer (DO/DONT).
O Futuro da Internet (2012.1)
Telnet: Modo de Funcionamento
14

No caso de terminais half-duplex:
 Apenas
a interface entre o protocolo e o usuário
remoto seria half-duplex.
 O protocolo operaria como full-duplex.

Modelo fluxo (stream):
O
uso do modelo fluxo implicou na necessidade de
análise de cada caractere para identificar se seria um
caractere de comando.
 Se tivesse colocado os comandos Telnet e os dados do
terminal em “registros” separados, teriam reduzido
grandemente a sobrecarga.
O Futuro da Internet (2012.1)
FTP (File Transfer Protocol)
15


Foi construído sobre o Telnet, parte por razões
arquiteturais e parte por razões pragmáticas.
Usa uma conexão Telnet para enviar os seus comandos
de quatro caracteres seguidos normalmente por um
único parâmetro terminado por um CRLF.
O Futuro da Internet (2012.1)
FTP
16



A razão arquitetural para separar os fluxos de
comandos e de dados era para que os comandos, em
particular pedidos de interrupção (abort) não ficassem
presos atrás de uma transferência de arquivo grande.
O FTP definiu um sistema de arquivos rudimentar
chamado de NVFS (Network Virtual File System) e os
comandos básicos para realizar as transferências de
arquivos e consulta ao sistema de arquivo remoto.
Inicialmente correio eram dois comandos no FTP.
Demorou um pouco para ser separado num protocolo
distinto.
O Futuro da Internet (2012.1)
RJE (Remote Job Entry)
17

Permitia a submissão de um programa para rodar
numa máquina remota e recuperar a saída
(normalmente um arquivo de impressão).
O Futuro da Internet (2012.1)
ARPANET: Arquitetura das Camadas
Superiores
18
O Futuro da Internet (2012.1)
ARPANET: Lições Aprendidas
19




Por mais rudimentar que fosse, provou que as
aplicações poderiam ser construídas e podiam ser
muito úteis.
Ganhamos experiência valiosa com sistemas
distribuídos.
Aprendemos a dificuldade de lidar com diferenças sutis
na semântica dos diversos sistemas para o que
pareciam conceitos muito similares.
Aprendemos a necessidade de encontrar um equilíbrio
entre super especificação e manutenção da utilidade.
O Futuro da Internet (2012.1)
ARPANET: Lições Aprendidas
20


Qual a estrutura necessária para uma rede de
compartilhamento de recursos?
Um grupo de interessados formou um grupo de
interesse de usuários (USING) para desenvolver os
protocolos necessários:
Linguagem de comando comum
 Editor de rede
 Protocolo comum de cobrança (para usar os hosts)
 FTP melhorado
 Protocolo gráfico.


Mas a ARPA não gostou muito de perder o controle e
cortou o financiamento do grupo...
O Futuro da Internet (2012.1)
ARPANET: Lições Aprendidas
21



Os protocolos de camada superior da ARPANET deram
uma maior contribuição para a nossa compreensão do
projeto de protocolos do que para a arquitetura das
camadas superiores.
Mas isto era compreensível, pois o desenvolvimento de
aplicações distribuídas não era a motivação principal
para o projeto.
O uso da forma canônica (ex.: NVT) foi uma grande
inovação teórica e prática. Permitiu a redução de um
problema 𝑂(𝑛2) para um problema 𝑂(𝑛) evitando a
tradução para cada par de sistemas distintos.
O Futuro da Internet (2012.1)
ARPANET: Lições Aprendidas
22



As MIBs (Management Information Bases) são formas
canônicas atuais.
A experiência da ARPANET mostrou que há
vantagens em fazer errado da primeira vez: a
nova versão do Telnet ficou muito melhor a partir
de uma síntese de mecanismos conflitantes.
Mas tem que ser muito errado, caso contrário são
feitos apenas pequenos remendos, como foi o caso
do FTP.
O Futuro da Internet (2012.1)
ARPANET: Lições Aprendidas
23

A elegância não deve ser levada muito adiante:
 RJE
usando FTP e FTP e RJE usando Telnet levou a uma
solução impraticável.
O Futuro da Internet (2012.1)
A tentativa do OSI
24


Começando em 1978, OSI foi a primeira tentativa
dos grupos de padronização de fazer algo rápido
e o primeiro a aprender que seria difícil senão
impossível chegar a um acordo com um conjunto de
interesses tão diferentes.
Adotaram 7 camadas a partir de uma arquitetura
proposta pela Honeywell.
O Futuro da Internet (2012.1)
OSI: Arquitetura das Camadas
Superiores
25

Questões:
Quais partes dos protocolos
existentes pertenceriam às
camadas de sessão e
apresentação?
 Que outras funções
pertenceriam a estas
camadas?


Não houve muito consenso
e o desacordo
correspondia a PTTs x
indústria de computadores.
O Futuro da Internet (2012.1)
OSI: Pressão das PTTs
26

Interesse em colocar como OSI dois produtos que já
tinham:
 Teletexto
e
 Videotexto.
O Futuro da Internet (2012.1)
OSI: Camada de Sessão
27



Controle de diálogo e
Primitivas de sincronização
Ou seja, não tem nada a ver com o
estabelecimento de sessões, login, segurança e
funções associadas!
O Futuro da Internet (2012.1)
OSI: Camada de Aplicação
28



A camada de aplicação não contém dados dos
usuários.
Ou melhor, as PDUs contêm apenas informações
compreensíveis pelo protocolo que interpreta a PDU.
Não contém dados a serem interpretados por uma
camada acima...
Foi emprestado o conceito de “esquema conceitual” do
mundo de bancos de dados:
Para que duas aplicações troquem informações, precisam
de “um esquema conceitual no seu universo de discurso”.
 Generalização do conceito de forma canônica desenvolvido
para os protocolos da ARPANET.

O Futuro da Internet (2012.1)
OSI: Camadas de Aplicação e de
Apresentação
29


Se a camada de aplicação cuida da semântica
(esquemas conceituais), então a camada de
apresentação deve cuidar da sintaxe.
A camada de apresentação deve apenas negociar
a sintaxe utilizada pela aplicação.
O Futuro da Internet (2012.1)
OSI: Sintaxes
30
O Futuro da Internet (2012.1)
OSI: Protocolos de Aplicação
31

FTAM – File Transfer Access Method


JTM – Job Transfer and Manipulation


Baseado em protocolo Britânico
VTP – Virtual Transfer Protocol


Baseado em protocolo Britânico
Baseado numa combinação de propostas da DEC e
pesquisadores europeus
Apesar de incluir mais funcionalidades que as versões
anteriores da ARPANET, não trouxeram nenhuma
inovação na arquitetura.
O Futuro da Internet (2012.1)
OSI: Novos desenvolvimentos
32







CCR – Commitment, concurrency, and recovery
Um protocolo de commit em duas fases como um
componente reusável
TP – Transaction Processing
RDA – Remote Database Access
RPC – Remote Procedure Call
X.500 – Diretório
Protocolo de Gerência: CMIP – Common
Management Information Protocol
O Futuro da Internet (2012.1)
CCITT: Protocolo de Correio (X.400)
33


Na ARPANET as mensagens eram trocadas
diretamente entre os computadores.
À época das discussões que levaram ao X.400,
muitos sistemas eram estações de trabalho ou PCs.
 Isto
levou à distinção de servidores que recebiam
mensagens em nome de seus usuários
 Conceitos:
 MTA
– Message Transfer Agents e
 Servidores de mensagens
O Futuro da Internet (2012.1)
OSI: Mecanismo Comum de
Estabelecimento de Conexão
34


ACSE – Association Control Service Element
Provê mecanismos para:
 Endereçamento
na camada de aplicação
 Negociação de contexto da aplicação
 Autenticação


As aplicações definidas pela OSI (CCR, TP,
transferência de arquivos, etc.) essencialmente
apenas definem o comportamento da fase de
transferência de dados.
O ACSE provê a fase de estabelecimento
O Futuro da Internet (2012.1)
OSI: Natureza do Processo de
Aplicação
35


Grande contribuição do OSI para as camadas
superiores.
Protocolos de aplicação (application entities) fazem
parte do processo da aplicação, mas há uma parte
que fora do ambiente OSI (OSIE).
O Futuro da Internet (2012.1)
OSI: Natureza do Processo de
Aplicação
36



Na abordagem da ARPANET não havia
praticamente nada do processo de aplicação (AP)
fora das entidades de aplicação (AEs).
Queremos acessar a cnn.com (AP) e não o HTTP
(AE).
OSI:
 Distinção
entre protocolos de aplicação da aplicação
 Ao mesmo tempo reconhecendo que nomear o
protocolo de aplicação antes requer nomear a
aplicação.
O Futuro da Internet (2012.1)
OSI: Boa Engenharia de Software
37


Abordagem OSI permitia que os protocolos de
aplicação fossem construídos a partir de módulos
reutilizáveis, os ASEs (Application Service Elements).
Composição de um protocolo de aplicação:
 ACSE
e um ou mais ASEs ligados por uma função de
controle (CF).
O Futuro da Internet (2012.1)
OSI: Problemas com a Estrutura
38



Em 1983 já estava claro que cada sessão e
conexão de apresentação suportavam uma única
conexão de aplicação.
Não havia multiplexação acima da camada de
transporte e não havia necessidade de
endereçamento nas camadas de sessão e
apresentação.
Portanto, não havia necessidade para que as
camadas de sessão e apresentação estabelecessem
conexões de forma serial por conta da sobrecarga.
O Futuro da Internet (2012.1)
OSI: Problemas com a Estrutura
39

Estava claro que:
A
implementação da fase de estabelecimento das
camadas de sessão, apresentação e aplicação
deveriam ser consideradas como uma única máquina
de estados.
 E que as unidades funcionais de sessão (i.e. as
primitivas de controle e sincronização) deveriam ser
vistas como bibliotecas a serem incluídas caso
necessário.
O Futuro da Internet (2012.1)
OSI: Problemas mais fundamentais
40




Se uma aplicação necessitasse mudar o contexto de apresentação
durante o tempo de vida da conexão, ela informaria a camada de
apresentação, que efetuaria a mudança renegociando-o.
Diferentes partes de uma aplicação poderia requerer uma sintaxe
diferente a ser usada em tempos diferentes numa conexão.
Mas, como o protocolo de aplicação poderia invocar primitivas de
sincronização de sessão para retornar a um ponto anterior do fluxo,
a camada de apresentação deveria ter o registro do pedido do
protocolo de aplicação para garantir que a sintaxe correta fosse
usada para o fluxo de dados no ponto para o qual se retornou...
As funções de sincronização deveriam estar acima da apresentação
e não embaixo dela!
O Futuro da Internet (2012.1)
OSI: Problemas mais fundamentais
41

Conflito no uso da camada de sessão:
O
protocolo de processamento de transações (TP) usou
CCR para um commit de duas fases, mas também fazia
o seu próprio uso de primitivas de sessão necessárias,
na mesma sessão de conexão.
 A sessão não tinha meios de distinguir estes dois usos, e
não havia garantias de não interferência entre elas.
O Futuro da Internet (2012.1)
OSI: Problemas mais fundamentais
42

Repasse de mensagens X.400:
 Conexões
entre aplicações eram a origem e o destino
dos dados.
 Mas, o modelo de referência (RM) permitia
explicitamente o repasse na camada de aplicação.
 Portanto, enquanto a sintaxe do “envelope” tinha que
ser entendido por todos os intermediários da camada
de aplicação, a sintaxe da “carta” deveria se
entendido apenas pelo remetente e pelo destinatário
da carta.
O Futuro da Internet (2012.1)
OSI: Problemas mais fundamentais
43

Repasse de mensagens X.400 (cont.):
A
arquitetura exigia que o intermediário suportasse
todas as sintaxes necessárias não só para o envelope,
mas também para a carta, mesmo se apenas o
remetente e o destinatário precisariam interpretar a
sua sintaxe.
 O SMTP evitou este problema por um acidente
histórico, pois a única sintaxe era ASCII, e
posteriormente bastou acrescentar o MIME
(Multipurpose Internet Mail Extensions)
O Futuro da Internet (2012.1)
OSI: Lições Aprendidas
44

O OSI fez grandes progressos em ampliar o nosso
conhecimento das camadas superiores, mas sofreu
com problemas causados por interesses conflitantes:
 Interesses
econômicos
 Modelo “furado”.

Funções da ACSE na camada de aplicação são
conceitos associados com sessões, mas a camada de
sessão foi roubada pelas PTTs.
O Futuro da Internet (2012.1)
OSI: Lições Aprendidas
45



O fato de não existir multiplexação nas camadas de
sessão e apresentação é um forte indício de que
apesar de existirem funções de sessão e apresentação,
elas não constituem camadas distintas.
A negociação da sintaxe de apresentação deveria ser
uma função do estabelecimento da conexão da
aplicação.
Precisamos de uma arquitetura de camada de
aplicação que suporte a combinação de módulos em
protocolos.
O Futuro da Internet (2012.1)
OSI: Lições Aprendidas
46

No caso de repasses de mensagens (como as de
correio) necessitamos de duas camadas para as
conexões de aplicação de modo a separar:
A
sintaxe fim-a-fim da carta e
 A sintaxe etapa-a-etapa do envelope.

Devemos esperar que as aplicações possam ser
usadas como base para a construção de aplicações
mais complexas.
O Futuro da Internet (2012.1)
OSI: Lições Aprendidas
47




Reconhecimento dos papéis da sintaxe e da semântica
nos protocolos de aplicação.
Distinção entre sintaxes abstrata e concreta.
Reconhecimento de que os contextos de aplicação e
apresentação eram casos específicos de uma
propriedade geral dos protocolos (política de
negociação).
Percepção de que o campo nos protocolos inferiores
para identificar o protocolo acima era realmente uma
forma degenerada de contexto da apresentação e não
um elemento de endereçamento.
O Futuro da Internet (2012.1)
OSI: Lições Aprendidas
48


O OSI ficou preso cedo demais numa estrutura
particular de camadas.
Se a ACSE tivesse sido a camada de sessão, o
resultado poderia ainda não ser o mais correto,
mas estaria perto o bastante do resto da solução.
O Futuro da Internet (2012.1)