UTILIZE A PESQUISA!

Bridge de Rota de Origem (SRB)

FUNDAMENTAÇÃO

Oalgoritmo de brindge de rota de origem (SRB) foi desenvolvido pela IBM e proposto ao comitê IEE 802.5 como um meio de estabelecer bridges entre todas as LANs. Desde sua proposição inicial, a IBM ofereceu um novo padrão de bridge ao comitê IEE 802: asolução de bridge transparente de rota de origem (SRT). A bridge SRT elimina completamente as SRBs puras, propondo que os dois tipos de bridges de LAN sejam as bridges transparentese as bridges SRT. Embora a bridge SRT tenha obtido suporte, as SRTBs ainda são bastante implementadas.

ALGORITMO SRB

As bridges SRB são assim chamadas por considerarem que a rota completa, da origem até o destino. está incluído em todos os frames enviados pela origem e que trafegam entra as LANs. As bridges SRBs armazenam e encaminham os frames de acordo como que é indicado pela rota especificada no campo apropriado do frame.

Conteúdo extraído da página 260 do livro INTERNET WORKING TECHNOLOGIES HANDBOOK - TRADUÇÃO DA SEGUNDA EDIÇÃO.

AppleTalk

FUNDAMENTAÇÃO

O AppleTalk, um pacote de protocolos desenvolvidos pela Apple Computer no começo dos anos 80, foi desenvolvido juntamente com o computador Macintosh. O propósito do AppleTalk era permitir que vários usuários compartilhassem recursos, como arquivos e impressoras. Os dispositivos que fornecem esses recursos são chamados de servidores, enquanto os dispositivos que utilizam esses recursos (como um usuário de computador Macintosh) são chamados clientes. Por esse motivo, o AppleTalk é uma das primeira implementações de um sistema distribuído cliente-servidor.
O AppleTalk foi projetado com ua interface de rede transparente. Isso significa que a interação entre os computadores e os servidores de rede requer uma pequena interação da parte do usuário. Além disso, as efetivas operações dos protocolos AppleTalk são invisíveis para os usuários finais, que vêem somente o resultado dessas oprações. Existem duas operações de AppleTalk: AppleTalk Fase 1 e AppleTalk Fase 2.
O AppleTalk Fase 1, que é a primeira especificação do AppleTalk, foi desenvolvida no começo dos anos 80, restritamente para o uso em grupos de trabalhos locais. Assim, a Fase 1 apresenta duas limitações principais: seus segmentos de rede que não podem conter mais do que 127 hosts e 127 servidores e podem suportar somente redes não-estendidas.
O AppleTalk Fase 2, a segunda implementação Apple Talk otimizada, foi projetada para utilização em internetworks maiores. A Fase 2 soluciona as principais limitações do AppleTalk Fase 1 e contém vários aperfeiçoamentos em relação à Fase 1. Em particular, a Fase 2 permite qualquer combinação de 253 hosts ou servidores em um mesmo segmento de rede
AppleTalk e suporta redes não-estendidas e estentidas.


Redes não-estendidas

A rede Apple não-estendida é um segmento da rede física, ao qual é atribuído apenas o número de uma única rede, variando de 1 e 1.024. A rede 100 e a rede 562, por exemplo, são dois números de rede válidos em uma rede não-estendida. Cada número de nó em uma rede não-estendida precisa ser único e um mesmo segmento de rede não pode ter mais de uma Zona AppleTalk Fase nele configurada. (A zona é um grupo lógico de nós ou redes) A AppleTalk Fase 1 suporta apenas as redes não-estendidas, mas, como uma regra, as configurações de redes não-estendidas não são mais utilizadas em novas redes, sendo substituídas pelas redes estendidas.

Redes estendidas

A rede AppleTalk estendida é um segmento de rede física, ao qual podem ser atribuído vários números de rede. Essa configuração é conhecida como faixa de cabo. As faixas de cabo AppleTalk podem indicar o número de uma única rede ou vários números de redes consecutivos. A Rede 3-3 (unária) e a Rede 3-6 das faixas de cabo, por exemplo, são válidos em uma rede estendida precisa ser única e seu endereço também precisa ser único, para propósitos de identificação. As redes estendidas podem ter várias zonas AppleTalk configuradas em um mesmo segmento de rede e os nós das redes estendidas podem pertencer a qualquer zona única associada à rede estendida. As configurações de redes estendidas têm, como uma regra, substituir as configurações de redes não-estendidas.

Conteúdo extraído das página 273, 274, 275, 276 e 277 do livro INTERNET WORKING TECHONOLOGIES HANDBOOK - TRADUÇÃO DA SEGUNDA EDIÇÃO.

RSVP

ReSource reserVation Protocol ( Protocolo de Reserva de Recursos) é um protocolo especialmente desenvolvido para serviços integrados de Internet, pois permite que as próprias aplicações requeiram da rede reservas de recursos necessários para seus diversos serviços. As novas funções que foram implementadas neste protocolo tem dado a este uma flexibilidade e escalabilidade única comparado a protocolos convencionais de reserva de recursos. Este protocolo é utilizado por um host, em benefício do fluxo de dados de uma aplicação, para requerer uma Internet deverá ser modificada para poder suportar uma Qualidade de Serviço (Quality of Service) específica da rede. O protocolo RSVP é também utilizado por routers (roteadores) para entregar requisições de controle da QoS para todos os nós ao longo do(s) caminho(s) por onde os dados irão fluir, além de manter o estado da conexão para o serviço que foi requisitado. As requisições RSVP geralmente irão resultar, embora não necessáriamente, em reservas de recursos em cada nó ao longo da conexão.

------------------------------
Princípios de Qos
Vamos da um breve resumo de Qos para quem ainda não conhece:
Os protocolos de QoS têm a tarefa de fornecer córregos de dados diferentes com as prioridades e de garantir qualidades tais como a largura de faixa e atrasam épocas. Há atualmente duas arquiteturas principais: Serviços integrados (IntServ) e serviços diferenciados (DiffServ). Ambas as políticas do tráfego do uso das arquiteturas e podem ser combinadas para permitir QoS no LAN como na WAN.
------------------------------


ARQUITETURA


RSVP é um protocolo desenvolvido para permitir que as aplicações requisitem diferentes QoS para seus fluxos de dados. Para isso, dois pré-requisitos devem ser observados:
Elementos de redes, tais como roteadores, devem adequar-se aos mecanismos de controle de qualidade de serviço para garantir a entrega dos pacotes de dados;
A aplicação deve estar capacitada a fornecer os parâmetros ideais de QoS.
O RSVP não é um protocolo de roteamento, trabalhando em conjunto com este. É usado por uma aplicação para requisitar uma qualidade de serviço específica da rede. O protocolo atua tanto em máquinas do usuário quanto em roteadores, responsabilizando-se, nesse caso, a estabelecer e manter as condições para o serviço requisitado. O diagrama esquemático pode ser visto na figura
RSVP em Máquinas do Usuário e Roteadores.

O RSVP negocia a reserva de recursos em um único sentido de cada vez, ou seja, de forma simplex.. Com isso, ele trata distintamente receptores e transmissores, operando juntamente com a camada de transporte.
O RSVP não realiza transporte de dados, sendo apenas um protocolo de controle e atuando no mesmo nível de outros protocolos como o ICMP (Internet Control Message Protocol), o IGMP (Internet Group Management Protocol) ou protocolos de roteamento, conforme mostrado no desenho esquemático da figura 2. O gerenciamento ocorre no início da comunicação, sendo reiniciado de tempos em tempos. Caberá ao receptor a responsabilidade em requisitar uma QoS específica. O protocolo RSVP foi feito de forma a garantir que as arquiteturas mais antigas sejam compatíveis com o novo sistema, através do encapsulamento de seus pacotes de controle.


Camada de Atuação do Protocolo RSVP

DEFINIÇÃO DE CONCEITOS BÁSICOS

*Sessão
O protocolo RSVP define como sessão todo enlace de comunicação pelo qual se relacionam as camadas de transporte de todos os participantes da comunicação, podendo ser ponto-a-ponto ou multicast. Cada sessão é tratada independentemente. O conceito de sessão é propositalmente genérico, pois uma sessão pode ser estabelecida baseando-se em valores de QoS diferentes daqueles requisitados pelo receptor inicialmente. Tal fato deve-se à liberdade que o gerenciador possui em unir recursos ao longo do caminho de dados da aplicação, sempre tendo o melhor aproveitamento dos recursos como objetivo. Ao efetuar essa política, os valores de QoS requisitados poderão sofrer alterações, desde que essas não acarretem perda de qualidade para uma comunicação já estabelecida.

*Soft-state
O protocolo RSVP é baseado na noção de soft-state. Este termo foi inicialmente proposto por [5], definindo o ``estado'' que um determinado elemento, pertencente ao percurso de dados de um determinado par fonte-destino, se encontra quando uma reserva está estabelecida. O início do soft-state ocorre quando uma mensagem de reserva é recebida e realizada no elemento; este estado é periodicamente realimentado pelos receptores. Ao invés de entregar à rede a responsabilidade em detectar e responder a falhas, o RSVP delega aos receptores o trabalho de reenviar periodicamente suas requisições de serviços. Caso uma falha ocorra, somente uma nova requisição do serviço restabelecerá o soft-state nos roteadores.

ARP (Address Resolution Protocol)

Address Resolution Protocol ou ARP é um protocolo usado para encontrar um endereço da camada de enlace (Ethernet, por exemplo) a partir do endereço da camada de rede (como um endereço ip).
Embora na Internet cada máquina tenha um (ou mais) endereços IP, na verdade, eles não podem ser usados para transmitir pacotes, pois o hardware da camada de enlace de dados não reconhece endereços da Internet. Hoje em dia, muitos hosts de empresas e universidades estão associados a uma LAN por uma placa de interface que só reconhece endereços de LANs. Por exemplo, cada placa Ethernet fabricada é equipada com um endereço Ethernet de 48 bits. Os fabricantes de placas Ethernet solicitam um bloco de endereços de uma autoridade central para assegurar que duas placas não tenham o mesmo endereço (evitando conflitos, caso as duas estejam na mesma LAN).
As placas enviam e recebem quadros com base em endereços Ethernet de 48 bits. Elas nada
sabem sobre endereços IP de 32 bits.
Agora, surge a seguinte pergunta: De que forma os endereços IP são mapeados nos endereços da camada de enlace de dados, como é o caso dos endereços Ethernet? Para explicar como esse processo funciona, usaremos uma ilustração de uma pequena universidade com diversas redes clase C (agora chamada /24).

Três redes /24 interconectadas: duas redes Ethernet e um anel FDDI

Aqui, temos duas redes Ethernet, uma no departamento de ciência da computação com o endereço IP 192.31.65.0, e outra no departamento de engenharia elétrica co m o endereço IP 192.31.63.0. As duas estão conectadas por um anel de backbone do campus (por exemplo, FDDI) cujo endereço IP é 192.31.60.0. Cada máquina de uma rede Ethernet tem um endereço Ethernet exclusivo, identificado pelos rótulos E1 a E6, e cada máquina do anel FDDI tem um endereço FDDI, identificado pelos rótulos de F1 a F3.
Começaremos examinando como um usuário no host 1 envia um pacote para um usuário no host 2.
Vamos supor que o tr ansmissor conheça o nome do receptor pretendido, talvez algo como
mary@eagle.cs.uni.edu. A primeira etapa é encontrar o endereço IP do host 2, conhecido como
eagle.cs.uni.edu. Essa pesquisa é realizada pelo DNS (Domain Name System), que estudaremos no Capítulo 7. No momento, supomos apenas que o DNS retorna o endereço IP correspondente ao host 2 (192.31.65.5).
Em seguida, o software da camada superior do host 1 constrói um pacote com 192.31.65.5 no
campo Destination address e o fornece ao software IP para transmissão. O software IP pode
examinar o endereço e constatar que o destino está em sua própria rede, mas ele precisa encontrar de alguma forma o endereço Ethernet da máquina de destino. Uma solução é ter um arquivo de configuração em algum lugar no sistema que faça o mapeamento de endereços IP em endereços Ethernet. Embora essa solução sem dúvida seja possível, no caso de organizações com milhares de máquinas, manter todos esses arquivos atualizados é uma tarefa demorada e propensa a erros.

Arquitetura CFX

Neste artigo iremos estudar a arquitetura CXF.
A arquitetura CXF é construída sobre os seguintes componentes:
*Bus;
*Interface;
*Mensageiros e interceptores;
*Modelo de Serviço;
*Ligações de dados;
*Vinculações do protocolo;
*Transportes.
A figura abaixo mostra a arquitetura geral:


Bus
Bus é a espinha dorsal da arquitetura CXF. O Bus CXF é composto de uma mola baseada arquivo de configuração, ou seja, cxf.xml que é carregado na inicialização do servlet através SpringBusFactory. Ele define um quadro comum para todos os endpoints. Ele liga todos os componentes da infra-estrutura de execução e fornece um contexto de aplicação comum. Ele carrega os arquivos de configuração relevante no diretório META-INF/cxf colocados no classpath e, portanto, constrói o contexto de aplicação.

CFX
CXF fornece o conceito de modelagem de interface, que permite criar serviços de web usando APIs frontend diferente, também permite que você crie clientes de serviços Web dinâmicOs. A interface primária CXF é suportado por JAX-WS.

JAX-WS
JAX-WS é uma especificação que define a semântica para desenvolver, publicar e consumir serviços da web. JAX-WS simplifica o desenvolvimento de serviços web. Ele é baseado em Java APIs, que facilitam o desenvolvimento e implantação de serviços web. A especificação oferece suporte ao WS-Basic Profile 1.1, que aborda a interoperabilidade de serviços web.

Interface Simples
Além da interface JAX-WS, CXF também suporta o que é conhecido como simple fronted ("interface simples"). A interface simples, fornece componentes simples ou classes Java que usa reflexão para a construção e publicação de web services. É simples, porque não utilizar qualquer anotação para criar serviços web. Em JAX-WS, temos que anotar uma classe Java para denotar-lo como um serviço web e usar ferramentas para converter entre um objeto Java e WSDL. A interface simples usa fábrica de componentes para criar um serviço eo cliente.

Mensageiros e Interceptores
Um dos elementos importantes da arquitectura CXF são os componentes Interceptores. Interceptores são componentes que interceptam as mensagens trocadas entre clientes ou serviço da Web e componentes de servidor. Em CXF, isso é implementado através do conceito de cadeias interceptoras. O conceito de encadeamento Interceptor é a funcionalidade do núcleo de runtime CXF.

Modelo de Serviço
O modelo de serviço, num verdadeiro sentido, os modelos de serviços. É um quadro de componentes que representa um serviço em um WSDL como modelo. Ele fornece a funcionalidade para criar vários elementos WSDL, como operações, fixações, pontos de extremidade do esquema, e assim por diante.

Ligação de Dados
A ligação de dados é a chave para qualquer serviço de desenvolvimento web. Mapeamento de dados através de ligação entre os objetos Java e os elementos XML. Como sabemos, com um serviço Web, mensagens são trocadas como artefatos XML. Então tem que haver alguma maneira de converter esses XML em objetos Java e vice-versa para o pedido de processo como o de serviço e cliente. CXF suporta dois tipos de ligação de coponentes de dados: JAXB e Aegis.

Ligação de Protocolos
Ligações vinculam as mensagens do serviço web com o protocolo formato específico. As mensagens, na terminologia de serviços web, nada mais são que uma operação com parâmetros de entrada e saída. A mensagem definida na componente de serviços web é chamado de uma mensagem lógica. A mensagem de lógica usada por um componente de serviço é mapeado ou vinculado a um formato de dados físicos utilizados pelos terminais no mundo físico. Estabelece regras sobre a forma como as mensagens lógica será mapeado para uma carga de reais enviados através do fio ou da rede.

Transportes
Transportes definem o protocolo de roteamento de alto nível para transmitir as mensagens sobre o fio. Protocolos de transporte são associados com os desfechos. Um ponto pode se comunicar com outro através de um protocolo de transporte específico. Informações relativas ao transporte são nada além de detalhes de rede. Parâmetros de serviço são uma representação física de uma interface de serviço. Os terminais são compostos de ligação e de detalhes de rede.

Conhecendo os Sockets

Os sockets (soquetes em português) são a maneira de se comunicar com outros programas usando os descritores de arquivo padrão do Unix. No ambiente Unix, ao se comunicar com um dispositivo ou um arquivo, você recebe uma resposta se tudo deu certo ou não. Esta resposta é o que se chama de descritor de arquivo.

O Unix foi o primeiro Sistema Operacional a usar em grande escala este tipo de tecnologia. E no Unix, para tudo se usa um descritor de arquivo (file descriptor, o famoso fd que precede muitas funções da linguagem C). No Unix, a utilização de redes já tem uma longa estrada atrás. Isto facilita muito as coisas para os programadores, pois não é necessário estar em um ambiente gráfico para se programar os soquetes. Você instala numa máquina um Linux Red Hat (ou a versão brasileira da Conectiva), e começa a programar com relativa facilidade. Estou falando dos que programam em C, que é praticamente a linguagem nativa do Unix.

Voltando aos sockets, eles existem em diversos tipos. No entanto, na internet, eles são de dois tipos: Stream Sockets e Datagram Sockets (Soquetes de Fluxo e os Soquetes de Datagramas). São referenciados como SOCK_STREAM e SOCK_DGRAM respectivamente. Qual a diferença entre estes?
Os Soquetes de Fluxo (SOCK_STREAM) enviam os dados e os controlam para que cheguem exatamente como foram enviados. Por exemplo, se enviar os dados A, B, C e D, eles chegarão ao seu destino exatamente como foram enviados e nesta mesma ordem: A, B, C e D. O Protocolo de Transporte de Controle (Transport Control Protocol, em inglês) utiliza estes soquetes.
Se estes mesmos 4 pacotes de dados forem enviados pelos Datagram Sockets, talvez apenas 3 cheguem ao seu destino. Quanto à ordem de sua chegada, pode ser A, D e C ou outra ordem qualquer. Eles são enviados, mas sem controle. O User datagram Protocol (Protocolo de Datagrama de Usuário) utiliza estes sockets.