sistemas e aplicações distribuídas - uniasselvi

2013

SiStemaS e aplicaçõeS DiStribuíDaS

Prof. Danton Cavalcanti Franco Junior Prof. Jan Charles Gross

Copyright © UNIASSELVI 2013

Elaboração:

Prof. Danton Cavalcanti Franco Junior

Prof. Jan Charles Gross

Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.

004.36F825s Franco Junior, Danton CavalcantiSistemas e aplicações distribuídas / Danton Cavalcanti Franco Junior; Jan Charles Gross. Indaial : Uniasselvi, 2013.

178 p. : il

ISBN 978-85-7830- 698-4

1. Processamento distribuído – Redes. I. Centro Universitário Leonardo da Vinci.

Impresso por:

III

apreSentação

Prezado(a) Acadêmico(a)!

Seja bem-vindo ao estudo da disciplina de Sistemas e Aplicações Distribuídas, que tem como principal objetivo demonstrar a importância e o funcionamento de um sistema operacional e dos sistemas distribuídos.

Este Caderno de Estudos foi dividido em três unidades. A primeira é introdutória, conta o histórico do sistema operacional e traz conceitos elementares de sua estrutura além de fazer entender o gerenciamento da memória. Na segunda unidade falaremos de processos, incluindo suas variantes (threads e subprocesso) além de entender como funciona a gerência do processador através do escalonamento de processos, finalizando com a gerência de dispositivos. Na terceira unidade serão estudados os sistemas distribuídos, sua arquitetura em um ambiente distribuído.

Durante o texto, você encontrará dicas de leitura e, ao final de cada unidade, um texto complementar que lhe auxiliará na busca de informações complementares.

Bom estudo!

Prof. Danton Cavalcanti Franco JuniorProf. Jan Charles Gross

IV

Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto para você que está chegando agora à UNIASSELVI quanto para você que já é veterano, há novidades em nosso material.

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um formato mais prático, que cabe na bolsa e facilita a leitura.

O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova diagramação no texto, aproveitando ao máximo o espaço da página, o que também contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente, apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade de estudá-lo com versatilidade nas telas do celular, tablet ou computador. Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto em questão.

Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa continuar seus estudos com um material de qualidade.

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de Desempenho de Estudantes – ENADE. Bons estudos!

UNI

VII

UNIDADE 1 – INTRODUÇÃO E FUNDAMENTOS DE SISTEMAS OPERACIONAIS ........ 1

TÓPICO 1 – FUNDAMENTOS E CONCEITOS BÁSICOS DE SISTEMAS OPERACIONAIS ............................................................................................................. 31 INTRODUÇÃO .................................................................................................................................... 32 O QUE É UM SISTEMA OPERACIONAL? .................................................................................... 4

2.1 FUNÇÕES BÁSICAS DO SISTEMA OPERACIONAL .............................................................. 52.1.1 Facilidade de acesso aos recursos do sistema .................................................................... 62.1.2 Compartilhamento de recursos de forma organizada e protegida ................................ 72.1.3 Controle e gerenciamento dos recursos de rede ............................................................... 7

3 HISTÓRICO .......................................................................................................................................... 73.1 PRIMEIRA GERAÇÃO .................................................................................................................. 83.2 SEGUNDA GERAÇÃO .................................................................................................................. 113.3 TERCEIRA GERAÇÃO .................................................................................................................. 123.4 QUARTA GERAÇÃO ..................................................................................................................... 143.5 QUINTA GERAÇÃO ...................................................................................................................... 16

4 TIPOS DE SISTEMAS OPERACIONAIS ....................................................................................... 164.1 SISTEMAS OPERACIONAIS DE COMPUTADORES DE GRANDE PORTE ....................... 17

4.1.1 Sistemas operacionais de lote (batch) ................................................................................. 184.1.2 Sistemas operacionais de tempo compartilhado ............................................................... 184.1.3 Sistemas operacionais transacionais ................................................................................... 18

4.2 SISTEMAS OPERACIONAIS DE SERVIDORES ........................................................................ 184.3 SISTEMAS OPERACIONAIS DE MULTIPROCESSADORES ................................................. 194.4 SISTEMAS OPERACIONAIS DE COMPUTADORES PESSOAIS ........................................... 194.5 SISTEMAS OPERACIONAIS DE TEMPO REAL ....................................................................... 194.6 SISTEMAS OPERACIONAIS EMBARCADOS .......................................................................... 204.7 SISTEMAS OPERACIONAIS DE CARTÕES INTELIGENTES ................................................ 20

LEITURA COMPLEMENTAR .............................................................................................................. 21RESUMO DO TÓPICO 1 ....................................................................................................................... 23AUTOATIVIDADE ................................................................................................................................ 24

TÓPICO 2 – INTRODUÇÃO AOS SISTEMAS OPERACIONAIS TRADICIONAIS E DE REDES ......................................................................................................................... 251 INTRODUÇÃO .................................................................................................................................... 252 SISTEMAS FORTEMENTE ACOPLADOS .................................................................................... 25

2.1 SISTEMAS ASSIMÉTRICOS .......................................................................................................... 262.2 SISTEMAS SIMÉTRICOS ............................................................................................................... 272.3 SISTEMAS COM MULTIPROCESSAMENTO ........................................................................... 28

2.3.1 Processamento vetorial ......................................................................................................... 282.3.2 Processamento paralelo ........................................................................................................ 29

2.4 QUANTO À ORGANIZAÇÃO FUNCIONAL ........................................................................... 293 SISTEMAS FRACAMENTE ACOPLADOS ................................................................................... 31

3.1. SISTEMAS OPERACIONAIS DE REDE ..................................................................................... 323.2 SISTEMAS OPERACIONAIS DISTRIBUÍDOS ........................................................................... 33

Sumário

VIII

3.3 QUANTO À ORGANIZAÇÃO FUNCIONAL ........................................................................... 34LEITURA COMPLEMENTAR .............................................................................................................. 35RESUMO DO TÓPICO 2 ....................................................................................................................... 37AUTOATIVIDADE ................................................................................................................................ 38

TÓPICO 3 – FUNDAMENTAÇÃO DA GERÊNCIA DE MEMÓRIA .......................................... 391 INTRODUÇÃO .................................................................................................................................... 392 A MEMÓRIA DO COMPUTADOR ................................................................................................. 393 ALOCAÇÃO DE MEMÓRIA ............................................................................................................ 41

3.1 ALOCAÇÃO CONTÍGUA DE ÚNICO USUÁRIO (ALOCAÇÃO SIMPLES) ....................... 413.2 ALOCAÇÃO PARTICIONADA FIXA (ALOCAÇÃO ESTÁTICA) ......................................... 423.3 ALOCAÇÃO PARTICIONADA DINÂMICA ............................................................................ 44

4 TÉCNICAS COMPLEMENTARES ................................................................................................... 464.1 SWAPPING ...................................................................................................................................... 464.2 MEMÓRIA VIRTUAL .................................................................................................................... 46

4.2.1 Paginação ................................................................................................................................ 474.3 SEGMENTAÇÃO ............................................................................................................................ 47

LEITURA COMPLEMENTAR .............................................................................................................. 48RESUMO DO TÓPICO 3 ....................................................................................................................... 50AUTOATIVIDADE ................................................................................................................................ 51

UNIDADE 2 – GERÊNCIA DE PROCESSOS E DISPOSITIVOS ................................................ 53

TÓPICO 1 – ESTRUTURA E FUNCIONAMENTO DOS PROCESSOS ..................................... 551 INTRODUÇÃO .................................................................................................................................... 552 CONCEITO DE PROCESSO ............................................................................................................. 56

2.1 BLOCO DE CONTROLE DO PROCESSO (PCB) ....................................................................... 572.2 ESTADOS DO PROCESSO ............................................................................................................ 572.3 MUDANÇA DE ESTADOS DO PROCESSO .............................................................................. 59

3 SUBPROCESSO ................................................................................................................................... 604 THREAD ................................................................................................................................................ 615 INTERRUPÇÕES E EXCEÇÕES ....................................................................................................... 62LEITURA COMPLEMENTAR .............................................................................................................. 64RESUMO DO TÓPICO 1 ....................................................................................................................... 67AUTOATIVIDADE ................................................................................................................................ 68

TÓPICO 2 – GERENCIAMENTO DO PROCESSADOR ................................................................ 691 INTRODUÇÃO .................................................................................................................................... 692 CONCEITOS BÁSICOS ..................................................................................................................... 69

2.1 CRITÉRIOS DE ESCALONAMENTO ......................................................................................... 702.2 OBJETIVOS DO ESCALONAMENTO ........................................................................................ 71

3 TIPOS DE ESCALONAMENTO ....................................................................................................... 713.1 TIPOS DE ESCALONAMENTO NÃO PREEMPTIVOS ........................................................... 72

3.1.1. First-in-first-out (FIFO) ........................................................................................................ 723.1.2 Escalonamento job mais curto primeiro ............................................................................. 733.1.3 Escalonamento cooperativo ................................................................................................. 73

3.2 ESCALONAMENTO PREEMPTIVO ........................................................................................... 743.2.1 Escalonamento circular ......................................................................................................... 753.2.2 Escalonamento por prioridades ........................................................................................... 753.2.2.1 Escalonamento circular com prioridades ........................................................................ 763.2.3 Múltiplas filas ......................................................................................................................... 763.2.3.1 Múltiplas filas com realimentação ................................................................................... 77

IX

4 ESCALONAMENTO DE SISTEMAS EM TEMPO REAL ........................................................... 784.1 TEMPO REAL CRÍTICO – RÍGIDOS ........................................................................................... 794.2 TEMPO REAL NÃO CRÍTICO – MODERADOS ....................................................................... 79

5 GERENCIAMENTO DE PROCESSOS EM SISTEMAS DISTRIBUÍDOS E DE REDE ........ 79LEITURA COMPLEMENTAR .............................................................................................................. 81 RESUMO DO TÓPICO 2 ....................................................................................................................... 84AUTOATIVIDADE ................................................................................................................................ 85

TÓPICO 3 – GERENCIAMENTO DE DISPOSITIVOS .................................................................. 871 INTRODUÇÃO .................................................................................................................................... 872 O SUBSISTEMA DE E/S – FUNCIONAMENTO .......................................................................... 873 DEVICE DRIVER (DRIVER) ............................................................................................................. 894 CONTROLADORES ........................................................................................................................... 905 LÓGICO E FÍSICO .............................................................................................................................. 91LEITURA COMPLEMENTAR .............................................................................................................. 92RESUMO DO TÓPICO 3 ....................................................................................................................... 96AUTOATIVIDADE ................................................................................................................................ 97

UNIDADE 3 – SISTEMAS DISTRIBUÍDOS .................................................................................... 99

TÓPICO 1 – SISTEMAS DISTRIBUÍDOS ........................................................................................ 1011 INTRODUÇÃO .................................................................................................................................... 1012 SISTEMAS DISTRIBUÍDOS ............................................................................................................. 1013 CARACTERÍSTICAS FUNDAMENTAIS DOS SISTEMAS DISTRIBUÍDOS ....................... 104

3.1 COMPARTILHAMENTO DE RECURSOS ................................................................................. 1043.2 CRESCIMENTO INCREMENTAL ............................................................................................... 1053.3 CONCORRÊNCIA .......................................................................................................................... 1063.4 ESCALABILIDADE ........................................................................................................................ 1073.5 TOLERÂNCIA A FALHAS ............................................................................................................ 1083.6 TRANSPARÊNCIA ......................................................................................................................... 1103.7 HETEROGENEIDADE ................................................................................................................... 1113.8 ABERTURA ...................................................................................................................................... 1123.9 SEGURANÇA .................................................................................................................................. 114

RESUMO DO TÓPICO 1 ....................................................................................................................... 117AUTOATIVIDADE ................................................................................................................................ 118

TÓPICO 2 – ARQUITETURA DE SISTEMAS DISTRIBUÍDOS .................................................. 1191 INTRODUÇÃO .................................................................................................................................... 1192 CAMADAS E MÓDULOS ................................................................................................................. 1203 MODELOS DE ARQUITETURA ...................................................................................................... 122

3.1 MODELO CLIENT-SERVER ......................................................................................................... 1233.2 SERVIÇOS ATENDIDOS POR MÚLTIPLOS SERVIDORES .................................................... 1263.3 SERVIDOR PROXY E CACHE ...................................................................................................... 1273.4 PROCESSOS PARES ....................................................................................................................... 129

4 VARIAÇÕES DO MODELO CLIENTE-SERVIDOR .................................................................... 1314.1 CÓDIGO MÓVEL ........................................................................................................................... 1314.2 AGENTES MÓVEIS ........................................................................................................................ 1334.3 COMPUTADORES EM REDE ...................................................................................................... 1344.4 CLIENTES FRACOS ....................................................................................................................... 1364.5 DISPOSITIVOS MÓVEIS ............................................................................................................... 1384.6 INTEROPERABILIDADE ESPONTÂNEA ................................................................................. 1394.7 COMPUTAÇÃO UBÍQUA OU PERVASIVA .............................................................................. 139

X

RESUMO DO TÓPICO 2 ....................................................................................................................... 142AUTOATIVIDADE ................................................................................................................................ 143

TÓPICO 3 – COMUNICAÇÃO EM UM AMBIENTE DE COMPUTAÇÃO DISTRIBUÍDA .. 1451 INTRODUÇÃO .................................................................................................................................... 1452 PROTOCOLOS .................................................................................................................................... 145

2.1 CARACTERÍSTICAS DA COMUNICAÇÃO ENTRE PROCESSOS ....................................... 1462.2 SOCKETS .......................................................................................................................................... 1482.3 COMUNICAÇÃO UDP ................................................................................................................. 1502.4 COMUNICAÇÃO TCP .................................................................................................................. 152

3 COMUNICAÇÃO CLIENTE-SERVIDOR ...................................................................................... 1563.1 O PARADIGMA CLIENTE/SERVIDOR ...................................................................................... 1563.2 SERVIDORES ................................................................................................................................... 1573.3 ARQUITETURA DOS SISTEMAS C/S ......................................................................................... 1583.4 SGBD DISTRIBUÍDO ...................................................................................................................... 159

4 OBJETOS DISTRIBUÍDOS E RPC ................................................................................................... 1594.1 INTRODUÇÃO ............................................................................................................................... 1604.2 OBJETOS DISTRIBUÍDOS ............................................................................................................. 1604.3 CHAMADAS REMOTAS DE PROCEDIMENTOS .................................................................... 1624.4 ARQUITETURA OSF RPC ............................................................................................................. 163

5 FALHAS DE COMUNICAÇÃO ........................................................................................................ 1645.1 FALHAS POR OMISSÃO .............................................................................................................. 164

5.1.1 Falhas por omissão de processo .......................................................................................... 1655.1.2 Falhas por omissão na comunicação ................................................................................... 165

5.2 FALHAS ARBITRÁRIAS ............................................................................................................... 1665.3 FALHAS DE SINCRONIZAÇÃO ................................................................................................. 1675.4 MASCARAMENTO DE FALHAS ................................................................................................ 1685.5 CONFIABILIDADE DA COMUNICAÇÃO 1 PARA 1 ............................................................. 168

LEITURA COMPLEMENTAR .............................................................................................................. 169RESUMO DO TÓPICO 3 ....................................................................................................................... 173AUTOATIVIDADE ................................................................................................................................ 174REFERÊNCIAS ........................................................................................................................................ 175

1

UNIDADE 1

INTRODUÇÃO E FUNDAMENTOS DE SISTEMAS OPERACIONAIS

OBJETIVOS DE APRENDIZAGEM

PLANO DE ESTUDOS

A partir do estudo desta unidade, o(a) acadêmico(a) estará apto(a) a:

• conhecer os principais conceitos de sistemas operacionais;

• entender os principais conceitos e fundamentos de sistemas operacionais;

• entender o processo de gerência de memória;

• conhecer o mecanismo dos processos;

• entender o funcionamento dos processos e suas formas de atuação.

Esta unidade está dividida em três tópicos, sendo que, ao final de cada um deles, você encontrará atividades que lhe auxiliarão na apropriação do conhecimento.

TÓPICO 1 – FUNDAMENTOS E CONCEITOS BÁSICOS DE SISTEMAS OPERACIONAIS

TÓPICO 2 – INTRODUÇÃO AOS SISTEMAS OPERACIONAIS TRADICIONAIS E DE REDES

TÓPICO 3 – FUNDAMENTAÇÃO DA GERÊNCIA DE MEMÓRIA

3

TÓPICO 1UNIDADE 1

FUNDAMENTOS E CONCEITOS BÁSICOS DE

SISTEMAS OPERACIONAIS

1 INTRODUÇÃOVamos falar de sistemas operacionais, para isso é importante entender

como é o seu funcionamento. Vale lembrar que é um programa como qualquer outro, exceto pelo fato de ser um programa que executa rotinas no núcleo do processador. Essas rotinas são, contudo, responsáveis pelo interfaceamento entre o hardware da máquina e as demais aplicações do usuário.

Para muitos, quando se fala em sistema operacional, imagina-se algo intangível e muito complicado, entretanto, um sistema operacional não é nada disso.

É graças ao sistema operacional que a interação do usuário com o computador é transparente, rápida e muito mais segura. Todo o gerenciamento dos recursos como processador, memória e dispositivos de entrada e saída fica a cargo do sistema operacional.

Dispositivos também conhecidos por devices podem ser de entrada ou saída (I/O), e servem para a comunicação do mundo exterior com o computador. São exemplos de dispositivos: HD, DVD, monitor, teclado e mouse (figura a seguir).

UNI

UNIDADE 1 |INTRODUÇÃO E FUNDAMENTOS DE SISTEMAS OPERACIONAIS

4

FIGURA 1 – EXEMPLOS DE DISPOSITIVOS CONECTADOS A UM COMPUTADOR

FONTE: Disponível em: <http://2.bp.blogspot.com/-0U7BhViJd3c/UQkV3fvjLtI/AAAAAAAAACw/yK0jXZWCF-k/s1600/perifericos.jpg>. Acesso em: 10 fev. 2013.

Neste capítulo veremos os conceitos básicos do sistema operacional, bem como sua evolução histórica.

Programas computacionais podem ser grosseiramente divididos em dois tipos:• programas do sistema, que manipulam a operação do computador. Podemos citar o desfragmentador de discos, o gerenciador de tarefas, entre outros;•programas aplicativos, que resolvem problemas para o usuário, como Excel, Word e Corel Draw.

IMPORTANTE

2 O QUE É UM SISTEMA OPERACIONAL?Pode-se dividir a estrutura de um sistema computacional em quatro

elementos: hardware, o sistema operacional, os programas e os usuários.

• O hardware compreende toda a parte física, que engloba a UCP (Unidade Central de Processamento), em inglês conhecida por CPU (Central Process Unit), a memória e os dispositivos de entrada e saída (I/O devices).

• Os programas, também conhecidos como aplicativos, que fornecem funcionalidades específicas como planilhas, editores de texto, editores gráficos e sistemas administrativos.

TÓPICO 1 | FUNDAMENTOS E CONCEITOS BÁSICOS DE SISTEMAS OPERACIONAIS

5

• Os usuários são as pessoas que interagem com esses programas, utilizando alguns recursos de hardware. Podemos ter os usuários finais e os usuários desenvolvedores de sistemas.

• Finalmente, tem-se o sistema operacional, que é responsável por gerenciar todos os recursos de hardware, tornando o uso da máquina transparente aos usuários. A figura a seguir mostra esses elementos e a relação entre eles.

FIGURA 2– ELEMENTOS QUE COMPÕEM UM SISTEMA COMPUTACIONAL E SUA RELAÇÃO

FONTE: Os autores

CPU é a unidade central de processamento, considerado o processador da máquina. É errado quando as pessoas se referem ao gabinete como CPU, pois o gabinete engloba uma série de dispositivos (placa-mãe, unidades de disco etc.). Portanto, fique atento e nunca chame seu gabinete de CPU, trate-o apenas como gabinete. Se estiver falando de recursos de desempenho de processamento, aí sim utilize o termo CPU.

2.1 FUNÇÕES BÁSICAS DO SISTEMA OPERACIONAL

São várias as funções do sistema operacional, podemos citar:


6

• permitir que os programas armazenem e obtenham informação;• isolar os programas dos detalhes específicos de hardware;• controlar o fluxo de dados entre os componentes de um computador;• permitir que os programas sejam executados sem a interferência de outros

programas;• permitir que os programas independentes cooperem periodicamente e

compartilhem informações;• responder aos erros ou a solicitações dos usuários;• impor um escalonamento entre programas que solicitam recursos;• facilitar o acesso aos recursos do sistema.

FONTE: Adaptado de: <http://www.paginadox.xpg.com.br/downloads/CEFET/so/Aula1.pdf >. Acesso em: 22 mar. 2013.

Contudo, sintetizamos todas as funções em duas: facilidade de acesso aos recursos do sistema e compartilhamento de recursos de forma organizada e protegida, vistos a seguir.

2.1.1 Facilidade de acesso aos recursos do sistema

A parte física da máquina (hardware) é composta por inúmeros componentes como discos rígidos, unidades de fita, impressoras, monitores de vídeo, teclados, mouses etc., todos interligados e funcionando de forma transparente.

É justamente esse funcionar de “forma transparente”, o papel do sistema operacional, que deve garantir que todos esses dispositivos sejam acessados e controlados conforme as regras estabelecidas. Essa estrutura pode ser observada na figura a seguir.

FIGURA 3 – ESTRUTURA DO SISTEMA OPERACIONAL

FONTE: Os autores


7

A gravação de um dado no disco, por exemplo, envolve uma série de processos, são comandos necessários para a localização da trilha e do setor, transferência dos dados da memória para o local correto, a validação dos dados, o controle da integridade e por fim a conclusão da gravação. Para o usuário o arquivo foi salvo, mas internamente o ciclo ocorrido foi bem amplo.

2.1.2 Compartilhamento de recursos de forma organizada e protegida

O compartilhamento de recursos, principalmente em sistemas multiusuários é um papel muito importante que o sistema operacional deve desempenhar. Entretanto, os sistemas monousuários também devem ter os recursos gerenciados, pois é só através disso que um usuário consegue utilizar todos os dispositivos disponíveis.

Por exemplo, uma impressora não deve ser acessada por dois usuários ao mesmo tempo, enquanto um imprime outro deve aguardar, todavia, uma unidade de disco pode ser acessada simultaneamente por diversos usuários, e cabe ao sistema operacional gerenciar a leitura e escrita dos dados no disco. Isso pode parecer para o usuário uma tarefa simples, mas há uma série de processos e rotinas envolvidas para que esse procedimento ocorra com sucesso.

2.1.3 Controle e gerenciamento dos recursos de rede

Os sistemas operacionais de rede devem permitir também o compartilhamento de recursos entre os usuários e o controle de acesso, permitindo que todos interajam de forma cooperativa.

Todos os recursos devem ser monitorados, sendo alocados quando um usuário solicita e tem permissão por exemplo.

3 HISTÓRICOA evolução dos sistemas operacionais ocorreu de forma gradativa e está

diretamente relacionada à evolução do hardware. A partir da Segunda Guerra Mundial, a evolução do hardware deu um salto com grandes avanços.

Podemos dividir a história dos sistemas operacionais em gerações ou fases.

Antes de 1940, as máquinas eram mecânicas, sendo sua programação feita através de engrenagens. Só a partir da Segunda Guerra Mundial que se desencadeou o processo de criação de máquinas digitais, sendo necessário elaborar formas de gerenciá-las.


8

Este item de nossa apostila mostra a evolução dos sistemas operacionais dentro do contexto histórico, da primeira à quinta fase. Alguns autores também trazem a fase zero, considerando-a como uma fase antes da era digital.

Alguns autores consideram a geração anterior aos computadores digitais como geração zero.

NOTA

3.1 PRIMEIRA GERAÇÃO

Válvulas e Plugs

É a fase compreendida entre os anos de 1940 até 1955. Com o início da Segunda Guerra Mundial, também se deu início a era dos computadores digitais, sendo o ENIAC (Electronic Numerial Integrator and Computer) o primeiro computador digital criado para realizar cálculos balísticos.

O ENIAC pesava 30 toneladas, media 5,50 metros de altura e 25 metros de comprimento, ocupando uma área de 180m². Contava com 70 mil resistores e 17.468 válvulas a vácuo. Demorou três anos para ser construído. Realizava uma soma em 0.2 milissegundos, uma multiplicação de dois números de 10 dígitos em 2.8 milissegundos, e uma divisão em 24 milissegundos. A temperatura do local de trabalho chegava a 50ºC. Nunca funcionou por 24 horas ininterruptas (válvulas queimavam e precisavam ser trocadas), e normalmente executava-se duas vezes um mesmo problema para comprovar o correto funcionamento da máquina. Custou US$ 500.000,00 doados pelo exército americano. Na figura a seguir pode ser observada uma válvula usada nos primeiros computadores.

NOTA


9

FIGURA 4 – VÁLVULA USADA NOS PRIMEIROS COMPUTADORES

FONTE: Disponível em: <http://upload.wikimedia.org/wikipedia/commons/8/89/VacuumTube1.jpg>. Acesso em: 12 fev. 2013.

Outros computadores como o EDVAC (Electronical Discrete Variable Automatic Computer) e o IAS (Princeton Institute for Advanced Studies) também pertencem a essa geração.

FONTE: Adaptado de: <http://www.angelfire.com/co/eltonsanders/socap4.html>. Acesso em: 22 mar. 2013.

Contudo, máquinas como essas exigiam um alto conhecimento no hardware, pois sua programação era realizada através de fios em grandes painéis, tudo através da linguagem de máquina (a resposta era dada em painéis através de lâmpadas), a figura a seguir mostra o painel do ENIAC, mostrando esse processo de programação.


10

FIGURA 5 – PAINEL DE PROGRAMAÇÃO DO ENIAC

FONTE: Disponível em: <http://obviousmag.org/archives/2012/03/os_saltos_altos_da_computacao_1.html>. Acesso em: 20 mar. 2013.

No início da década de 50, o processo de ligação através de fios nos painéis evoluiu para a programação através de cartões perfurados, tornando a programação mais fácil, e possível de ser repetida com a releitura dos cartões.

Como cada computador era único tanto em termos de estrutura como função, não havia necessidade de um sistema operacional, pois a programação era específica de cada máquina.

O advento dos cartões perfurados tornou a programação mais fácil e possível de ser repetida com a releitura dos cartões previamente perfurados.

Como cada computador era único, tanto em termos de estrutura como de função, não havia necessidade de um sistema operacional, pois a programação era específica de cada máquina e era feita exclusivamente para cada computador.

O filme Piratas do Vale do Silício (Pirates of Silicon Valley, 1999), com direção de Martyn Burke, conta a história da Microsoft e da Apple. É possível ver um pouco da origem do MS-DOS e do Windows, além de haver algumas cenas com uso dos cartões perfurados.

DICAS


11

3.2 SEGUNDA GERAÇÃO

Transistores e processamento em Batch

Compreendida entre os anos de 1956 e 1965, essa geração é marcada pelo surgimento do transistor e das memórias magnéticas, permitindo o aumento da velocidade das máquinas, a diminuição do tamanho dos equipamentos e a confiabilidade no processamento, essa é a geração dos computadores de grande porte, ou mainframes. A figura a seguir mostra os diferentes tipos de transístores usados atualmente.

FIGURA 6 – DIFERENTES TIPOS DE TRANSISTORES USADOS ATUALMENTE

FONTE: Disponível em: <http://www.mikroe.com/old/books/keu/04/4-01.gif. Acesso em: 1 fev. 2013.

Nessa geração também há o surgimento das primeiras linguagens de comunicação, como Assembly e Fortran, o que permitiu e facilitou a escrita de programas, evitando que fossem feitos diretamente no hardware.

Dessa forma surgiu o conceito de Job, onde o programa era escrito em papel, posteriormente os cartões eram perfurados com a codificação do programa, lidos e processados, tendo o resultado em um relatório impresso.

Os equipamentos possuíam um alto custo, desta forma, um processo Job tornava-se caro, a solução foi implementar o processamento em lote (batch), onde vários Jobs eram lidos a partir de cartões perfurados e gravados em uma fita magnética (utilizando um computador mais barato – 1401). Posteriormente, a fita era lida, processada e o resultado gravado em uma fita (utilizando um computador mais potente e caro – 7094). Finalmente a fita era lida e impressa novamente usando o computador mais barato (1401). A figura a seguir mostra esse processo.


12

A IBM fez o anúncio do IBM 1401 em 1959. Era um computador totalmente transistorizado, com capacidade de memória inicial de 4.096 bytes, podendo ser expandida até 16 Kb (raras eram as versões com 32 Kb de memória RAM). O IBM 7094 foi criado em 1962 e tinha Clock de 500 KHz e 32 Kb de memória operando a 36 bits.

UNI

FIGURA 7 – PROCESSO DE LEITURA E IMPRESSÃO

FONTE: TANENBAUM, Andrew S. Sistemas operacionais modernos. São Paulo: Prentice Hall-Br, 2003.

3.3 TERCEIRA GERAÇÃO

Circuitos integrados e multiprogramação

A terceira geração ocorreu entre os anos de 1966 e 1980, e destaca-se pelo uso dos circuitos integrados e a capacidade de multiprogramação (rodar vários programas em fatias de tempo). Na figura a seguir podemos observar diversos tipos de circuitos integrados.

No início da década de 60, havia duas linhas de máquinas totalmente incompatíveis, uma voltada para o mercado comercial (1401) com grande poder de processamento de caracteres, e outra com foco no meio científico (7094), com grande poder de processamento matemático. Portanto, escrever sistemas operacionais para esse tipo de estrutura era extremamente caro, pois para cada linha deveriam ser escritos sistemas operacionais específicos.


13

FIGURA 8 – TIPOS DE CIRCUITOS INTEGRADOS

FONTE: Disponível em: <http://img.alibaba.com/photo/331648991/IC_integrated_circuit_SN74LVC1G38DCKR_TI.jpg>. Acesso em: 20 fev. 2013.

Para unificar as funções do processamento, permitindo dessa forma que apenas um único tipo de sistema operacional fosse escrito, a IBM lançou a família 360, sendo suas sucessoras chamadas de 370, 4300, 3080 e 3090. A ideia de se ter famílias de máquinas sendo todas compatíveis, em teoria facilitaria o desenvolvimento de um sistema operacional, entretanto, isso não ocorreu, pois dada a complexidade de funções, vários bugs existiam, e a cada atualização, problemas eram corrigidos, mas ao mesmo tempo novos eram criados, tornando esse processo uma bola de neve.

Com a evolução do hardware, foi possível executar um programa, enquanto outro aguarda uma requisição de entrada/saída (I/O), para isso foi necessário criar partições de memória onde poderiam estar alocados vários Jobs juntamente com o sistema operacional (a figura a seguir mostra essa divisão).

Bug é um erro no funcionamento de um programa, também conhecido como falha e que pode causar erros no resultado final esperado pelo processamento.Esse termo originalmente foi criado por Thomas Edison, quando um inseto causou problemas de leitura em seu fonógrafo em 1878. Porém a invenção do termo frequentemente é atribuída erroneamente a Grace Hopper, que em 1945 reportou um mau funcionamento no computador Mark II, que era causado por um inseto preso nos contatos de um relê.

UNI


14

FIGURA 9 – PARTICIONAMENTO DA MEMÓRIA

FONTE: Os autores

Outros grandes avanços dessa geração foram, a substituição das unidades de fita por discos, o que facilitou a submissão dos Jobs de forma aleatória, essa técnica foi chamada de spooling; terminais de vídeo e teclado foram inseridos criando a interação on-line com o usuário e finalmente os processos foram divididos em tempos, oferecendo tempos de resposta razoáveis, a essa técnica deu-se o nome de time-sharing.

3.4 QUARTA GERAÇÃO

Computadores pessoais e estações de trabalho (redes)

Ocorrida entre os anos de 1981 e 1990, é marcada pela Integração em Larga Escala (Large Scale Integration – LSI) e Integração em Muito Larga Escala (Very Large Scale Integration – VLSI), o que acarretou na miniaturização do hardware e consequentemente seu barateamento. Como exemplo temos os primeiros computadores pessoais de 16 bits. A figura a seguir mostra uma placa utilizando VLSI.


15

FIGURA 10 – MINIATURIZAÇÃO UTILIZANDO VLSI

FONTE: Disponível em: <http://www.lambdaess.com/images/vlsi.jpg>. Acesso em: 15 fev. 2013.

Nessa geração também surge o MS-DOS, destacando o uso dos computadores pessoais. O conceito de multitarefa (executar diversas tarefas simultaneamente) também é implementado. O multiprocessamento também permitiu a execução de mais de um programa simultaneamente dando origem a técnicas de processamento vetorial e paralelismo.

As redes distribuídas começam a ser difundidas e vários protocolos de rede são criados, entre eles o TCP/IP, de domínio público. Surgem com isso as WANs, MANs e as LANs.

Com o desenvolvimento da rede, é na quarta geração que surgem os sistemas operacionais de rede.

IMPORTANTE

LAN – Local Area Network (abrangência no espaço físico de um ou mais prédios).MAN – Metropolitan Area Network (abrangência no espaço físico de uma cidade).WAN – Wide Area Network (abrangência no espaço de vários municípios ou países). Rede remota.

DICAS


16

3.5 QUINTA GERAÇÃO

Processamento distribuído, interfaces gráficas, linguagem natural

Marcada pela evolução da VLSI para a ULS (Ultra Large Scale Integration – Escala Ultra Larga de Integração), essa fase ocorre de 1991 até os dias atuais, permitiu uma grande evolução dos processadores, além de um ganho de velocidade muito grande.

O avanço das telecomunicações, a evolução do protocolo TCP/IP e o forte desenvolvimento da internet servem de fomento ao desenvolvimento dos sistemas distribuídos, substituindo a arquitetura/cliente servidor. A mobilidade dos sistemas também merece destaque. Sistemas operacionais aptos a rodarem em aparelhos celulares, palmtops e handhelds agregam infinitas possibilidades a esses aparelhos.

A quinta geração marca também o firmamento dos sistemas operacionais de interface gráfica, e os sistemas ditos open source (código aberto), dentre eles podemos destacar o FreeBSD, Linux e TROPIX.

A próxima geração não tarda a chegar, caminhamos para sistemas baseados em linguagem natural dotados de inteligência artificial, e extremamente móveis, para a tecnologia não há fronteiras.

Caro acadêmico! Para aprofundar seus conhecimentos sobre a história dos sistemas operacionais, leia o primeiro capítulo do livro: Introdução aos Sistemas Operacionais, de FLYNN, Ida M.; MCHOES, Ann Mclver. Trad.: Marcelo Alves Mendes. São Paulo: Pioneira Thomson Learning, 2002.

DICAS

4 TIPOS DE SISTEMAS OPERACIONAISA evolução dos sistemas operacionais discutida anteriormente permitiu a

implementação de uma grande diversidade de sistemas operacionais, que serão abordados neste tópico (vamos seguir a divisão proposta por Tanenbaum (2003), Sistemas operacionais modernos).

Dividimos basicamente nossa estrutura em dois tipos de sistema, os monotarefas e os multitarefas (a figura a seguir mostra o comparativo entre os sistemas). Contudo, essa visão pode ser ampliada, e vários subtipos de sistemas aparecem, é o que vamos estudar a seguir.


17

Os sistemas podem ser divididos conforme seu porte e sua função (observe a seguir essa divisão).

DICAS

FIGURA 11 – COMPARATIVO ENTRE SISTEMA MONOTAREFA (ESQUERDA) E MULTITAREFA

FONTE: MACHADO, F. M.; MAIA, L. P. Arquitetura de sistemas operacionais. 4° ed., São Paulo: Ed. LTC, 2007.

4.1 SISTEMAS OPERACIONAIS DE COMPUTADORES DE GRANDE PORTE

Sistemas especiais projetados para computadores de grande porte, utilizados em grandes corporações, são especializados em processamento de vários processos simultaneamente, gerando uma grande necessidade de I/O.

Podemos dividi-los em: lote, transacional e tempo compartilhado, explicados na sequência.


18

4.1.1 Sistemas operacionais de lote (batch)

Integra o conjunto dos primeiros sistemas operacionais multiprogramáveis desenvolvidos. Seu funcionamento não necessita da interação do usuário, sendo geralmente carregadas a partir de uma memória secundária.

Processamentos de grandes volumes de dados como relatórios, indexação de arquivos, backups, ou até mesmo um grande volume de cálculos utilizam sistemas batch.

4.1.2 Sistemas operacionais de tempo compartilhado

Também conhecidos como tempo compartilhado (time-sharing), permite a execução dos programas em pequenas fatias de tempo denominadas time-slice, sendo que um programa pode ter diversas fatias, caso não seja possível executá-lo por inteiro, ele retorna ao processador mais tarde para continuar sua execução.

Sistemas desse tipo permitem que se tenham vários usuários simultaneamente conectados através de terminais utilizando uma máquina com processador central, a maioria dos sistemas comerciais hoje em dia utilizam essa tecnologia.

4.1.3 Sistemas operacionais transacionais

Sistemas desse tipo possibilitam várias requisições simultâneas de usuário, como consultas a passagens aéreas ou reservas de uma cadeia de hotéis. São requisições pequenas, mas que possuem um alto volume e precisam ser gerenciadas como um todo.

4.2 SISTEMAS OPERACIONAIS DE SERVIDORES

Os servidores também são conhecidos como computadores pessoais de muito grande porte, sistemas desse tipo permitem que vários usuários compartilhem recursos de hardware e software.

As grandes empresas utilizam sistemas de servidores para compartilhamento de impressoras, arquivos, banco de dados, aplicações, ou até mesmo serviços web. O Windows 2000 é um claro exemplo desse tipo de sistema operacional.


19

4.3 SISTEMAS OPERACIONAIS DE MULTIPROCESSADORES

São sistemas especiais preparados para gerenciar hardware composto por diversas CPUs, tirando o máximo de proveito do poder de processamento equilibrando compartilhamento e gerência dos recursos. Em suma, são sistemas de servidores com variações para melhora de comunicação e conectividade.

4.4 SISTEMAS OPERACIONAIS DE COMPUTADORES PESSOAIS

Funcionalidade, facilidade e interface amigável são os pressupostos dos sistemas operacionais para micros pessoais, todas as pessoas que usam um computador em casa, possuem esse tipo de sistema operacional instalado, como exemplo podemos citar: Windows 98, Windows XP, Linux, MacOS etc.

4.5 SISTEMAS OPERACIONAIS DE TEMPO REAL

Também conhecidos como sistemas real-time, são usados em situações onde o tempo é fundamental para o funcionamento do sistema. São estabelecidos limites rígidos de tolerância para a resposta aos processamentos realizados.

Nesse tipo de sistema, não existe o conceito de fatia de tempo, sendo que o programa utiliza o processador o tempo necessário para efetuar a tarefa, são exemplos de aplicação: refinarias de petróleo, controle do trafego aéreo, usinas nucleares, equipamentos médicos, linhas de produção etc.

Dentro dessa categoria podemos ter ainda dois tipos de sistemas:

• Tempo Real Crítico: O tempo é crucial.• Tempo Real Não Crítico: O descumprimento ocasional de um prazo é aceitável

(áudio digital ou multimídia).

O robô Curiosity enviado a Marte usa sistemas em tempo real (figura a seguir).


20

FIGURA 12 – ROBÔ EM MARTE, USA SISTEMAS EM TEMPO REAL

FONTE: Wikipédia. Disponível em: <http://pt.wikipedia.org/wiki/2013>. Acesso em: 22 mar. 2013.

4.6 SISTEMAS OPERACIONAIS EMBARCADOS

Este tipo de sistema é usado em computadores que geralmente controlam dispositivos (computadores que não são considerados como tal), como um aparelho de televisão, um forno de micro-ondas, telefones móveis etc.

Um exemplo de sistema operacional embarcado, e que já traz novas tendências tecnológicas como toque na tela e controle de dispositivo móvel, é o iPhone OS, que controla o iPhone da Apple, além do PamlOS e Windows CE., para dispositivos móveis de propósito geral.

UNI

Na maioria das vezes, sistemas desse tipo apresentam restrições de memória, processamento, consumo de energia, contudo desempenhando de forma perfeita a função para a qual foram escritos.

4.7 SISTEMAS OPERACIONAIS DE CARTÕES INTELIGENTES

São sistemas operacionais muito pequenos, que rodam em dispositivos do tamanho de cartões de crédito. A maioria roda poucas funções, sendo extremamente limitada. Entretanto, outros possuem múltiplas funções. Como exemplo podemos citar os cartões de banco com chips ou as novas tags RFId, que são etiquetas inteligentes com transmissão via ondas de rádio.


21

Identificação por radiofrequência ou RFID (Radio-Frequency IDentification) método de identificação automática através de sinais de rádio, onde os dados podem ser recuperados e armazenados de forma remota através de dispositivos denominados etiquetas RFID.É uma tendência do mercado, em breve os produtos deixarão de ter códigos de barra, e passarão a ter etiquetas inteligentes para sua identificação.

DICAS

LEITURA COMPLEMENTAR

A HISTÓRIA DO WINDOWS

A Microsoft foi fundada em 1975 por Bill Gates e Paul Allen. Em 1980, Steve Ballmer se junta à companhia. O primeiro produto desenvolvido pela empresa foi uma versão do interpretador BASIC, para o computador Altair 8800 da MITS. Em 1977, foi lançado o Microsoft FORTRAN, para computadores baseados em CP/M.

Em 1980, a IBM planeja lançar seu computador pessoal com o sistema CP/M, mas as negociações com a Digital Research falham e a IBM procura a Microsoft para desenvolver seu sistema operacional. Sem ter um sistema para entregar, a Microsoft acerta um contrato não exclusivo de licenciamento com a IBM e procura a Seattle Computers para comprar seu sistema Q-DOS. Em 1982 a Microsoft começa a desenvolver aplicações para o Macintosh da Apple, lança o Microsoft COBOL e a planilha eletrônica Multiplan para MS-DOS. No ano seguinte anuncia o Microsoft Word e o Microsoft Windows. Em 1985 a Microsoft e a IBM assinam acordo para desenvolvimento conjunto de um futuro sistema operacional, no mesmo ano lança o Microsoft Windows 1.0 por 100 dólares. Em 1987 a Microsoft compra o programa de apresentações PowerPoint e lança a planilha eletrônica Excel. Em 1988 a Apple acusa a Microsoft de plágio sobre o seu Macintosh OS (este já uma cópia, do Xerox Alto) com o Windows 2.0, no ano seguinte formam uma aliança para desenvolver o padrão de fontes TrueType.

Em 1990 a Microsoft apresenta o Windows 3.0 para computadores pessoais e o OS/2 desenvolvido com a IBM para estações de trabalho. Nos anos seguintes anuncia em conjunto com outras empresas os padrões Multimidia PC, Advanced Power Management e o Plug and Play. Em 1992 a Microsoft e a IBM encerram o acordo de cooperação e dividem o sistema desenvolvido, a IBM passa a desenvolver o OS/2 4.0 e a Microsoft anuncia o Windows NT 3.0, no mesmo ano lança o Microsoft Access para Windows.


22

Em 1995 é lançado o Windows 95, um sistema operacional completo para computadores pessoais que elimina a necessidade do MS-DOS. No mesmo mês lança o Internet Explorer, parte do pacote Windows 95 Plus!, vendido separadamente. No ano seguinte lança o Windows NT 4.0, com o visual do Windows 95 e a segurança do Windows NT.

Em 1997 a Microsoft compra a WebTV e investe 150 milhões de dólares na concorrente Apple. No ano seguinte lança o Windows 98 incorporado ao Internet Explorer, iniciando um processo de monopólio movido pelo governo dos Estados Unidos, esse processo terminou em 2001 com a condenação da empresa.

Em 2001 lança o Windows XP juntando as linhas de sistemas operacionais Windows 95/98/Me para computadores pessoais, com o Windows NT/2000 para estações de trabalho, introduzindo uma nova interface gráfica. No mesmo ano lança o Xbox, seu primeiro console de videogames que irá competir como Sony Playstation e o Nintendo GameCube. Em 2007 a Microsoft lança o Windows Vista com uma interface gráfica aprimorada.

PRINCIPAIS VERSÕES DO WINDOWSWindows 1.0, novembro de 1985.Windows 2.0, novembro de 1987.Windows 2.1/286 e Windows 2.1/386, maio de 1988.Windows 2.11, março de 1989.Windows 3.0, maio de 1990.Windows 3.1, abril de 1992.Windows for Workgroups 3.1, outubro de 1992.Windows for Workgroups 3.11, novembro de 1993.Windows 95, agosto de 1995. Possui várias atualizações: OSR 1, OSR 2, OSR 2.1 e OSR 2.5.Windows 98, junho de 1998. Em maio de 1999 é lançado o Windows 98 SE (second edition).Windows Me, setembro de 2000.Windows NT 3.1, julho de 1993.Windows NT 3.5, setembro de 1994.Windows NT 3.51, maio de 1995.Windows NT 4.0, julho de 1996. Incorporou a interface gráfica do Windows 95.Windows 2000, fevereiro de 2000. Internamente é a versão NT 4.0.Windows XP, outubro de 2001. Versão NT 5.1, recebeu as atualizações SP1 e SP2.Windows Server 2003, abril de 2003. Versão NT 5.2.Windows Vista, janeiro de 2007. Versão NT 6.0.

FONTE: InfoEscola. História da Microsoft. Disponível em: <http://www.infoescola.com/informatica/historia-da-microsoft/13>. Acesso em: 1 mar. 2013.

23

Caro(a) acadêmico(a)! Neste primeiro tópico, você estudou os seguintes aspectos:

• O que é um sistema operacional e sua importância para o funcionamento de um sistema computacional.

• A importância do sistema operacional na relação entre o hardware e os usuários.

• As funções básicas do sistema operacional: facilidade de acesso aos recursos do sistema, compartilhamento de recursos de forma organizada e protegida, e controle e gerenciamento da rede.

• Um histórico da evolução dos sistemas operacionais.

• A relação direta entre a evolução do hardware e a evolução do sistema operacional através das gerações.

• Na quarta geração, surgiram os sistemas operacionais de rede, impulsionados principalmente pela evolução dos mecanismos de rede e a grande difusão das LANs, MANs e WANS.

• Verificou que os sistemas operacionais podem ser monotarefa e multitarefa.

• É possível dividir os sistemas operacionais segundo suas funções em tipos: sistemas operacionais de computadores de grande porte, sistemas operacionais de servidores, sistemas operacionais de multiprocessadores, sistemas operacionais de computadores pessoais, sistemas operacionais de tempo real, sistemas operacionais embarcados e sistemas operacionais de cartões inteligentes.

• Viu uma breve história do Windows.

RESUMO DO TÓPICO 1

24

Caro(a) acadêmico(a)! Resolva as questões a seguir para aprofundar seus conhecimentos e reforçar seu aprendizado.

1 Quais são os elementos que compõem a estrutura de um sistema computacional?

2 Quais são as funções básicas de um sistema operacional?

3 Quais gerações são apontadas na história e qual é o período que compreendem?

4 Em qual geração surgiram os sistemas operacionais de rede? Por quê?

5 Quais são os tipos de sistemas operacionais?

6 Em que ano surgiu a primeira versão do Windows?

AUTOATIVIDADE

25

TÓPICO 2

INTRODUÇÃO AOS SISTEMAS OPERACIONAIS

TRADICIONAIS E DE REDES

UNIDADE 1

1 INTRODUÇÃOOs sistemas operacionais podem ser classificados como fortemente

acoplados e fracamente acoplados em função da quantidade de processadores e dispositivos de entrada e saída que controlam.

A evolução do hardware criou os processadores de múltiplos núcleos (Core 2 Duo e Quad Core, i3, i5 e i7 são exemplos) ou máquinas com mais de um processador (máquinas multiprocessadas), que compartilham recursos como memória e dispositivos de I/O. Os sistemas que controlam essas máquinas são considerados fortemente acoplados, ao passo que sistemas independentes conectados por uma rede (um laboratório, por exemplo) são considerados fracamente acoplados.

Este tópico aborda ambos os tipos de sistemas, explicando sua aplicação e uso. Atente para os sistemas fracamente acoplados, geralmente sistemas operacionais de rede.

2 SISTEMAS FORTEMENTE ACOPLADOSSistemas operacionais tradicionais

Os sistemas fortemente acoplados (tightly coupled) caracterizam-se pela existência de um único sistema operacional controlando vários processadores e compartilhando apenas uma memória.

UNIDADE 1 | INTRODUÇÃO E FUNDAMENTOS DE SISTEMAS OPERACIONAIS

26

Alguns sistemas fortemente acoplados permitem ampliar sua capacidade de processamento apenas adicionando novos processadores (desde que haja suporte na placa-mãe). Outra vantagem desse tipo de arquitetura é o custo de desenvolvimento, pois processadores com mais de um núcleo são mais baratos que processadores de núcleo único.

IMPORTANTE

São sistemas aplicados em processamento científico, como exploração de petróleo, controle do clima, desenvolvimento aeroespacial etc., pois qualquer aplicação que use intensivamente a capacidade de processamento pode beneficiar-se com a inclusão de novos processadores ao sistema. Na figura a seguir temos a representação de um sistema fortemente acoplado.

FIGURA 13 – SISTEMAS FORTEMENTE ACOPLADOS

FONTE: MACHADO, F. M.; MAIA, L. P. Arquitetura de sistemas operacionais. 3° ed., São Paulo: Ed. LTC, 2002

A divisão dos sistemas fortemente acoplados pode ser feita conforme a simetria dos processadores, a seguir veremos em detalhes cada uma delas.

2.1 SISTEMAS ASSIMÉTRICOS

Sistemas assimétricos, também conhecidos como mestre/escravo (master/slave), baseiam-se na premissa de que apenas um processador pode executar os serviços do sistema operacional, ou seja, as chamadas de I/O, as SystemCalls, interrupções e demais processos críticos sempre são realizadas pelo processador principal, os demais processadores, quando necessitam realizar esse tipo de operação, devem solicitar ao mestre.

TÓPICO 2 | INTRODUÇÃO AOS SISTEMAS OPERACIONAIS TRADICIONAIS E DE REDES

27

Mais adiante você estudará os conceitos de interrupções e System Calls.

ESTUDOS FUTUROS

A figura a seguir mostra o esquema de um sistema assimétrico.

FIGURA 14 – SISTEMAS ASSIMÉTRICOS


Essa organização tem algumas desvantagens, a mais crítica é que se o processador mestre falhar, o sistema todo para, outro problema é o grande overhead gerado na situação de vários processadores requisitarem I/O, isso geraria lentidão no sistema em função do grande número de vezes que o processador mestre seria interrompido.

NOTA

2.2 SISTEMAS SIMÉTRICOS

O processamento simétrico (Simmetric Multiprocessing – SMP) garante que todos os processadores realizem as mesmas funções, exceto o boot e outras pequenas funções que ficam a cargo do processador principal (pois geralmente dependem do início pelo endereçamento zero, proveniente da BIOS).


28

Essa forma de organização pode gerar conflitos de acesso à memória que devem ser cuidadosamente gerenciados, entretanto o poder de processamento é aumentado, principalmente com o paralelismo (rodar um mesmo programa ao mesmo tempo em processadores diferentes), e tolerável a falhas, pois se um processador falhar, o sistema continua operante. A figura 15 mostra essa organização.

FIGURA 15 – SISTEMAS SIMÉTRICOS


2.3 SISTEMAS COM MULTIPROCESSAMENTO

O multiprocessamento divide o programa em fatias que podem ser executadas simultaneamente em diversos processadores. A seguir abordaremos os dois níveis de processamento existentes: vetorial e paralelo.

2.3.1 Processamento vetorial

O processamento vetorial permite a manipulação de vetores inteiros, sendo as instruções executadas sobre os vários elementos de um ou mais vetores. As aplicações que rodam nesses computadores devem possuir código vetorizável. Como exemplo de aplicação que utiliza perfeitamente esta arquitetura, podemos citar os modelos numéricos de previsão de tempo e clima (utilizados na Meteorologia). Aplicações desse porte trabalham com matrizes numéricas de grande tamanho e complexidade; ao ser utilizado um processamento vetorial, se ganha muito em processamento.

Com um processamento paralelo, reduz-se consideravelmente a quantidade de operações necessárias para simular os movimentos e sistemas meteorológicos. Máquinas vetoriais processam dados em altíssimas velocidades, processando, em segundos, informações que os computadores normais levariam horas.


29

Um processador vetorial possui instruções que agilizam a manipulação de vetores. Como exemplo de uso podemos pegar a seguinte expressão: C[x] = A[x] + B[x], seria executada por apenas uma instrução vetorial, ganhando tempo ao passo que num processador escalar o processo envolveria a busca do valor no vetor A, posteriormente a busca no vetor B, somá-los e finalmente armazenar no vetor C.

NOTA

2.3.2 Processamento paralelo

No processamento paralelo, uma aplicação pode ser executada simultaneamente por mais de um processador. Contudo, para que isso ocorra, é necessário que se possa dividir a tarefa em partes independentes, sem que gere conflito ou dependência entre as outras partes.

Um exemplo de uso de processamento paralelo é o uso em cálculos científicos, onde expressões complexas podem ser quebradas em instruções menores que por sua vez podem ser executadas em níveis vetoriais.

Como exemplo de uso de processo paralelo, imaginemos a seguinte expressão: x = (a + b) + (c * b) + (d / a) + (b * i) poderia ser dividida em quatro partes sendo todas executadas simultaneamente:V[1] = (a + b)V[2] = (c * b)V[3] = (d / a)V[4] = (b * i)

NOTA

2.4 QUANTO À ORGANIZAÇÃO FUNCIONAL

Quanto à organização funcional interna, é necessário que a comunicação dos dispositivos de I/O e o processador ocorram de forma correta. Para isso temos três formas de organização, conforme Machado e Maia (2002):

• Barramento comum (common bus ou time-shared bus) – a comunicação entre os processadores e demais controladores é feita através de um barramento comum. Entretanto, como desvantagem, citamos o fato de que apenas um processador pode utilizar o barramento por vez, o que pode causar problemas de performance.


30

Outro fator negativo é que, se houver comprometimento do barramento, o sistema falhará por falta de comunicação (figura 16a).

• Barramento cruzado (crossbar-switch matrix): Essa estrutura permite a conexão simultânea das unidades funcionais, o único problema é gerenciar os conflitos de acesso à memória simultaneamente por dois processadores (figura 16b).

• Memória multiport: Nesse esquema, os processadores podem acessar a memória ao mesmo instante, e os conflitos controlados pelos próprios módulos (figura 16c).

FIGURA 16 – (A) BARRAMENTO COMUM, (B) BARRAMENTO CRUZADO E (C) MEMÓRIA MULTIPORT



31

3 SISTEMAS FRACAMENTE ACOPLADOSSistemas operacionais de rede

A característica desses sistemas é possuir dois ou mais sistemas interligados, e cada sistema é controlado pelo seu próprio sistema operacional. É importante destacar que cada sistema possui e gerencia seus próprios recursos como processador memória e dispositivos de I/O.

Com as redes de computadores evoluídas juntamente com o hardware, o conceito de sistema fracamente acoplado evoluiu para rede de computadores (hoje é comum termos esse tipo de sistema em nosso dia a dia) (MACHADO; MAIA, 2002). A figura a seguir mostra o mecanismo de sistemas fracamente acoplados.

FIGURA 17 – SISTEMA FRACAMENTE ACOPLADO


Para melhor entendimento, imaginemos uma rede de computadores onde cada máquina possui seu próprio sistema operacional, mas interconectada pode compartilhar recursos. Na figura a seguir podemos observar os sistemas fracamente acoplados através da visão de uma rede de computadores.

Usa-se o desenho de uma nuvem para representar uma rede de computadores.

DICAS


32

FIGURA 18 – REDE DE COMPUTADORES (SISTEMAS FRACAMENTE ACOPLADO)


Neste tópico abordaremos as duas subdivisões dos sistemas fracamente acoplados: sistemas operacionais de rede e sistemas operacionais distribuídos.

3.1. SISTEMAS OPERACIONAIS DE REDE

Os sistemas operacionais de rede também chamados de SOR possuem vários equipamentos cada um com seu próprio sistema operacional interconectados, o que possibilita o compartilhamento de recursos entre os usuários.

As redes locais são exemplos dessa arquitetura, inclusive possuindo hardware e sistema operacionais diferentes, o sistema funciona perfeitamente, e mesmo na falha de algum equipamento o sistema continua operando, limitando-se apenas a ausência do recurso com problema (MACHADO; MAIA, 2002). A figura a seguir mostra o leiaute de uma rede de computadores.


33

FIGURA 19 – REDE DE COMPUTADORES, DISPOSITIVOS INDEPENDENTES COMPARTILHANDO RECURSOS


3.2 SISTEMAS OPERACIONAIS DISTRIBUÍDOS

Essa arquitetura propõe que os sistemas estejam separados, mas com um forte relacionamento entre si, sendo que na maioria das vezes possuem o mesmo sistema operacional, e para os usuários a rede é apresentada de forma transparente.

O balanceamento de carga é um forte ponto positivo dos sistemas distribuídos, pois possibilita que uma tarefa seja processada por um processador que esteja ocioso. O compartilhamento de recursos também é transparente, pois uma impressora em um ponto de rede pode ser vista como um dispositivo local (MACHADO; MAIA, 2002).

Além do balanceamento de carga, esse sistema também oferece a vantagem de ser tolerante a falhas, pois na eventualidade de falha de um sistema, outro pode assumir o papel do sistema problemático impedindo que os processos parem.

A figura a seguir mostra a visão de um sistema distribuído, note que os computadores estão espalhados dentro de uma rede, mas na visão do usuário existe apenas uma máquina. Os sistemas operacionais, nesse caso, devem estar relacionados e compatibilizados.


34

FIGURA 20 – SISTEMAS OPERACIONAIS DISTRIBUÍDOS


O projeto Seti (Search for Extra-Terrestrial Intelligence) é um exemplo de computação distribuída, no qual várias máquinas processam uma tarefa. Há necessidade, entretanto, da instalação de um software no sistema operacional que processe as informações.Além do projeto Seti, temos como exemplo o Climateprediction.net (que simula o clima na Terra), o PrimeGrid (que busca encontrar o maior número primo do mundo), além de tantos outros.Acesse o site: <http://boinc.berkeley.edu/> e veja a lista de projetos e, se interessar, participe, vale a pena!

NOTA

3.3 QUANTO À ORGANIZAÇÃO FUNCIONAL

Diferentemente dos sistemas fortemente acoplados, a organização funcional dos sistemas fracamente acoplados é definida pela topologia, ou seja, a posição dos computadores e como estão interligados. Temos dois tipos de topologias (MACHADO; MAIA, 2002):

• Barramento: Nessa topologia os sistemas são conectados através de uma única linha, usado em redes locais, todos compartilham o mesmo meio. Como problema aponta-se a falha ao meio, que compromete todo o sistema (figura 21a).

• Organização distribuída: Caracteriza-se por possuir várias linhas de comunicação entre os diversos equipamentos, desta forma, na falha de alguma delas, outra pode permitir a comunicação, muito utilizado em redes distribuídas (figura 21b).


35

FIGURA 21 – (A) BARRAMENTO E (B) ORGANIZAÇÃO DISTRIBUÍDA



Supercomputador criado com mais de um milhão de núcleos bate recorde

A Universidade de Stanford, nos EUA, ultrapassou a marca de 1 milhão de cores de processamento em um supercomputador. O IBM Blue Gene/Q Sequoia suporta exatos 1.572.864 núcleos de processadores, que funcionam em conjunto com 1.6 petabytes de memória. A supermáquina é usada para simulações complexas do comportamento dos fluídos e os dados são muito úteis para a indústria aeronáutica.

Uma das principais aplicações do volume de informações colhidas a cada simulação do supercomputador é fornecer subsídios a engenheiros para que eles criem motores de aeronaves mais silenciosos. Como as turbinas de aviões atuais funcionam, basicamente, sugando e expulsando ar, que é um fluído, os dados extremamente precisos permitem que novos designs e aprimoramentos nas turbinas sejam testados dentro do computador. Assim, não há a necessidade de desenvolver protótipos. Além disso, vale lembrar que não é possível entrar em uma turbina para vê-la em funcionamento.

Pesquisadores resolveram problema causado por grande volume de dados

Em termos de computação, há uma tendência a achar que mais é melhor. Mais memória, mais núcleos, mais processadores tenderiam a aumentar a capacidade de um sistema. Contudo, quando se fala na casa do milhão e meio de núcleos de processamentos, problemas começam a mostrar que, nem sempre, muito mais é melhor.


36

Supercomputadores funcionam quebrando porções matemáticas de problemas complexos. Cada pedaço dos cálculos pesados realizados pela máquina é endereçado a um grupo de processadores, que computa os dados e entrega os resultados no dispositivo de saída. Esse princípio faz com que soe natural que o supercomputador com 1,5 milhão de processadores seja melhor do que aquele com 500 mil.

No entanto, até o IBM Blue Gene/Q Sequoia de Stanford ser desenvolvido, havia um problema: surgia um gargalo de dados quando o computador chegava a um valor próximo de 1 milhão de processadores. Tantos núcleos funcionando a altas velocidades geravam um volume de dados tão grande que o sistema chegava a um bloqueio. Isso acontecia porque os softwares que operavam máquinas com milhões de núcleos não eram refinados o suficiente para dar vazão a tanta informação.

Em Stanford, esse problema foi resolvido com uma complexa reengenharia diretamente no código do software e no processamento dos dados. O resultado proposto foi o CharLES, um tipo de sistema operacional, digamos assim, capaz de aproveitar todo o poderio dos 1,5 milhões de cores do supercomputador.

FONTE: TechTudo. Supercomputador criado com mais de um milhão de núcleos bate recorde. Disponível em: <http://www.techtudo.com.br/curiosidades/noticia/2013/01/supercomputador-criado-com-mais-de-um-milhao-de-nucleos-bate-recorde.html>. Acesso em: 10 fev. 2013.

37

RESUMO DO TÓPICO 2

Caro(a) acadêmico(a)! No Tópico 2, você estudou os seguintes conteúdos:

• Os sistemas podem ser classificados como fortemente e fracamente acoplados.

• A expansão de sistemas fortemente acoplados ocorre pela adição de novos processadores.

• Um sistema assimétrico utiliza o mecanismo mestre/escravo.

• Nos sistemas simétricos os processadores realizam as mesmas funções.

• Sistemas com processamento vetorial utilizam apenas uma instrução para a manipulação dos vetores.

• Sistemas paralelos permitem a quebra de uma tarefa em pequenas partes.

• Os sistemas fracamente acoplados utilizam processamento separado, onde os equipamentos são interconectados através de redes ou barramentos.

• Barramento e organização distribuída são as formas de organização funcional dos sistemas fracamente acoplados.

38

Caro(a) acadêmico(a)! Para seu melhor aprofundamento resolva as questões a seguir.

1 Baseado na leitura complementar, pesquise na internet outras formas de adaptação de equipamentos, e os sistemas operacionais utilizados para a comunicação entre eles.

2 Especifique como poderiam ser conectados três computadores, duas impressoras e um sistema de armazenamento de forma que todos compartilhassem recursos.

AUTOATIVIDADE

39

TÓPICO 3

FUNDAMENTAÇÃO DA GERÊNCIA DE MEMÓRIA

UNIDADE 1

1 INTRODUÇÃOA memória é parte fundamental para o processamento dos dados em um

computador, pois é nela que são armazenados antes de serem executados nos registradores da CPU. Seu correto funcionamento e gerenciamento são primordiais para que a integridade dos dados seja garantida e, consequentemente, a correta execução do programa.

Para tanto, o sistema operacional deve oferecer mecanismos para que os dados e os processos em execução interajam entre si sem causar a perda de dados, tampouco a sua violação ou falha.

Com a evolução do hardware, as formas de acesso e gerência da memória também evoluíram, e o sistema operacional ganhou com isso, fôlego para aprimorar o gerenciamento do hardware como um todo.

Neste tópico estudaremos a evolução e a forma com que ocorre o gerenciamento da memória do computador, e o papel que o sistema operacional desempenha.

2 A MEMÓRIA DO COMPUTADORPodemos considerar que todo dispositivo capaz de armazenar dados no

computador é chamado de memória, podendo armazenar pequenas quantidades de bits (registradores) até grandes massas de dados (discos magnéticos e fitas magnéticas).

Quanto a sua organização, podemos dividir as memórias em uma hierarquia conforme sua velocidade e custo. Podemos observar isso na figura a seguir (SILBERSCHATZ; GALVIN, 2000).

O sistema operacional deve gerenciar e controlar o acesso aos dados que estão nas diversas camadas dessa hierarquia, principalmente das camadas iniciais, onde ocorre um grande fluxo de dados.


40

Antigamente os cartões perfurados também eram considerados unidades de memória, pois armazenavam os dados em papel.

NOTA

FIGURA 22 – HIERARQUIA DOS DISPOSITIVOS DE ARMAZENAMENTO

FONTE: Silberschatz, Galvin e Gagne (2001)

Toda essa divisão hierárquica só foi possível através da evolução do computador e dos sistemas operacionais, nos itens a seguir veremos como a gerência de memória evoluiu até a atualidade.

Os dispositivos de armazenamento podem ser voláteis (perdem seu conteúdo quando é interrompida a energia – a memória RAM é um exemplo) e não voláteis (permanecem com os dados mesmo depois da falta de energia – podemos citar aqui os discos rígidos).

NOTA

TÓPICO 3 | FUNDAMENTAÇÃO DA GERÊNCIA DE MEMÓRIA

41

3 ALOCAÇÃO DE MEMÓRIAO gerenciamento de memória é um processo altamente crítico para o sistema

operacional. Como apenas as instruções que estão na memória principal é que podem ser executadas, cabe ao sistema operacional manter na memória o maior número possível de processos, evitando desta forma a queda de desempenho no sistema como um todo.

Vamos falar a seguir dos diferentes tipos de alocação de memória, iniciando pelo mais simples de todos, implementado nos primeiros sistemas operacionais: alocação simples.

3.1 ALOCAÇÃO CONTÍGUA DE ÚNICO USUÁRIO (ALOCAÇÃO SIMPLES)

Este tipo de alocação consiste em dividir a memória em duas partes, uma para o sistema operacional e outra para o programa do usuário.

Como nos primórdios da computação apenas um programa era executado por vez, bastava ao sistema operacional, carregá-lo na memória para sua execução, entretanto era importante que o tamanho do programa fosse menor que a memória disponível, pois o mesmo deveria ser alocado integralmente na memória.

Como o programa deveria ser alocado inteiro na memória, se a área de memória disponível fosse menor que o tamanho do programa, este não poderia ser executado. Salienta-se que antigamente apesar do grande tamanho dos computadores, sua memória era limitada.

NOTA

A figura a seguir mostra a divisão da memória no esquema de alocação simples, detalhando inclusive o ponto de divisão das áreas do sistema operacional e do programa do usuário que se utilizava de um registrador com o endereço limite da memória. Toda vez que um programa era alocado na memória, os endereços eram comparados com o endereço limite do registrador, no caso de ser maior o processo era interrompido (gerado o erro de violação de acesso – access violation).


42

FIGURA 23 – ESTRUTURA DA MEMÓRIA NO SISTEMA DE ALOCAÇÃO SIMPLES

FONTE: Os autores

Destaca-se que nesse sistema de alocação, se o programa não ocupar toda a área da memória, o espaço não utilizado fica vazio e não pode ser utilizado para outro processamento.

Para resolver os problemas de incompatibilidade do tamanho dos programas com a memória livre disponível, foi criada a técnica de overlay, que consistia em dividir o programa em módulos que eram carregados na memória somente quando necessários, e substituíam os módulos já utilizados. Para essa divisão, alocava-se o espaço necessário para comportar o maior módulo do programa, obtendo um melhor aproveitamento da memória. Esses arquivos de overlay tinham a extensão OVL

NOTA

3.2 ALOCAÇÃO PARTICIONADA FIXA (ALOCAÇÃO ESTÁTICA)

Com a evolução e o crescimento da memória, uma das primeiras técnicas utilizadas para o melhor aproveitamento da memória foi dividi-la em fragmentos, denominados partições, desta forma era possível alocar várias tarefas (programas) na memória, sendo que os mesmos deveriam ser alocados em alguma partição que lhe acomodasse.


43

A grande desvantagem dessa técnica, é que como as partições eram declaradas na inicialização do sistema, sempre que necessário alterá-las, o sistema como um todo deveria parar ser reconfigurado e então reinicializado.

Outro problema dessa técnica, é que os programas poderiam executar em apenas uma partição, e mesmo que houvesse outras disponíveis, não era possível o compartilhamento de partições, isso acontecia em função da forma com que os endereços dos programas eram declarados endereços absolutos.

No endereçamento absoluto, um programa deve ser alocado em um endereço fixo definido na hora de sua compilação, portanto, se o endereço já estiver alocado por outro programa, ocorrerá um erro de alocação e o processo será cancelado.

NOTA

As partições são definidas por registradores contendo os endereços de início e fim de cada partição, sendo que na carga do programa se o conteúdo a ser alocado for maior que o endereço do registrador, ele não pode ser carregado, ocasionando uma falha de violação. A figura a seguir mostra esse mecanismo.

FIGURA 24 – ESTRUTURA DA MEMÓRIA NO SISTEMA DE ALOCAÇÃO PARTICIONADA ESTÁTICA

FONTE: Os autores


44

Mesmo permitindo que se tenham várias partições de tamanhos diversos, os programas devem ser armazenados inteiros na memória e de forma contínua, devendo permanecer na memória do início ao fim de sua execução, não podendo ocupar mais de uma partição ao mesmo tempo. Ao término da execução, os programas são retirados da memória, o que acaba gerando uma grande fragmentação desta (várias porções livres de memória que não podem ser alocadas por outros programas por não comportarem o tamanho requerido).

NOTA

Para controlar as partições livres, o sistema operacional cria uma tabela que contém o número da partição, o seu tamanho e se está alocada ou não; assim, é possível verificar em quais locais pode ser alocado determinado programa.

IMPORTANTE

3.3 ALOCAÇÃO PARTICIONADA DINÂMICA

Este tipo de alocação é um avanço em relação à alocação estática, pois permite que as tarefas definam previamente o tamanho que necessitem. Desta forma, as partições são alocadas somente conforme a necessidade de cada programa.

De certa forma, essa técnica reduz a fragmentação na hora de alocar os programas, entretanto, há uma forte incidência na hora que os programas terminam e são retirados da memória.

Contudo, a solução do problema de fragmentação se torna mais evidente, pelo fato de as partições serem alocadas dinamicamente. Sendo assim, duas soluções podem ser implementadas:

• Relocação de partições: consistem em relocar as partições eliminando os espaços entre elas, gerando assim uma grande área livre que pode ser reparticionada por novos programas (Figura 25a).

• Junção de partições adjacentes: consiste na junção das partições adjacentes vazias em uma única partição, que pode permitir a alocação de novos programas em função do aumento do espaço disponível – note que é necessário que um programa termine para que seja feita a junção das partições, no exemplo o programa B terminou de executar (Figura 25b).


45

FIGURA 25 – (A) RELOCAÇÃO DE PARTIÇÃO E (B) JUNÇÃO DE PARTIÇÕES ADJACENTES

FONTE: Os autores

Caro(a) acadêmico(a)! Leia, no final deste tópico, o texto sobre as estratégias de escolha da melhor partição de memória.

DICAS

46


4 TÉCNICAS COMPLEMENTARESAlém das melhorias e dos avanços no gerenciamento de memória, muitas

vezes, os sistemas possuíam limitações de memória física, o que ocasionou a criação de novas técnicas, discutidas nos próximos itens, dentre elas o swapping que é inclusive utilizada em conjunto com outras técnicas.

4.1 SWAPPING

Essa técnica consiste em retirar alguns programas da memória e salvá-los em disco. Ou seja, sempre que um programa precisa esperar alguma coisa, outro que precise ser executado pode ocupar seu lugar em memória, para tanto o sistema operacional precisa fazer a troca dos programas, salvando o que está esperando no disco e colocando o que precisa ser executado na área de memória liberada (figura a seguir).

FIGURA 26 – EXEMPLO DE SWAPPING DE MEMÓRIA

FONTE: Adaptado de: <http://www.thetechnicalstuff.com/swap-space/>. Acesso em: 15 fev. 2013.

Transferência

Transferência

É importante salientar que se o programa for carregado e descarregado muitas vezes da memória, este processo torna-se inviável, pois faz com que o sistema perca muito desempenho.

4.2 MEMÓRIA VIRTUAL

É uma técnica muito avançada e poderosa, pois une a memória física da máquina com um arquivo especial salvo em disco, dando a ideia de se ter muito mais memória disponível do que a memória realmente instalada, a figura a seguir mostra esse mecanismo.


47

FIGURA 27 – FUNCIONAMENTO DA MEMÓRIA VIRTUAL

FONTE: Os autores

Um fato interessante a ser destacado na memória virtual, é que um programa maior que a memória física disponível pode ser executado, pois pode ser carregado dinamicamente na memória conforme sua necessidade.

Um problema dessa técnica é que, ao acessar o disco, a execução se torna mais lenta, pois o HD tem um tempo de acesso maior (para leitura e escrita de dados) do que a memória RAM.

4.2.1 Paginação

Técnica que permite aos programas estarem alocados na memória em endereços não contíguos, ou seja, um programa pode agora ter seus dados alocados em qualquer frame (áreas da memória que agrupam as páginas), isso facilitou e resolveu um sério problema das outras formas de alocação dos programas, que era de disponibilidade contígua para alocação.

4.3 SEGMENTAÇÃO

Possibilita a divisão dos programas através de sub-rotinas, que possuem seus próprios endereços. O compilador pode, por exemplo, dividir um programa em vários segmentos, que poderiam conter: variáveis globais, variáveis locais, vetores, endereços de funções, endereços de procedimentos etc.

48


Nos sistemas operacionais distribuídos, a gerência de memória utiliza segmentação e paginação, contudo especifica serviços que gerenciam a comunicação entre os processos distribuídos. Muitas vezes, um processo é disparado para ser executado em outra máquina (mais ociosa), pois se fossem executadas as várias páginas em micros separados, uma queda de performance pode ocorrer, inviabilizando o funcionamento do sistema.

NOTA

Caro(a) acadêmico! Para aprofundar seus conhecimentos sobre gerenciamento de memória, leia o capítulo 2 do livro: Introdução aos Sistemas Operacionais, de FLYNN, Ida M.; MCHOES, Ann Mclver. Trad.: Marcelo Alves Mendes. São Paulo: Pioneira Thomson Learning, 2002.

DICAS


Estratégias de Alocação de Partição

Os sistemas operacionais implementam, basicamente, três estratégias para determinar em qual área livre um programa será carregado para execução. Essas estratégias tentam evitar ou diminuir o problema da fragmentação externa.

A melhor estratégia a ser adotada por um sistema depende de uma série de fatores, sendo o mais importante o tamanho dos programas processados no ambiente. Independentemente do algoritmo utilizado, o sistema possui uma lista de áreas livres, com o endereço e tamanho de cada área.

• Best-fit: Na estratégia best-fit, a melhor partição é escolhida, ou seja, aquela em que o programa deixa o menor espaço sem utilização. Nesse algoritmo, a lista de áreas livres está ordenada por tamanho, diminuindo o tempo de busca por uma área desocupada. Uma grande desvantagem desse método é consequência do próprio algoritmo. Como é alocada a partição que deixa a menor área livre, a tendência é que cada vez mais a memória fique com pequenas áreas não contíguas, aumentando o problema da fragmentação.


49

• Worst-fit: Na estratégia worst-fit, a pior partição é escolhida, ou seja, aquela em que o programa deixa o maior espaço sem utilização. Apesar de utilizar as maiores partições, a técnica de worst-fit deixa espaços livres maiores que permitem a um maior número de programas utilizar a memória, diminuindo o problema da fragmen tação.

• First-fit: Na estratégia first-fit, a primeira partição livre de tamanho suficiente para carregar o programa é escolhida (Figura 19c). Nesse algoritmo, a lista de áreas livres está ordenada crescentemente por endereços. Como o método tenta primeiro utilizar as áreas livres de endereços mais baixos, existe uma grande chance de se obter uma grande partição livre nos endereços de memória mais altos. Das três estratégias apresentadas, a first-fit é a mais rápida, consumindo menos recursos do sistema.

FONTE: MACHADO, Francis Berenger; MAIA, Luiz Paulo. Arquitetura de Sistemas Operacionais. LTC, 2002. p. 165-167.

50

RESUMO DO TÓPICO 3

Caro(a) acadêmico(a)! No Tópico 3, você estudou os seguintes assuntos:

• As memórias possuem um nível hierárquico baseado em seu custo e velocidade.

• Verificou que a gerência de memória é um processo extremamente importante para o funcionamento do computador, pois dela depende o correto funcionamento dos programas.

• Nos primeiros sistemas operacionais, a forma de alocação de memória era contígua, permitindo apenas um programa alocado por vez.

• A alocação particionada estática melhorou a forma de alocação dos programas, mas deveria ser reprogramada sempre.

• A alocação particionada dinâmica permitiu manipular a memória mais facilmente, principalmente com a desfragmentação e junção de partições adjacentes.

• O swapping permitiu a troca dos programas em execução por outros em espera, utilizando o disco para tal.

• A memória virtual ampliou a memória física da máquina, e permitiu através da paginação a alocação não consecutiva dos endereços dos programas.

• A segmentação permite uma visão mais clara da divisão dos programas.

51

Caro(a) acadêmico(a)! Resolva as questões a seguir para aprofundar seus conhecimentos e reforçar seu aprendizado sobre a gerência de memória.

1 Leia o artigo “Sistemas Operacionais”, disponível em: <http://www.lume.ufrgs.br/bitstream/handle/10183/19242/000102159.pdf> e a partir da leitura:

a) Faça uma resenha do artigo.

b) Elenque pelo menos duas características de cada item do artigo que você julgue importante, e justifique sua resposta.

AUTOATIVIDADE

53

UNIDADE 2

GERÊNCIA DE PROCESSOS E DISPOSITIVOS


PLANO DE ESTUDOS

A partir do estudo desta unidade, o(a) acadêmico(a) estará apto(a) a:

• conhecer a forma com que os processos são gerenciados;

• compreender as formas de gerenciamento dos dispositivos de hardware.

Esta unidade está dividida em três tópicos, sendo que, ao final de cada um deles, você encontrará atividades que lhe auxiliarão na apropriação do co-nhecimento.

TÓPICO 1 – ESTRUTURA E FUNCIONAMENTO DOS PROCESSOS

TÓPICO 2 – GERENCIAMENTO DO PROCESSOADOR

TÓPICO 3 – GERENCIAMENTO DE DISPOSITIVOS

55

TÓPICO 1

ESTRUTURA E FUNCIONAMENTO DOS PROCESSOS

UNIDADE 2

1 INTRODUÇÃONos sistemas antigos, apenas um programa era executado por vez e o

mesmo alocava-se na memória (como visto no tópico anterior) e alocava todos os recursos da máquina. Contudo, a evolução implementou a multitarefa, que é a possibilidade de executar vários programas simultaneamente. Esses programas devem ser escalonados e ganham conforme essas regras de escalonamento o processador, podendo assim executar seu conjunto de instruções.

No Tópico 3, você estudará as diversas formas e quais mecanismos o sistema operacional utiliza para escalonar um processo.

ESTUDOS FUTUROS

Quando falamos em programa, tarefa ou job, estamos nos referindo em termos gerais a processos, que com o advento dos sistemas multitarefas passou a ser o termo mais usado para designar um programa em execução, embora os termos anteriores tenhas suas particularidades para cada tipo de atividade, podemos a grosso modo dizer que: programa = tarefa = job = processo.

Qualquer sistema operacional que execute mais de um processo ao mesmo tempo, obrigatoriamente deve oferecer mecanismos para controle desses processos. Neste tópico veremos o que é um processo e quais suas características, além de conceitos de threads e subprocessos.

UNIDADE 2 | GERÊNCIA DE PROCESSOS E DISPOSITIVOS

56

2 CONCEITO DE PROCESSOPode-se dizer que um processo é um programa em execução (ativo) e que

programa é um conjunto de códigos (passivo) que quando carregado em memória vira um processo.

Desta forma é possível, por exemplo, ter um mesmo programa executando vários processos, como um editor de textos (um programa), com vários documentos distintos abertos (processos).

Quando da criação de um processo, o sistema operacional, aloca o programa criando recursos para o mesmo, podemos dividi-los em três partes conforme Machado e Maia (2002) (figura a seguir):

• Contexto de software: determina os limites dos recursos que podem ser alocados ao processo, como memória, quantidade de arquivos abertos, prioridade etc.

• Contexto de hardware: armazena o conteúdo dos registradores tais como a pilha do programa, o contador de programa, status etc.

• Espaço de endereçamento: é responsável por armazenar as instruções que serão executadas pelo processo.

FIGURA 28 – SISTEMAS OPERACIONAIS DISTRIBUÍDOS

FONTE: Machado e Maia (2002, p. 66)

TÓPICO 1 | ESTRUTURA E FUNCIONAMENTO DOS PROCESSOS

57

2.1 BLOCO DE CONTROLE DO PROCESSO (PCB)

Quando da criação de um processo, o sistema operacional cria uma estrutura chamada de Bloco de Controle do Processo (PCB – Process Control Block) responsável por gerenciar todos os contextos do processo (hardware, software e endereços do programa). É fundamental que o PCB armazene (MACHADO; MAIA, 2002):

• Nome do processo e/ou número do processo• Ponteiros.• Estado do processo.• Prioridade.• Registradores.• Limites de memória.• Listas de arquivos abertos.

O PCB é armazenado em uma área de memória reservada de acesso exclusivo do sistema operacional, é possível limitar a quantidade de processos que podem ser executados no sistema operacional, limitando o tamanho dessa área de memória.

As alterações necessárias no PCB, como mudança de prioridade, atualização de endereços de memória, contadores de programa (tempo de execução, tempo ocioso, tempo de acesso etc.) ou até mesmo finalização do processo, são realizadas única e exclusivamente pelo sistema operacional. Na necessidade do usuário fazer alguma alteração no processo, é necessário que ele se utilize das System Calls, que são chamadas ao sistema, denominadas de porta de acesso às funções protegidas do núcleo do sistema operacional.

NOTA

2.2 ESTADOS DO PROCESSO

Um processo não pode executar exclusivamente, monopolizando a CPU, pois dessa forma caracterizaria um sistema monotarefa (executando apenas uma tarefa por vez). Assim é necessário que se faça a troca dos processos (escalonamento) para que todos executem uma determinada fatia do tempo.

Para que a troca de processo ocorra, é necessário que os mesmos mudem de estado, identificando a situação em que se encontram. Os cinco estados possíveis são:


58

• Novo (new): quando o processo é criado, iniciado com os valores padrão dos seus registradores e aceito pelo sistema operacional, seu estado inicial é novo.

• Pronto (ready): o processo encontra-se nesse estado quando aguarda apenas que o mecanismo de escalonamento do sistema operacional o coloque para executar na CPU.

• Execução (running): estado em que o processo entra quando a CPU executa suas instruções. Apenas um processo pode estar nesse estado por vez (em sistemas monoprocessados), contudo, se o hardware possuir mais de um processador (multiprocessado), pode-se ter mais de um processo no estado de execução.

• Espera: o processo encontra-se esperando quando aguarda a ação de algum evento externo. Podemos subdividir o estado de espera em dois grupos:

- Espera (wait): quando o processo aguarda a conclusão de uma operação em um recurso que já foi garantido.

- Bloqueado (blocked): quando o processo aguarda a liberação de um recurso que está alocado para outro processo.

• Encerrado (finish): quando o processo termina sua execução, que pode ocorrer de forma normal ou por erro de execução.

O sistema operacional mantém duas listas, uma de processos prontos e outra de processos em espera, quando um processo termina sua espera, ele entra na lista de prontos (figura a seguir).

Alguns autores não fazem referência aos estados de novo e terminado dos processos. Desta forma representam apenas os estados: executando, espera e pronto. Isso ocorre por conta de que todos os processos precisam ser iniciados e terminam de alguma forma, fazendo com que esses estados (novo e terminado) sempre ocorram.

NOTA


59

FIGURA 29 – LISTA DE PROCESSOS PRONTOS E EM ESPERA

FONTE: Os autores

2.3 MUDANÇA DE ESTADOS DO PROCESSO

Conforme o processo executa, vai mudando de estado, seja por determinação do escalonador ou por algum evento que ocorreu e gerou uma interrupção.

Conforme Silberschatz, Galvin e Gagne (2004), as mudanças de estado de um processo são (figura a seguir):

• Novo – Pronto: quando o PCB (processo) é criado e alocado na área reservada ao sistema operacional, seguindo então para a lista de prontos.

• Pronto – Executando: é realizada pelo escalonador de acordo com a política implementada pelo sistema operacional.

• Executando – Pronto: quando o processo é interrompido por outro de maior prioridade, ou quando termina de executar em sua fatia de tempo conforme as regras de escalonamento implementadas pelo sistema operacional.

• Executando – Espera: quando o processo realiza uma operação de I/O ele entra na fila de espera, até que a solicitação seja realizada.

• Espera – Pronto: é realizado pelo escalonador quando este recebe um sinal indicando que a solicitação de I/O do processo foi realizada com sucesso.

• Executando – Terminado: acontece quando o programa termina sua execução com sucesso ou com erro, quem realiza essa transição é o escalonador de processos.


60

FIGURA 30 – MUDANÇAS DE ESTADO DO PROCESSO

FONTE: Silberschatz, Galvin e Gagne (2004, p. 64)

Nos sistemas distribuídos, dependendo do escalonador, um processo pode entrar em estado de executando em outro computador, importante destacar que se esse processo não for bem planejado, pode gerar perda de processamento com tempos de acesso à rede.

NOTA

3 SUBPROCESSOQuando o processo cria um novo processo hierarquicamente, denomina-se

processo filho ou subprocesso. É possível assim, dividir a aplicação em várias partes que trabalham concorrentemente.

Os subprocessos são processos como outro qualquer, possuindo PCB, contexto e concorrem com os processos já existentes, diferenciando-se pelo fato de que estão relacionados numa hierarquia de pais e filhos, onde no momento de encerramento do processo pai, todos os seus processos filhos também são encerrados.

O uso de subprocesso é aplicado, por exemplo, numa consulta a banco de dados, onde vários usuários acessam uma mesma base. Se algum deles requisitar um relatório, os demais devem aguardar o término da operação. Desta forma, o ideal seria criar um subprocesso responsável pelo relatório, assim aumentaria a quantidade de dados processados (throughput) pela aplicação.

NOTA


61

Throughput (ou taxa de transferência) é a quantidade de dados transferidos de um lugar a outro, ou a quantidade de dados processados em um determinado espaço de tempo.

DICAS

Na figura a seguir podemos observar a hierarquia dos processos e seus subprocessos.

FIGURA 31 – SUBPROCESSOS

FONTE: Os autores

4 THREAD

A thread possui a mesma ideia de um subprocesso, entretanto, compartilha a mesma área de dados com o programa principal. Sua principal vantagem é a economia de recursos do sistema, pois não há criação de PCB, já que o contexto da thread é comum ao programa principal.

Com threads pode-se, por exemplo, fazer a correção ortográfica de um documento, no mesmo instante que é realizada sua transmissão para um e-mail sem atrapalhar a digitação de texto novo pelo usuário.

Na figura a seguir temos um gráfico demonstrando o compartilhamento de recursos do processo com suas threads. Note que o processo é um só compartilhando, a mesma área de memória com suas threads, diferenciando apenas os dados processados por cada uma delas.


62

FIGURA 32 – THREAD

FONTE: Os autores

Caro(a) acadêmico(a)! Para aprofundar seus conhecimentos sobre threads leia o artigo “Multithreading em ação com VB .NET”, de Alexandre Santos Lobão no site da Microsoft Developer Network – MSDN, disponível em: <http://www.microsoft.com/brasil/msdn/ Tecnologias/vbnet/Multithreading.mspx>.

DICAS

5 INTERRUPÇÕES E EXCEÇÕESDurante a execução normal de um programa podem ocorrer eventos que

precisam ser tratados pelo sistema operacional, podemos dividir esses eventos em:

• Interrupções (assíncrono): são eventos que podem ser gerados por hardware ou por software e são independentes do programa executando, devendo ser tratados pelo sistema operacional. É exemplo de interrupção um periférico que avisa a CPU que precisa carregar dados para a memória.

• Exceções (síncrono): esse tipo de evento ocorre quando o próprio programa gera um erro, por exemplo, um estouro de pilha ou uma divisão por zero.


63

A Intel especifica as seguintes exceções:0 Erro de Divisão (Divide Error)1 Exceções de Debug (Debug Exceptions)2 Faz o cascateamento do controlador3 Ponto de parada de execução (Breakpoint)4 Overflow5 Checagem de Limites (Bounds Check)6 Código Operacional Inválido (Invalid Opcode)7 Coprocessador não disponível (Coprocessor Not Available)8 Falha Dupla (Double Fault)9 Segmento de Coprocessador Ultrapassado (Coprocessor Segment Overrun)10 TSS Inválida (Invalid TSS)11 Segmento Não Presente (Segment Not Present)12 Exceção da Pilha (Stack Exception)13 Exceção de Proteção Geral – Falha Tripla (General Protection Exception - Triple Fault)14 Falha de Página (Page Fault)15 Reservada (Reserved)16 Erro do Coprocessador (Coprocessor Error)

NOTA

Quando ocorre alguma interrupção, o controle é desviado para a rotina de tratamento correspondente e executado, somente depois de sua execução o controle volta para o programa anterior. A figura a seguir mostra esse processo.

FIGURA 33 – INTERRUPÇÕES: DESVIO PARA ROTINA DE TRATAMENTO

FONTE: Os autores


64

As interrupções possuem prioridades, sendo que algumas podem ser mascaradas (desabilitadas pelo processador) outras são consideradas não mascaráveis (devem obrigatoriamente ser tratadas). É graças às interrupções que temos a possibilidade de ter sistemas multiprogramáveis, pois é através delas que o sistema operacional controla o sincronismo dos processos e controla os periféricos e dispositivos do sistema.

NOTA


Interrupções, Exceções e IDTs

Apesar de já termos citado e explicado parcialmente o que são interrupções, vamos dar uma revisada no assunto. A Intel define uma interrupção como “elas [as interrupções] alteram o fluxo normal do programa para manipular eventos externos ou para reportar erros ou condições de exceção”.

Esta definição é um tanto simplista e deixa de fora alguns aspectos relevantes. O primeiro deles é como ocorre uma interrupção. Já sabemos que uma interrupção pode ser gerada por software ou por hardware. Tomemos como exemplo uma interrupção de hardware quando uma tecla é digitada. Se tudo estiver configurado corretamente, quando uma tecla é digitada, o teclado envia um pedido de interrupção para a CPU. Neste caso, a CPU pára o código em execução e chama uma função que fará a leitura da porta 0x60 (a porta de saída do teclado) para determinar o que o teclado está enviando. Esta função, então, deverá devolver o controle para o que estava sendo executado antes do teclado ter enviado o pedido de interrupção. O código original, com frequência, nem fica sabendo que ocorreu uma interrupção. Uma interrupção também pode ser gerada via software através da instrução Assembly int.

Neste ponto é interessante saber que o sistema de interrupções pode ser ativado ou desativado através dos comandos de Assembly cli (desativar) e sti (ativar).

Não é só o teclado que pode disparar uma interrupção. Qualquer outro dispositivo do computador, como HDs, drives de disquete, placas de som, drives de CD-ROM, placas de rede, etc., podem (e precisam) fazer o mesmo. Todos utilizam interrupções por dois motivos: para avisar o sistema operacional que completaram alguma tarefa ou que possuem dados para o sistema operacional. O PIT (Programable Interrupt Timer – Temporizador de Interrupções Programável) também dispara interrupções em intervalos de tempo pré-determinados, o que é muito útil na multitarefa preemptiva.


65

Programas de usuários também podem usar interrupções. O MS-DOS e a BIOS fornecem várias interrupções para este fim. As interrupções da BIOS só funcionam em modo real.

Uma ISR (Interrupt Service Routine – Rotina do Serviço de Interrupções) é o código executado quando ocorre uma interrupção, portanto existe uma ISR para cada interrupção. A forma como a CPU fica sabendo qual ISR executar será analisada mais adiante.

Nada impede que se codifique ISRs próprias, ainda mais quando se pretende escrever um novo sistema operacional. Pode parecer difícil escrever um código que não conflite com o processo em execução, mas a coisa é menos complicada do que se pensa. É que a CPU se encarrega automaticamente da parte mais complicada, salvando os registradores SS, EIP, ESP e CS na pilha. Se o ponteiro da pilha estiver apontando para o mesmo endereço no início da ISR e quando a instrução iret for chamada, então esta instrução restaura os registradores automaticamente. Portanto, é só controlar a pilha: caso um ou mais dos registradores EAX, EBX, ECX, EDX, EBP, ESI, EDI, ES, DS, FS ou GS forem utilizados na função (o que é mais do que provável), primeiro é preciso salvá-los na pilha e não esquecer-se de restaurá-los após o uso.

[...]

As IRQs (Interrupt Request – Requisição de Interrupção) são interrupções disparadas pelo hardware. Existem 16 no total e são numeradas de 0 a 15. O PIC (Programable Interrupt Controller) mapeia estas IRQs em dois blocos com 8 IRQs cada. É padrão que as 8 primeiras IRQs sejam mapeadas em interrupções de 8 a 15 e que as 8 últimas seja mapeadas em interrupções de 112 a 119. Isto acaba interferindo com as exceções (o que será visto adiante), de modo que se torna necessário remapear as IRQs para um bloco diferente de números de interrupção.

Quando ocorre uma interrupção de hardware, uma série de eventos é desencadeada. Para simplificar o processo e aumentar a compatibilidade dos dispositivos nas diferentes plataformas, quando um dispositivo dispara uma IRQ, ele a dirige para o PIC enviando toda a informação necessária. O PIC identifica o número da IRQ e depois avisa a CPU. A CPU, assim que terminar a instrução corrente, executa o número da interrupção recebida.

Uma exceção é uma interrupção que ocorre quando alguma coisa dá errado com o código que está sendo executado. Pode ser uma divisão por zero, uma tentativa de acessar um segmento inexistente ou coisa parecida.

Existem 15 tipos de exceções na CPU x86, classificadas como interrupções de 0 a 16, o que significa que existem algumas “falhas” na sequência. Estas falhas correspondem a interrupções reservadas pela Intel, talvez para uso futuro.

[...]


66

Uma IDT (Interrupt Descriptor Table – Tabela de Descritores de Interrupção) é um array de descritores usado para associar interrupções e exceções às respectivas ISRs. É o mapa da mina para a CPU saber qual rotina precisa ser executada quando receber uma chamada de interrupção. Cada descritor é composto por 8 bytes e a IDT pode conter no máximo 256 descritores (o total de interrupções no PC também é 256). Quando se cria uma IDT, não é necessário que a tabela contenha 256 descritores, basta usar um para cada interrupção que será tratada no sistema operacional. Para informar a localização da IDT para a CPU, usamos a instrução Assembly LIDT.

[...]

FONTE: Aldeia Numaboa. Interrupções, Exceções e IDTs. Disponível em: <http://www.numaboa.com.br/informatica/oficina/123-so/744-interrupcoes>. Acesso em: 2 jan. 2013.

67

RESUMO DO TÓPICO 1Caro(a) acadêmico(a)! No Tópico 2, você estudou os seguintes assuntos:

• Processos são ativos e programas são passivos.

• Os processos possuem: contexto de hardware, contexto de software e espaço de endereçamento.

• O PCB é a essência do processo.

• Um processo apresenta estados que são: novo, pronto, execução, espera e encerrado.

• A mudança de estados de um processo é a base de seu funcionamento.

• Subprocessos são processos filhos de um processo e alocam recursos como tal.

• Thread são similares a processos, entretanto compartilham a mesma área de dados.

• Interrupções e exceções são fundamentais para o sistema operacional.

68

AUTOATIVIDADE

Caro acadêmico(a)! Resolva as questões a seguir para aprofundar seus conhecimentos e reforçar seu aprendizado sobre os processos.

1 O que é um processo?

2 O PBC deve armazenar que tipo de informação?

3 Quais são os estados de um processo e qual é a sua função?

4 O estado de espera apresenta quais particularidades?

5 Quais são as possíveis mudanças de estado de um processo?

6 Baseado na Figura 31, responda:

a) Ao encerrar o processo F, qual(is) processo(s) será(ão) finalizado(s)?b) Ao encerrar o processo B, qual(is) processo(s) será(ão) finalizado(s)?

7 Conceitue:

a) Thread.b) Interrupções.c) Exceções.

69

TÓPICO 2

GERENCIAMENTO DO PROCESSADOR

UNIDADE 2

1 INTRODUÇÃOQuando um computador é multiprogramado, temos vários processos

concorrendo entre si disputando a CPU. Desta forma cabe ao sistema operacional decidir qual é o processo que irá ganhar a CPU em determinado momento. A essa escolha damos o nome de escalonamento de processos.

A decisão é tomada a partir de vários fatores, podendo ser por tempo, por prioridade, tamanho do processo etc. O mecanismo de escalonamento é uma das atividades mais complexas que o sistema operacional desempenha.

Neste tópico abordaremos as formas de escalonamento de processos.

2 CONCEITOS BÁSICOSUm dos objetivos de um sistema multiprogramável, é manter a CPU

ocupada com algum processamento, ou seja, maximizar o uso da CPU.

As máquinas que possuem só um processador podem executar apenas um processo por vez. Assim, com o escalonamento temos diversos programas que ganham o direito de usar a CPU por um determinado tempo, dando a impressão de que estamos executando vários programas ao mesmo tempo.


70

Ter vários programas na memória ajuda o processo de escalonamento, pois evita a carga do programa para a memória, tarefa relativamente lenta, pois os dados estão armazenados no disco rígido, que é muitas vezes mais lento que a memória.É importante salientar que, para cada processador, podemos ter um programa executando; logo, em sistemas com processadores duplos como DualCore ou Core 2 Duo, podemos, sim, executar dois processos simultaneamente. Existem processadores mais modernos com até quatro núcleos que podem simular outros núcleos, caso do i7 da Intel.

NOTA

2.1 CRITÉRIOS DE ESCALONAMENTO

Vários fatores influenciam na hora de se decidir qual processo irá ganhar a CPU e o direito de executar. Para isso são determinados critérios que devem ser observados na hora de se executar um programa.

Em Machado e Maia (2002), são propostos os seguintes critérios:

• Utilização do processador: desejado que o sistema fique ocupado a maior parte do tempo. Quanto maior a utilização. melhor aproveitamento (um sistema que utiliza 30% é bem menos eficaz que um que consegue utilizar a CPU em 90% do tempo).

• Throughput: determina a quantidade de processos que podem ser executados num intervalo de tempo, quanto maior a quantidade de processos executados maior o throughput.

• Tempo de processador (CPU): determina o tempo que um processo fica no estado de executando, ou seja, está rodando na CPU.

• Tempo de espera: é o tempo que um processo aguarda na fila de espera para ser executado, quanto menor esse tempo melhor.

• Tempo de turnaround: é o tempo que um processo leva desde a sua criação até sua conclusão, levando em consideração todo o tempo de alocação, espera, entrada e saída. Os mecanismos de alocação de processos visam minimizar o turnaround dos processos.

• Tempo de resposta: tempo de uma requisição ao sistema ou aplicação e o instante em que ela é atendida.

TÓPICO 2 | GERENCIAMENTO DO PROCESSADOR

71

Quando temos vários processos que disputam um número finito de recursos, podem ocorrer situações de deadlock, onde um processo entra em estado de espera pelo recurso, o escalonador o tira da CPU. Contudo, este processo jamais pode retornar a executar se o recurso não for liberado.Na leitura complementar desta unidade há um texto sobre deadlock.

NOTA

2.2 OBJETIVOS DO ESCALONAMENTO

Um dos objetivos do escalonador é justiça, ou seja, processos semelhantes devem ter um critério de escalonamento semelhante, pois não é justo dar mais tempo de CPU a um processo que tem papel equivalente a outro. Da mesma forma é importante garantir que todos os processos executem evitando o que chamamos de starvation, onde um processo de menor prioridade sempre é deixado de executar em função de outros de maior prioridade.

Outro objetivo é manter todas as partes do sistema o mais ocupado possível, ou seja, dispositivos de Entrada e Saída e CPU devem ficar o menor tempo possível ocioso, desta forma tem-se um ganho de processamento.

Além disso, o escalonador deve garantir que o critério de escalonamento seja bem aplicado.

3 TIPOS DE ESCALONAMENTOPara Machado e Maia (2002) existem duas políticas de escalonamento

preemptivos (utilizadas em sistemas complexos, porém mais flexíveis) e não preemptivos (sistemas mais simples):

• Preemptivo: um escalonamento é preemptivo quando o sistema permite a interrupção de um processo para a execução de outro. Desta forma, processos mais prioritários podem ganhar a atenção da CPU, com a vantagem de se ter uma execução mais uniforme entre os processos.

• Não preemptivo: neste tipo de escalonamento, quando um processo ganha a CPU, nenhum outro pode interrompê-lo tirando-o da execução.


72

3.1 TIPOS DE ESCALONAMENTO NÃO PREEMPTIVOS

Neste item iremos abordar alguns tipos de escalonamento não preemptivos.

3.1.1. First-in-first-out (FIFO)

É um algoritmo extremamente simples, onde basta a implementação de uma fila onde o primeiro programa que entra é o primeiro a ser selecionado para a execução.

Quando o processo ganha a CPU ele é executado até o fim sem ser interrompido, ou até que realize uma Entrada/Saída, onde neste momento é realizada sua E/S e o processo é recolocado no fim da fila (MACHADO; MAIA, 2002).

A figura a seguir mostra um sistema com dois processos (A e B), onde a execução se alterna sempre que um deles efetua uma operação de Entrada/Saída. Observe que o tempo de execução do processo que ganha a CPU vai até o momento em que realiza uma nova operação de Entrada/Saída.

FIGURA 34 – ESCALONAMENTO FIFO



73

3.1.2 Escalonamento job mais curto primeiro

Também conhecido por Escalonemanto Shortest-Job-First (SJF), prioriza os processos menores, ou seja, aqueles que executam em menos tempo.

O grande problema desta técnica é definir o tempo exato que um programa irá levar para sua execução completa, em ambientes de produção onde um processo é executado várias vezes de forma repetida, o cálculo desse tempo pode ser mais preciso, contudo, em outras situações na maioria dos casos é um tempo padrão estimado (MACHADO; MAIA, 2002).

Há também que se levar em conta os tempos que o processo irá demorar realizando operações de entrada e saída. A figura a seguir mostra o mecanismo de escalonamento SJF.

FIGURA 35 – ESCALONAMENTO SJF


3.1.3 Escalonamento cooperativo

Neste mecanismo, quem determina que o tempo de execução encerrou é o próprio processo, ou seja, o processo voluntariamente libera a CPU para o próximo processo na fila de pronto (cooperação).

O grande problema dessa técnica é que como não existe intervenção do sistema operacional, um determinado processo pode alocar a CPU indefinidamente por tempo indeterminado (um programa em looping, por exemplo, jamais irá liberar a CPU).


74

Os sistemas Windows 3.1 e 3.11 (figura a seguir) utilizavam esta técnica de escalonamento (chamada de multitarefa cooperativa), onde o processo que estava em execução, constantemente verificava uma fila de mensagens a fim de detectar a solicitação de algum outro processo que desejasse usar a CPU, em função das mensagens recebidas o processo em execução cedia a vez para o processo com maior necessidade de execução.

FIGURA 36 – AMBIENTE DO WINDOWS 3.11

FONTE: Os autores

Se não houver o mínimo de intervenção do sistema operacional, programas com loops infinitos, poderiam ser escritos para travar o sistema, o que seria a forma mais básica de implementação de “vírus”.

NOTA

3.2 ESCALONAMENTO PREEMPTIVO

Neste item serão abordadas algumas técnicas de escalonamento preemptivo.


75

3.2.1 Escalonamento circular

Também conhecido como round robin scheduling é utilizado em sistemas de tempo compartilhado, e sua técnica é estipular tempos determinados para cada processo. Desta forma, ao encerrar o tempo, o processo é deslocado para o fim da fila. No caso de o processo encerrar antes de terminar seu tempo, o próximo processo da fila é escalonado (figura a seguir).

FIGURA 37 – ESCALONAMENTO CIRCULAR

FONTE: Os autores

A principal vantagem desta técnica é impedir que um processo monopolize a CPU, pois o tempo dos processos é controlado pelo sistema operacional. Em contrapartida, o grande problema desta técnica é dar tempos iguais para os processos. Assim, um processo que necessite de um tempo de CPU maior terá o mesmo tempo de um processo que supostamente seria menos importante para determinada operação.

Para minimizar o problema dos tempos iguais, implementações com filas auxiliares são propostas para resolver esse problema, sendo que nestas filas os processos teriam tempos de escalonamento variado.

3.2.2 Escalonamento por prioridades

Este tipo de escalonamento atribui prioridades aos processos (através de um valor armazenado em seu PCB). Desta forma, os processos que possuem o maior valor de prioridade são executados primeiro. No caso de existir processo com prioridade igual, o mecanismo de circular é implementado para a execução.

De tempos em tempos, o processador percorre a fila de processos para verificar se existe algum processo com prioridade maior, se houver, o processo corrente é substituído pelo processo de maior prioridade.


76

Conforme o sistema operacional determina, a forma de associação das prioridades, se podem ter processos que nunca serão executados por sua prioridade ser baixa (starvation). Para solucionar esse problema, alguns sistemas operacionais implementam prioridades dinâmicas, onde depois de um tempo em execução o processo decai de prioridade mudando para uma lista de processos menos prioritários, dando a vez a todos os processos.

A figura a seguir mostra o funcionamento do escalonamento por prioridades.

FIGURA 38 – ESCALONAMENTO CIRCULAR


3.2.2.1 Escalonamento circular com prioridades

Esta técnica implementa além da prioridade, fatias de tempo. Assim, há um melhor equilíbrio entre a execução dos processos, pois mesmo os de menor prioridade terão uma fatia de tempo a ser executada.

Amplamente utilizado em sistemas de tempo compartilhado.

3.2.3 Múltiplas filas

Quando é possível a classificação dos processos em grupos, por exemplo, processos do sistema, processos batch, processos de alta interação etc., é possível a implementação de filas que possuem seu próprio mecanismo de escalonamento.

Cada fila possui sua própria prioridade, o sistema operacional apenas escalona processos de outra fila quando a fila de mais alta prioridade está vazia.

A figura a seguir mostra um escalonamento por múltiplas filas, onde as filas superiores têm maior prioridade de execução pelo tipo de processo que elas controlam, quanto mais alta a prioridade da fila, mais crítico é o processo para o sistema.


77

Uma alternativa para eliminar a necessidade de esvaziar uma fila de prioridade superior antes de executar processos de filas menos prioritárias, seria atribuir fatias de tempo para as filas (80%, 9%, 5%, 3%, 2%, 1%), desta forma todos os processos executariam, mesmo os de menor prioridade (SILBERSCHATZ; GALVIN; GAGNE, 2004).

FIGURA 39 – ESCALONAMENTO POR MÚLTIPLAS FILAS

FONTE: Silberschatz, Galvin e Gagne (2004, p. 106)

3.2.3.1 Múltiplas filas com realimentação

É muito semelhante ao mecanismo de escalonamento por múltiplas filas, contudo os processos devem trocar de fila conforme seu processamento. Através da detecção pelo sistema operacional do comportamento do processo, ele é alocado dinamicamente na fila que melhor atende sua necessidade.

Esse tipo de implementação torna o algoritmo de escalonamento mais generalista, atendendo a todos os tipos de processos.

O maior problema dessa implementação é o alto overhead dos processos, ou seja, a grande quantidade de verificação dos processos para enquadramento na fila ideal gera grande perda de tempo pelo sistema, e consequentemente um atraso na execução da tarefa desejada.

A figura a seguir representa um mecanismo de escalonamento por múltiplas filas com realimentação.


78

FIGURA 40 – ESCALONAMENTO POR MÚLTIPLAS FILAS COM REALIMENTAÇÃO

FONTE: Os autores

4 ESCALONAMENTO DE SISTEMAS EM TEMPO REALDeterminam a forma com que os processos devem ser escalonados

dentro de sistemas onde o fator tempo é crítico. Assim, o processo que tem maior necessidade de ser executado tem prioridade sobre todos os demais processos do sistema, podemos dividi-los em tempo real crítico e tempo real não crítico.

Sistemas em tempo real são utilizados para controle de processos, como sistemas que controlam indústrias, tráfego aéreo, usinas de energia, navios, plataformas de petróleo etc.Nestes sistemas, a resposta deve ser imediata, não sendo permitidas falhas pelos limites de tempo de cada processo.

NOTA


79

4.1 TEMPO REAL CRÍTICO – RÍGIDOS

Neste tipo de sistema, o gerenciador de processos necessita saber antecipadamente o tempo necessário para a execução do processo bem como todos os recursos que irá alocar, pois o processo só é aceito se todas as condições de recursos puderem ser atendidas, pois é necessário que se garanta a execução do mesmo do início ao fim e em um determinado tempo específico.

Neste caso, a falha é crítica, sua ocorrência pode acarretar em danos irreversíveis, podemos citar o ABS de um carro, que se falhar, pode machucar ou até tirar a vida de uma pessoa.

4.2 TEMPO REAL NÃO CRÍTICO – MODERADOS

Essa abordagem é menos restritiva, pois permite atribuir prioridades ao processo, sendo a execução dos prioritários superior aos menos prioritários. Contudo, o escalonador deve ser bem elaborado, a fim de realmente priorizar os processos mais críticos ao sistema, pois mesmo com a prioridade alta, certos processos devem ter um tempo maior de execução sobre outros.

O processamento, neste caso, é importante, todavia, a falha não prejudica a ação como um todo, podendo restaurar o sistema se necessário. Neste caso, podemos citar um gravador de DVD, se ele falhar, apenas a mídia será perdida. O processo pode ser recomeçado.

O importante é garantir que os processos mais prioritários sejam executados.

5 GERENCIAMENTO DE PROCESSOS EM SISTEMAS DISTRIBUÍDOS E DE REDE

Nos sistemas distribuídos e de rede, os mecanismos de escalonamento são os mesmos dos sistemas tradicionais, com a diferença que o escalonador de processos pode alocar os recursos em sistemas distintos, ou seja, máquinas que podem estar em locais diferentes.

Há nestes sistemas o gerenciador de CPUs que fornece os critérios e mecanismos para criar, apagar, renomear, nomear, abortar, localizar, escalonar, bloquear, executar e sincronizar os processos.

Para alocar um processo a ser rodado em outra máquina, devemos seguir os seguintes passos:


80

1.Conectar-se à rede.2.Instruir o sistema local a migrar os dados ou processo para o sistema remoto.3.Enviar uma requisição ao sistema remoto para que o processo seja executado

naquele sistema.

A partir desse ponto o processo remoto trata o processo como se fosse um processo local, sem nenhuma intervenção externa. A forma de comunicação dos processos pode ser dada por mensagens ou portas (também chamadas de canais). As mensagens fornecem as ferramentas para o gerenciador de CPU controlar os processos.

Outra característica, é que os processos podem ser executados nas máquinas que oferecem os recursos que os mesmos necessitam para rodar. Desta forma, a velocidade de execução é diminuída, já que os processos não precisam aguardar a liberação de um recurso alocado na máquina local.

Nos sistemas de rede, o Sistema Operacional de Rede, cria uma camada (Sistema Operacional) que roda localmente na máquina, sendo que as requisições e respostas para os nós da rede são realizados de forma transparente. A figura a seguir mostra a troca de mensagens entre os sistemas de rede.

FIGURA 41 – TROCA DE MENSAGENS ENTRE OS SISTEMAS OPERACIONAIS DE REDE

FONTE: Os autores


81


Ocorrência de Deadlock

Deadlock é um problema significativo que pode surgir até mesmo numa comunidade que coopera ou compete por processos. Ele é uma falha e não um erro ocorre quando mais de um processo requer um determinado recurso ao mesmo tempo.

O deadlock cria uma situação em que um ou mais processos nunca correrão para conclusão sem recuperação.

[...]

Situações semelhantes ocorrem periodicamente num conjunto de processos que estão a compartilhar recursos. Memória, os drives de uma impressora, um drive de disquetes são todos exemplos de recursos. Um processo pode bloquear quando é pedido qualquer um desses recursos e os mesmos estão ocupados, assim qualquer um pode contribuir para entrar na situação Deadlock.

[...]

Segundo Tanenbaum, deadlock pode ser formalmente definido como: “Um conjunto de processos estará em situação de deadlock se todo processo pertencente ao conjunto estiver esperando por um evento que somente um outro processo desse mesmo conjunto poderá fazer acontecer”.

Para um melhor entendimento podemos afirmar que deadlock é um termo empregado para traduzir um problema que ocorre quando um grupo ou conjunto de processos competem entre si. O aparecimento do mesmo depende das características de dois ou mais programas diferentes e dos respectivos processos a executar pelos diferentes programas ao mesmo tempo. Esses programas podem ser executados de forma repetitiva usando diferentes processos sem que ocorra a situação de deadlock, porém, basta um único processo padrão complicado para se entrar em deadlock.

[...]

Podemos citar como exemplo de situação de deadlock, não relacionado à computação, mas que facilita o entendimento do que seja uma situação de deadlock, dois carros seguindo em direção oposta numa pista que permite apenas a passagem de um veículo. Nesse caso os dois ficam impedidos de continuar seu percurso.

Um deadlock, em computação, ocorre normalmente com recursos como dispositivos, arquivos, memória, entre outros.


82

Existem algumas condições para que possa ter uma ocorrência de deadlock. São elas:

• Condição de exclusão mutua - em um determinado instante, cada recurso esta em uma de duas situações: ou associado a um processo ou disponível.

• Condição de posse e espera - processos que, em um determinado instante, retêm recursos concedidos anteriormente podem requisitar novos recursos.

• Condição de não preempção - recursos concedidos previamente a um processo não podem ser forçosamente tomados desse processo – eles devem ser explicitamente libertados pelo processo que os retêm.

• Condição de espera circular - deve existir um encadeamento circular de dois ou mais processos; cada um deles encontra-se á espera de um recurso que está sendo utilizada pelo membro seguinte dessa cadeia.

Todas estas condições devem estar presentes para que ocorra um deadlock. Se alguma delas falhar, então não ocorrerá um deadlock.

[...]

As situações de deadlock podem ser tratadas ou não em um sistema, os desenvolvedores devem avaliar o custo/benefício que essas implementações podem trazer. Normalmente, as estratégias usadas para detectar e tratar as situações de deadlocks, geram grande sobrecarga, podendo até causar um dano maior que a própria ocorrência do deadlock, sendo, às vezes, melhor ignorar a situação.

Existem três estratégias para tratamento de deadlocks: Detecção e Recuperação, Evitar Deadlock e Prevenção.

[...]

Para detecção do deadlock, deve-se implementar no sistema uma estrutura de dados que armazene as informações sobre os processos e os recursos alocados a eles e essas reflitam a situação de cada processo/recurso no sistema. Porém, é importante ressaltar que o simples procedimento de atualização dessas estruturas gera sobrecarga no sistema, pois toda vez que o processo aloca, libera ou requisita um recurso, elas precisam ser atualizadas.

[...]

O deadlock pode ser evitado, mas só quando certas informações estiverem disponíveis.

O Sistema Operacional, que adota esta estratégia, procura evitar a ocorrência de deadlocks por meio de alocação cuidadosa de recursos. O sistema deve ser capaz de saber e decidir se liberar um recurso é seguro ou não.

[...]


83

Sabendo que são quatro as condições para que possa ocorrer uma situação de deadlock simultaneamente, a prevenção procura eliminar pelo menos uma delas.

[...]

Deadlock é um problema potencial em qualquer sistema operacional. Um estado de deadlock ocorre quando dois ou mais processos estão esperando indefinidamente por um evento que só pode ocorrer por um dos processos em espera.

[...]

FONTE: Webartigos.com - Deadlock. Disponível em: <http://www.webartigos.com/articles/3416/1/deadlock/pagina1.html>. Acesso em: 18 fev. 2013.

Para saber mais sobre Deadlock, leia o capítulo 8 do livro Sistemas Operacionais: conceitos e alicações, de Silberschatz, Galvin e Gagne, 2004.

NOTA

84

RESUMO DO TÓPICO 2Caro(a) acadêmico(a)! Neste tópico, você estudou os seguintes assuntos:

• O escalonamento decide qual processo irá ganhar a CPU conforme os critérios estabelecidos.

• Um escalonador deve ser justo, garantindo que todos os processos tenham tratamento igual conforme sua importância.

• O escalonador pode ser preemptivo e não preemptivo.

• Exemplos de escalonamentos não preemptivos: FIFO, SJF e cooperativo.

• São escalonamentos preemptivos: circular, por prioridades, circular com prioridades, múltiplas filas e múltiplas filas com realimentação.

• O escalonamento em tempo real é utilizado em processos críticos.

• Sistemas distribuídos e de rede, programam as mesmas técnicas de escalonamento local, com a possibilidade de executar o processo remotamente.

• O deadlock é um problema de espera por recursos que jamais poderão ser liberados.

85

AUTOATIVIDADE

Caro acadêmico(a)! Resolva as questões a seguir para aprofundar seus conhecimentos e reforçar seu aprendizado sobre o gerenciamento do processador.

1 O que é escalonamento?

2 Quais são os critérios de escalonamento?

3 O que significa justiça no processo de escalonamento?

4 O que diferencia escalonamento preemptivo de não preemptivo?

5 Explique dois tipos de escalonamento preemptivo.

6 Explique dois tipos de escalonamento não preemptivo.

7 Faça uma pesquisa na internet sobre deadlock e apresente um relatório com suas conclusões.

87

TÓPICO 3

GERENCIAMENTO DE DISPOSITIVOS

UNIDADE 2

1 INTRODUÇÃOO controle de todos os periféricos da máquina é função do sistema

operacional, função esta que se torna a mais importante, pois dela depende todo o funcionamento da máquina, pois os próprios processos precisam alocar recursos, como gravar um dado no disco, ler uma informação do teclado etc.

Como existem diversos tipos distintos de dispositivos, o sistema operacional

implementa o que chamamos de camada de subsistema de Entrada/Saída, que tem a função de isolar os dispositivos da aplicação. Um usuário não enxerga o HD fisicamente, mas sim uma estrutura lógica com espaços que usa para ler e gravar dados.

Neste tópico vamos abordar a forma com que o sistema operacional gerencia o hardware e compreender como os processos alocam e desalocam recursos.

2 O SUBSISTEMA DE E/S – FUNCIONAMENTODevido à grande diversidade de dispositivos, é criada a divisão do processo

de entrada e saída em duas partes (MACHADO; MAIA, 2000):

• Hardware: que envolve o próprio dispositivo e o controlador do dispositivo (que possui instruções de acesso e controle ao dispositivo).

• Software: abrange o device driver que é o software compilado para conversar com o controlador do dispositivo, os subsistemas de E/S que oferecem a interface entre o sistema operacional e o device driver e por fim as operações de entrada e saída, que são comandos de alto nível utilizados pelas aplicações.

88


Por exemplo, uma linguagem de alto nível implementa comandos que possibilitam a leitura e gravação de arquivos, como read e write, por exemplo. Estes comandos quando acionados, realizam no sistema operacional o que chamamos de system calls, que acionam junto ao device driver, as rotinas necessárias ao acionamento do dispositivo. Por fim o device driver, aciona o controlador do dispositivo que realiza a função.

Esse mecanismo é conhecido como independência de dispositivo, ou seja, para que o dispositivo rode em outro sistema operacional basta reescrever o device driver, já que as demais chamadas continuam idênticas. A figura a seguir mostra essas camadas.

FIGURA 42 – GERÊNCIA DE DISPOSITIVO


Com a independência de dispositivos e as múltiplas camadas para acesso a E/S, é possível ter interfaces entre as aplicações e os dispositivos extremamente simples, o que além de facilitar a programação, agrega também a segurança, pois o controle de toda e qualquer E/S fica a cargo do sistema operacional.

NOTA

TÓPICO 3 | GERENCIAMENTO DE DISPOSITIVOS

89

3 DEVICE DRIVER (DRIVER)

Quando um fabricante desenvolve algum dispositivo, juntamente com ele é desenvolvido os device drivers que fazem a comunicação direta com o controlador do hardware.

Sua função é receber comandos gerais de acesso ao dispositivo e traduzi-los para os comandos específicos do controlador que por sua vez atua diretamente sobre o hardware.

Com um driver é altamente ligado ao hardware, são escritos em linguagem de máquina e um para cada sistema operacional. A figura a seguir mostra essa relação.

FIGURA 43 – FUNCIONAMENTO DO DEVICE DRIVER

FONTE: Os autores

Sempre que instalamos algum dispositivo na máquina devemos, na maioria das vezes, instalar os drives que acompanham o hardware. Desta forma estamos acoplando ao sistema operacional funcionalidades para o acionamento do dispositivo. Isso pode ser observado com o próprio Windows, que geralmente instala novos dispositivos genéricos, e posteriormente ao executarmos os programas instaladores, podemos observar as mudanças efetuadas no sistema. A figura a seguir mostra a tela de configuração de driver do Windows (no exemplo um drive para vídeo NVidia).

NOTA

90


FIGURA 44 – TELA DE ATUALIZAÇÃO DE DRIVER DO WINDOWS

FONTE: Sistema Operacional Windows XP Professional

4 CONTROLADORESOs controladores são os responsáveis pelo acionamento do hardware e,

na maioria das vezes, possui memória interna (buffer), registradores e instruções próprias, pois processam as requisições dos device drivers.

O buffer de um dispositivo é muito importante, principalmente se esse dispositivo for um HD ou um CD/DVD. Pois como são dispositivos relativamente mais lentos que a memória principal e os barramentos, sofrem com esse gargalo. Assim, leituras antecipadas para as áreas de buffer dos dispositivos podem dar um ganho considerável de performance à máquina.

NOTA

Para entender a importância de um buffer, realize uma pesquisa no Google.com sobre o termo Buffer Underrun que é um erro de esvaziamento de buffer da gravadora de CD/DVD. Pesquise também como alguns programas de gravação de CD/DVD atuam para minimizar a ocorrência desse erro. Isso vai ajudar seu entendimento sobre o uso de buffer nos dispositivos.

DICAS


91

Os dispositivos são ligados diretamente aos controladores, que por sua vez se conectam aos barramentos. A figura a seguir representa essa conexão, observe que a porta de entrada para os dispositivos sempre são os controladores.

FIGURA 45 – COMUNICAÇÃO DA CPU E MEMÓRIA COM CONTROLADORES

FONTE: Os autores

Com a evolução do hardware, e do próprio sistema operacional, hoje a maioria dos dispositivos implementa o mecanismo de DMA (Direct Memory Access – Acesso Direto à memória), onde o controlador transfere os dados diretamente para a memória, ou seja, o device driver grava os dados no buffer do controlador, deixando a CPU livre para a realização de outras atividades.O DMA permite que certos dispositivos de hardware num computador acessem a memória do sistema para leitura e escrita independentemente da CPU.

NOTA

5 LÓGICO E FÍSICOA importância da separação entre níveis lógicos e físicos permite a boa

integração do sistema operacional com o dispositivo em. Os controladores atuam sobre os diferentes dispositivos cada um com sua particularidade, um DVD, por exemplo, possui setores de tamanho iguais, e a organização de suas trilhas é espiral, já um disco rígido (HD), possui setores de 512 bytes, porém suas trilhas são concêntricas.

92


Uma placa de rede precisa identificar pacotes de dados e separar aqueles que são endereçados à máquina em questão. Um modem precisa diferenciar informação de voz de informação de dados.

Por outro lado, o teclado precisa identificar qual tecla foi pressionada, ao passo que o mouse precisa gerar sinais que identificam para qual direção está sendo movido, bem como se foi ou não pressionado algum botão de função.

Todas essas funções são implementadas pelo controlador, o sistema operacional desenvolve estruturas lógicas (software) que atuam em conjunto com as partes físicas para obter as funcionalidades necessárias (device driver).

É desta forma que os sistemas operacionais se tornaram mais genéricos permitindo o acoplamento de novos dispositivos sem grandes impactos para o sistema.

Um grande exemplo de relação forte entre a parte física e o sistema lógico são os sistemas de arquivos (visto a seguir na leitura complementar).


Sistema de arquivos

Todos nós sabemos que dados – sejam eles partes de programas ou dados propriamente dito, como um texto ou uma planilha – devem ser armazenados em um sistema de memória de massa, já que a memória (RAM) do micro é apagada quando desligamos o computador. Memória de massa é o nome genérico para qualquer dispositivo capaz de armazenar dados para uso posterior, onde incluímos disquetes, discos rígidos, CD-ROMs, ZIP drives e toda a parafernália congênere.

Dados são armazenados em forma de arquivos e a maneira com que os arquivos são armazenados e manipulados dentro de um disco (ou melhor dizendo, dentro de um sistema de memória de massa) varia de acordo com o sistema operacional.

Na maioria das vezes, um disco é dividido em pequenas porções chamadas setores. Dentro de cada setor cabem 512 bytes de informação. Multiplicando-se o número total de setores de um disco por 512 bytes, teremos a sua capacidade de armazenamento.

No caso de um disco rígido, ele possui na verdade vários discos dentro dele. Cada face de cada disco é dividida em círculos concêntricos chamados cilindros ou trilhas. Em cada trilha temos um determinado número de setores. É claro que toda esta divisão é invisível, pois é feita magneticamente. Para sabermos qual o número total de setores de um disco rígido, basta multiplicarmos sua geometria, ou seja, o seu número de cilindros, lados (parâmetro também chamado de “cabeças”) e setores por trilha. Um disco rígido que possua a geometria 2448 cilindros, 16 cabeças e 63 setores por trilha, terá 2448 x 16 x 63 = 2.467.584 setores.


93

Multiplicando-se o número total de setores por 512 bytes, teremos sua capacidade total, no caso 1.263.403.008 bytes.

[...]

O sistema de arquivos utilizado pelo MS-DOS chama-se FAT-16. Neste sistema existe uma Tabela de Alocação de Arquivos (File Allocation Table, FAT) que na verdade é um mapa de utilização do disco. A FAT mapeia a utilização do espaço do disco, ou seja, graças a ela o sistema operacional é capaz de saber onde exatamente no disco um determinado arquivo está armazenado.

Existem várias posições na FAT, sendo que cada posição aponta a uma área do disco. Como cada posição na FAT-16 utiliza uma variável de 16 bits, podemos ter, no máximo, 216 = 65.536 posições na FAT. Como em cada setor cabem apenas 512 bytes, concluímos que, teoricamente, poderíamos ter discos somente de até 65.536 x 512 bytes = 33.554.432 bytes ou 32 MB.

Por este motivo, o sistema FAT-16 não trabalha com setores, mas sim com unidades de alocação chamadas clusters, que são conjuntos de setores. Em vez de cada posição da FAT apontar a um setor, cada posição aponta para um cluster, que é um conjunto de setores que poderá representar 1, 2, 4 ou mais setores do disco.

Tamanho do Cluster Capacidade Máxima de Armazenamento 2 KB 128 MB4 KB 256 MB8 KB 512 MB16 KB 1 GB32 KB 2 GB

[...]

O tamanho do cluster é definido automaticamente pelo sistema operacional quando o disco é formatado, seguindo a tabela. Um disco rígido de 630 MB utilizará clusters de 16 KB, enquanto um de 1, 7 GB utilizará clusters de 32 KB.

[...]

Isto significa que um arquivo de 100 KB em um disco rígido que utilize clusters de 8 KB obrigatoriamente ocupará 13 clusters, ou 104 KB, pois este é o valor mais próximo de 100 KB que conseguimos chegar utilizando clusters de 8 KB. Neste caso, 4 KB serão desperdiçados.

Quanto maior o tamanho do cluster, maior o desperdício. Se o mesmo arquivo de 100 KB for armazenado em um disco rígido que utilize clusters de 16 KB, ele obrigatoriamente utilizará 7 clusters, ou 112 KB. E, para o caso de um disco rígido com clusters de 32 KB, este mesmo arquivo ocupará 4 clusters, ou 128 KB.

94


O desperdício em disco é um dos maiores problemas do sistema FAT, característica que chamamos de slack space. Quando maior o tamanho do cluster, mais espaço em disco é desperdiçado.

[...]

Vimos que o grande vilão do sistema FAT-16 é o desperdício em disco. Há, contudo, outro grande problema: o sistema FAT-16 não reconhece diretamente discos maiores que 2 GB. Para que discos com mais de 2 GB possam ser utilizados, devemos particioná-los, ou seja, dividi-los logicamente em outros menores que 2 GB. No caso de um disco rígido de 2,5 GB devemos obrigatoriamente dividi-lo em dois, podendo esta divisão ser, por exemplo, uma unidade de 2 GB e outra de cerca de 500 MB.

[...]

Com o sistema FAT-32 o tamanho dos clusters é sensivelmente menor, o que faz com que haja bem menos desperdício. Este sistema permite, também, que discos rígidos de até 2 terabytes (1 TB = 2^40 bytes) sejam reconhecidos e acessados diretamente, sem a necessidade de particionamento.

Tamanho do Cluster Capacidade Máxima de Armazenamento512 bytes 256 MB 4 KB 8 GB 8 KB 16 GB 16 KB 32 GB 32 KB 2 TB

[...]

A verdadeira solução para o problema de desperdício em disco é a utilização de um outro sistema de arquivos que não o FAT. O sistema operacional OS/2, por exemplo, possui um excelente sistema de arquivos denominado HPFS (High Performance File System). O sistema operacional Windows NT também possui o seu próprio (e também excelente) sistema de arquivos, denominado NTFS (New Technology File System).

No caso do OS/2 e do Windows NT, na hora de sua instalação o usuário pode optar em utilizar o sistema FAT-16 ou então o HPFS/NTFS. A vantagem destes sistemas de arquivo é que não há desperdício em disco, pois não há clusters: a menor unidade de alocação é o próprio setor de 512 bytes.


95

A desvantagem óbvia destes sistemas de arquivos: só podem ser utilizados em conjunto com os seus sistemas operacionais. Ou seja, não há como instalar o HPFS no Windows 95... Outra desvantagem: assim como o sistema FAT-32, não são “enxergados” por outros sistemas operacionais diretamente (há, contudo, alguns “macetes” que permitem com que esta limitação seja transposta).

[...]

FONTE: Clube do Hardware. Disponível em: <http://www.clubedohardware.com.br/artigos/313>. Acesso em: 27 fev. 2013.

96

RESUMO DO TÓPICO 3

Caro(a) acadêmico(a)! Neste tópico, você estudou os seguintes assuntos:

• A gerência de dispositivos é uma função extremamente crítica desempenhada pelo sistema operacional.

• Os subsistemas de E/S dividem-se em hardware e software.

• A independência de dispositivos torna mais flexível a compatibilidade do hardware com vários tipos de sistemas operacionais.

• O device driver é um programa que conversa diretamente com a controladora do dispositivo, e na maioria das vezes é desenvolvida pelo fabricante do hardware.

• Os controladores garantem o acionamento do dispositivo.

• Através do uso da técnica do DMA, é possível um dispositivo gravar dados diretamente na memória, deixando assim a CPU livre para outras atividades.

• Os sistemas de arquivos são as formas com que os sistemas operacionais preparam os discos para receberem dados.

97

Caro(a) acadêmico(a)! Resolva as questões a seguir para aprofundar seus conhecimentos e reforçar seu aprendizado sobre o gerenciamento do processador.

1 Qual é a vantagem de se ter independência de dispositivo?

2 Por que o device driver é fortemente acoplado ao hardware?

3 O que aconteceria se não existisse o device driver? Como deveriam funcionar os sistemas operacionais para utilizar um dispositivo?

4 Explique por que o buffer de um dispositivo é importante.

5 Qual é a importância da abstração dos comandos de acesso de um dispositivo para o usuário?

AUTOATIVIDADE

99

UNIDADE 3

SISTEMAS DISTRIBUÍDOS


PLANO DE ESTUDOS

Após o estudo desta unidade você estará apto a:

• conhecer as principais características e conceitos de sistemas distribuídos;

• compreender a arquitetura dos Sistemas Distribuídos e algumas das clas-sificações existentes;

• entender o funcionamento da comunicação cliente/servidor e chamadas remotas de procedimentos.

Esta unidade está dividida em três tópicos, sendo que ao final de cada um deles, você encontrará atividades que auxiliarão na apropriação dos conhecimentos.

TÓPICO 1 – SISTEMAS DISTRIBUÍDOS

TÓPICO 2 – ARQUITETURA DE SISTEMAS DISTRIBUÍDOS

TÓPICO 3 – COMUNICAÇÃO EM UM AMBIENTE DISTRIBUÍDO

101

TÓPICO 1

SISTEMAS DISTRIBUÍDOS

UNIDADE 3

1 INTRODUÇÃOAntes de começarmos os estudos, precisamos entender o que este termo

significa e algumas das consequências da utilização dos mesmos. Devido a isto, este tópico tem o objetivo de apresentar os principais conceitos relacionados aos sistemas distribuídos, suas principais características e também as principais consequências da sua utilização.

Segundo Gross (2008, p. 3), “o surgimento dos sistemas distribuídos ocorreu quase que de maneira involuntária, pois redes de computadores foram criadas e passaram a ser cada vez mais utilizadas, cujo melhor exemplo a ser dado neste sentido é a internet. Os sistemas de telefonia cresceram enormemente em tamanho físico e em recursos e tecnologia disponibilizadas. As empresas e instituições das mais diversas naturezas interligaram-se através de redes, impulsionando o desenvolvimento de novas tecnologias e serviços para atender às necessidades pessoais e empresariais”.

2 SISTEMAS DISTRIBUÍDOSSistemas distribuídos são aqueles sistemas que executam operações em diversos

equipamentos que não possuem memória compartilhada e que são percebidos pelos seus usuários como se estes estivessem executando em apenas um processador.

De modo geral, são descritos como sistemas que usam diversos computadores os quais não compartilham processador ou memória. Tais sistemas usam um conjunto de computadores independentes e algum meio que possibilite a troca de mensagens entre eles.

UNIDADE 3 | SISTEMAS DISTRIBUÍDOS

102

Segundo Gross (2008, p. 4), “sistemas distribuídos são uma categoria de sistemas ditos fracamente acoplados, os quais podem utilizar uma grande quantidade de computadores que estejam de alguma forma interligados, mas não necessariamente dependentes”.

Um sistema distribuído, portanto, consiste de um conjunto de equipamentos independentes, que estejam ligados por algum meio de comunicação e que executem softwares de sistema distribuído. Um software de sistema distribuído tem por finalidade permitir a coordenação de atividades e compartilhamento de recursos. O sistema distribuído dá ao usuário a visão de ele está utilizando um sistema único (FRIEDRICH, 2002).

De acordo com Gunther (2000, p. 8), “um sistema distribuído é composto de uma coleção de processos que estão tipicamente separados fisicamente”. Processos coordenam uns com os outros (através da troca de mensagens) para concluir uma tarefa computacional.

Um sistema distribuído consiste de um conjunto de equipamentos independentes, que estejam ligados por algum meio de comunicação e que executem softwares de sistema distribuído.

IMPORTANTE

Em sistemas distribuídos o processamento é organizado utilizando como base múltiplos elementos de processamento. “Um elemento de processamento é um dispositivo que tenha capacidade de processamento, os quais podem estar organizados de maneira funcional ou geográfica. Elementos de processamento distribuído têm a característica de cooperação em relação ao trabalho a realizar com o objetivo de atender aos requisitos de usuários”. (GROSS, 2008, p. 4).

“Os sistemas distribuídos foram criados para distribuir as tarefas e aumentar o poder computacional através do uso de vários processadores como também promover o compartilhamento de recursos. Cada processador possui sua própria memória e a comunicação entre os processadores é feita através de linhas de comunicação”. (RIBEIRO, 2005, p. 32-33).

O meio normalmente utilizado para a comunicação entre elementos de processamento são as redes de computadores, desde redes locais até redes de longa distância. Existem aplicações que envolvem a colaboração de equipamentos fisicamente separados, ou seja, por haverem muitas aplicações cuja natureza é de distribuição representa um razão para a construção de sistemas distribuídos (FRIEDRICH, 2002).

TÓPICO 1 | SISTEMAS DISTRIBUÍDOS

103

Estes sistemas, de acordo com Ribeiro (2005, p. 33), “objetivam melhorar a comunicação entre os computadores, propiciando a integração destes num sentido amplo, que pode envolver a facilidade de mudanças futuras, rapidez nas trocas de informações e confiabilidade na execução dos processos”. Eles permitem que uma aplicação seja dividida em diferentes partes que podem ser processadas em sistemas independentes que se comunicam através das linhas de comunicação. Ele cria a ilusão de que a rede de computadores seja vista como um único sistema de tempo compartilhado, em vez de um conjunto de máquinas distintas.

O uso de sistemas distribuídos potencializa as possibilidades de uso dos recursos computacionais.

IMPORTANTE

Um sistema distribuído, segundo Gross (2008, p. 4), “permite melhora do desempenho e redução do tempo de resposta, pois permite usar múltiplos processadores de um sistema de computação distribuída, os quais podem ser usados de modo a permitir tempos de resposta menores, obtendo ainda maior desempenho que os sistemas centralizados convencionais que utilizam apenas um processador”.

Os sistemas distribuídos proporcionam também melhor relação entre preço e desempenho, podendo ter poder de processamento muito superior aos dos mainframes. Por esta razão, uma das melhores soluções em termos de custo passou a ser a utilização de diversos processadores com preços relativamente baixos e que trabalhem em um único sistema (FRIEDRICH, 2002).

Mainframe, de acordo com Dantas (2005, p. 269), “é um termo comercial empregado no passado para descrever um computador com grande capacidade computacional”. Usualmente os computadores eram comercialmente classificados como de pequeno, médio e grande porte (mainframe) dependendo de sua capacidade de processamento.

De acordo com a Wikipédia, um mainframe é um computador de grande porte, dedicado normalmente ao processamento de um volume grande de informações. São capazes de oferecer serviços de processamento a milhares de usuários através de milhares de terminais conectados diretamente ou através de uma rede. Para conhecer um pouco mais sobre mainframes, acesse: <http://pt.wikipedia.org/wiki/Mainframe>. Acesso em: 12 out. 2012.

NOTA


104

Dependendo da aplicação, de acordo com Ribeiro (2005, p. 33), “os sistemas distribuídos podem oferecer uma economia grande, pelo baixo custo dos microprocessadores em relação ao oferecido pelos mainframes”. As aplicações podem ser eminentemente distribuídas e os recursos compartilhados permitindo que vários usuários tenham acesso a periféricos caros.

Sob o aspecto de arquitetura de máquinas para execução de aplicativos, de acordo com Dantas (2005, p. 31), “os sistemas distribuídos devem ser vistos como configurações com grande poder de escala pela agregação dos computadores existentes nas redes convencionais”.

Embora a utilização de ambientes distribuídos seja interessante sob o aspecto de utilização de recursos abundantes e na maioria das vezes ociosos nas redes, alguns cuidados devem ser verificados nas fases de projeto e implementação de aplicativos candidatos ao processamento nestas configurações. “Aspectos tais como a segurança, o retardo de comunicação, a confiabilidade, a disponibilidade e a compatibilidade de versões de pacotes de software são alguns pontos a serem considerados com cautela”. (DANTAS, 2005, p. 31).

3 CARACTERÍSTICAS FUNDAMENTAIS DOS SISTEMAS DISTRIBUÍDOS

Segundo Gross (2008, p. 5), embora os sistemas distribuídos sejam encontrados em toda a parte, seu projeto é muito simples e ainda há muito espaço para o desenvolvimento de serviços e de aplicativos mais ambiciosos. As características que justificam utilizar sistemas distribuídos são:

• Compartilhamento de recursos.• Crescimento incremental.• Concorrência.• Escalabilidade.• Tolerância a falhas.• Transparência.• Heterogeneidade.• Abertura.• Segurança.

3.1 COMPARTILHAMENTO DE RECURSOS

Os usuários estão tão acostumados às vantagens do compartilhamento de recursos que podem ignorar seu significado facilmente. O compartilhamento de recursos se refere ao conjunto de elementos que podem ser compartilhados num sistema computacional distribuído. Estes recursos incluem elementos de hardware como processador, discos, impressoras, entre outros e também recursos de software como bancos de dados, compiladores, arquivos, entre outros (FRIEDRICH, 2002).


105

A grande vantagem do compartilhamento de recursos é a redução de custos, sendo que em geral, em trabalhos cooperativos o compartilhamento de recursos é um importante requisito. Os recursos fisicamente localizados em um elemento de processamento num sistema distribuído podem ser acessados de outros locais físicos através do uso de recursos de comunicação como redes (FRIEDRICH, 2002).

O compartilhamento de recursos permite aos usuários o acesso às informações e aos serviços necessários para melhoria de seu trabalho diário e de suas atividades sociais.

IMPORTANTE

Em geral, conforme Gross (2008, p. 6), estes recursos possuem algum tipo de gerenciamento que permite realizar um conjunto de configurações, como:

• Configurações de acesso aos recursos.• Meios de manipular e efetuar atualizações nos recursos.• Uma sistemática de mapeamento dos nomes e endereços dos recursos.• Um modo de sincronizar acessos concorrentes para assegurar que haja consistência.

3.2 CRESCIMENTO INCREMENTAL

No crescimento incremental é possível efetuar o incremento no poder computacional sem que haja necessidade de duplicação ou interrupção nos serviços existentes. Para os usuários de sistemas distribuídos o crescimento incremental é percebido apenas através de um conjunto de novos benefícios que ele tem disponível, sem que tenha que ter perdido em termos de interrupções nos serviços para que tais incrementos pudessem ser implementados (FRIEDRICH, 2002).

A inclusão de novos recursos pode ser realizada sem que esta seja perceptível pelo usuário.

IMPORTANTE


106

“O crescimento incremental pode ser realizado em nível de hardware, pela adição de novos equipamentos oferecendo maior espaço de armazenamento, maior poder de processamento, entre outros. E também pode ser realizado em nível de software através da disponibilização de novos softwares para os usuários”. (GROSS, 2008, p. 6).

A disponibilização aos usuários destes novos recursos, em geral, é realizada através de interfaces de software dos sistemas distribuídos que são utilizados pelos desenvolvedores que trabalham com estes ambientes. O crescimento incremental é uma característica que torna os sistemas distribuídos mais atrativos do ponto de vista dos usuários, pois há a percepção de que o sistema está sempre recebendo melhorias ao invés de tornar-se apenas cada vez menos performático, como pode ocorrer com sistemas convencionais (FRIEDRICH, 2002).

3.3 CONCORRÊNCIA

De acordo com Gross (2008, p. 7), “tanto os serviços como os aplicativos fornecem recursos que podem ser compartilhados pelos clientes em um sistema distribuído”. Portanto, existe a possibilidade de que vários clientes tentem acessar um recurso compartilhado ao mesmo tempo. Por exemplo, uma estrutura de dados que registre lances de um leilão pode ser acessada com muita frequência, quando o prazo final se aproximar.

A concorrência em sistemas distribuídos ocorre pelo fato de haverem diversas execuções podendo ser solicitadas por diferentes usuários num mesmo instante. “O fato de diversos usuários fazerem solicitações de recursos num mesmo instante obriga que os sistemas distribuídos tenham a capacidade de executar estas diversas requisições em paralelo”. (GROSS, 2008, p. 7).

O processamento paralelo é possibilitado pelo fato de num sistema distribuído haver um nível menor de dependência de recursos, possibilitado pelo compartilhamento de recursos e também pelo fato destes processos poderem ser executados em equipamentos em locais diferentes (FRIEDRICH, 2002).

Segundo Gross (2008, p. 7), “a execução concorrente de processamentos deve ser tal que cada processamento pareça estar executando isoladamente”.

IMPORTANTE


107

Num equipamento com apenas um processador é possível executar um número limitado de processos simultaneamente, mas se existirem diversos equipamentos compartilhando recursos de processador trabalhando de forma colaborativa, o poder de processamento é multiplicado. Há necessidade de se observar apenas que, se vários processos estiverem acessando o mesmo recurso de forma concorrente, estes processos deverão ser sincronizados para assegurar que não haja conflitos entre o conjunto de processos concorrentes (FRIEDRICH, 2002).

Segundo Coulouris, Dollimore e Kindberg (2007, p. 16), “em uma rede de computadores, a execução concorrente de programas é a norma”. Posso fazer meu trabalho em meu computador, enquanto você faz o seu em sua máquina, compartilhando recursos como páginas web ou arquivos, quando necessário. A capacidade do sistema de manipular recursos compartilhados pode ser ampliada pela adição de mais recursos (por exemplo, computadores) na rede.

3.4 ESCALABILIDADE

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 31), sistemas distribuídos funcionam de forma efetiva e eficaz em muitas escalas diferentes, variando desde uma pequena intranet até a internet. Um sistema é descrito como escalável se permanece eficiente quando há um aumento significativo no número de recursos e no número de usuários. A internet é um exemplo de um sistema distribuído no qual o número de computadores e serviços vêm aumentando substancialmente.

“A escalabilidade refere-se a quanto um sistema pode se adaptar em caso de grande demanda”. (BALTZAN; PHILLIPS, 2012, p. 125).

IMPORTANTE

Os sistemas distribuídos devem ser utilizados de forma eficiente em diferentes escalas, ou seja, devem poder executar de forma adequada ao usuário contendo, por exemplo, três estações de trabalho operando sobre um servidor de arquivos da mesma forma que executa em uma rede local contendo 50 estações de trabalho ou mesmo se estiverem sendo executados em diversas redes locais formando uma rede corporativa (FRIEDRICH, 2002).

Uma característica forte da escalabilidade é que, quando o sistema cresce, o sistema distribuído e os demais softwares utilizados devem permanecer os mesmos. Caso haja substituição este sistema não pode ser caracterizado como escalável. O processamento da requisição de um serviço a um recurso deve ser independente do tamanho da rede ou quantidade de estações de trabalho na qual este sistema está sendo utilizado (FRIEDRICH, 2002).


108

3.5 TOLERÂNCIA A FALHAS

“O paradigma de tolerância a falhas pode ser definido como a habilidade que um sistema tem de apresentar um comportamento muito bem definido na ocorrência de falhas ativas”. (DANTAS, 2005, p. 44).

NOTA

Uma característica importante para sistemas disponíveis, principalmente para uma grande quantidade de usuários, é que estes sejam robustos. A robustez de um sistema distribuído está relacionada em grande parte com a capacidade do sistema em possuir mecanismos que impeçam ou minimizem os impactos causados por falhas que podem ocorrer (GROSS, 2008).

Uma falha pode produzir resultados indesejados ou incorretos e também paradas na execução que podem inclusive deixar parte ou todo o sistema indisponível. Para que haja maior tolerância a falhas em sistemas distribuídos pode-se utilizar a replicação de hardware, por exemplo. Para que haja mecanismos de recuperação em software é necessário que o projeto empregue mecanismos para permitir que dados permanentes possam ser recuperados em caso de ocorrência de falhas (FRIEDRICH, 2002).

“A tolerância a falhas é um sistema de computador projetado para que, caso um componente falhe, outro componente ou procedimento de backup tome o seu lugar imediatamente, sem perda de serviço. A tolerância a falhas pode ser fornecida por meio de um software, embutida no hardware, ou uma combinação dos dois” (BALTZAN; PHILLIPS, 2012, p. 121).

IMPORTANTE

De acordo com Gross (2008, p. 9), “os sistemas distribuídos fornecem um alto grau de disponibilidade perante as falhas de hardware. A disponibilidade de um sistema é a medida da proporção de tempo em que ele está pronto para uso. Quando um dos componentes de um sistema distribuído falha, apenas o trabalho que estava usando o componente defeituoso é afetado”. Um usuário pode passar para outro computador, caso aquele em que estava usando falhe; um processo servidor pode ser iniciado em outro computador.


109

Segundo Dantas (2005, p. 44-45), “a primeira forma de tolerância a falhas, caracterizada pela segurança e operacionalidade garantida, é a que realiza o mascaramento, empregado para encobrir ou ocultar as falhas. Neste item o serviço apresentado pelo sistema não deverá ser modificado pela ocorrência de falhas, ou seja, o sistema como um todo não deverá apresentar defeito. Logo, o sistema deverá permanecer operacional e em um estado seguro para os usuários e para o meio ambiente. É a forma mais completa de tolerância a falhas, a mais desejada e, também, a de maior custo”. Alguns autores, ao definirem tolerância a falhas, apenas consideram esta forma.

Ainda de acordo com Dantas (2005, p. 45), “todas as demais formas modificam o serviço prestado pelo sistema na ocorrência de falhas”.

“A forma conhecida como não tolerância a falhas é considerada uma forma extrema de tolerância. É a abordagem que apresenta a solução mais trivial, com o custo mais reduzido e é a mais frágil. Por esta razão, é a mais indesejada. Na ocorrência de falhas o sistema provavelmente apresentará defeito e, o mais grave, nada poderá ser afirmado quanto ao estado em que o sistema se encontrará após esta ocorrência”. Podendo o mesmo ingressar em um estado não operacional, ou até mesmo em um estado inseguro (DANTAS, 2005, p. 45).

Como opção em relação às duas abordagens anteriores, conforme Dantas (2005, p. 45), encontram-se duas formas intermediárias de tolerância a falhas. São estas:

• Aquela que garante que o sistema irá permanecer em um estado seguro, mas nada diz sobre o seu estado operacional, e por isso é chamada de defeito seguro.

• A segunda forma é aquela que garante que o sistema irá permanecer operacional. Ainda que o mesmo ingresse, por causa da falha, em um estado inseguro. Esta abordagem é denominada de tolerância a falhas sem mascaramento.

Segundo Dantas (2005, p. 45), de uma forma geral, “a opção de defeito seguro é sempre preferível em relação à tolerância à falha sem mascaramento, uma vez que segurança na maioria das ocasiões é muito mais importante que permanecer operacional”.

“Sistemas operacionais de rede convencionais têm pouca capacidade para tratamento de tolerância a falhas. Se ocorrer de 5% dos equipamentos apresentarem problemas, entende-se que pelo menos 5% dos usuários não poderá continuar suas atividades”. (GROSS, 2008, p. 5).

A visão de sistemas distribuídos, de acordo com Gross (2008, p. 5), “mostra que nestes casos a maior parte dos usuários não será afetada pelas falhas que estão ocorrendo, podendo perceber apenas uma queda na capacidade de processamento do referido sistema”.


110

3.6 TRANSPARÊNCIA

A transparência é uma característica que permite ao usuário visualizar o sistema como sendo algo único e não como uma coleção de elementos que são independentes. A questão da transparência é muito importante para o usuário, pois permite a ele utilizar o sistema da mesma forma independente do acesso estar sendo local ou remoto. As operações realizadas pelo usuário são as mesmas para acessos locais ou remotos (FRIEDRICH, 2002).

A transparência é uma característica que torna um sistema distribuído acessível aos usuários sem ser necessário o entendimento da tecnologia que se está utilizando.

IMPORTANTE

Para o usuário, segundo Ribeiro (2005, p. 33), “deve existir uma única máquina, com um único sistema operacional, onde ele pode acessar o recurso, independentemente da máquina na qual está conectado”.

Além disso, “os usuários fazem acesso a determinados elementos e/ou serviços sem que haja necessidade de se conhecer a localização física dos mesmos. É importante sim, para os usuários que o recurso seja disponibilizado ou o serviço seja executado, mas não interessa que elementos de processamento ou onde esteja sendo executado exatamente”. (GROSS, 2008, p. 9).

Certamente que as redes de computadores têm papel fundamental neste assunto, pois permitem o acesso aos recursos e/ou serviços de forma que não seja relevante a localização física do mesmo. Os quatro principais tipos de transparências são (FRIEDRICH, 2002):

• Transparência de migração: é possível que os recursos migrem para diferentes locais físicos sem que os usuários sejam afetados ou percebam a mudança ocorrida.

• Transparência de replicação: os recursos do sistema distribuído podem ser duplicados sem que os usuários percebam qualquer alteração no comportamento do sistema.

• Transparência de concorrência: eventuais compartilhamentos de recursos que estejam sendo realizados não são percebidos pelos usuários.

• Transparência de paralelismo: os recursos de execução são paralelizados automaticamente, sem a necessidade de o usuário indicar que devam ocorrer desta maneira ou mesmo sem que o usuário saiba que esta técnica está sendo utilizada.


111

3.7 HETEROGENEIDADE

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 28), a internet permite que usuários acessem serviços e executem aplicativos por meio de um conjunto heterogêneo de computadores e redes. A heterogeneidade se aplica aos seguintes aspectos:

• redes;• hardware do computador;• sistemas operacionais;• linguagens de programação;• implementações de diferentes desenvolvedores.

FIGURA 46 – UMA PARTE TÍPICA DA INTERNET

FONTE: Adaptado de COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems: concepts and design. 3. ed. England: Addison Wesley, 2001, p. 3.

Embora a internet seja composta de muitos tipos de redes, conforme mostra a figura anterior, suas diferenças são mascaradas pelo fato de que todos os computadores ligados a elas utilizam protocolos internet para se comunicar. “Por exemplo, um computador que possui uma placa Ethernet tem uma implementação dos protocolos internet enquanto um computador em um tipo diferente de rede tem uma implementação dos protocolos internet para esta rede”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 28).


112

De acordo com a Wikipédia, Ethernet é uma tecnologia de interconexão para redes locais baseada no envio de pacotes. Ela define cabeamento e sinais elétricos para a camada física, e formato de pacotes e protocolos para a camada de controle de acesso ao meio do modelo OSI. Se você quiser aprender um pouco mais sobre essa tecnologia pode acessar: <http://pt.wikipedia.org/wiki/Ethernet>. Acesso em: 7 out. 2012.

NOTA

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 28), os tipos de dados, como os inteiros, podem ser representados de diversas maneiras em diferentes tipos de hardware; por exemplo, existem duas alternativas para a ordem em que os bytes de valores inteiros são armazenados: uma iniciando a partir do byte mais significativo e outra a partir do byte menos significativo. Essas diferenças na representação devem ser consideradas, caso mensagens devam ser trocadas entre programas sendo executados em diferentes hardwares.

“Embora os sistemas operacionais de todos os computadores na internet precisem incluir uma implementação dos protocolos internet, nem todos fornecem necessariamente a mesma interface de programação de aplicativos para esses protocolos. Por exemplo, as chamadas para troca de mensagens no UNIX são diferentes das chamadas no Windows”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 28).

Segundo Coulouris, Dollimore e Kindberg (2007, p. 28), “diferentes linguagens de programação usam diferentes representações para caracteres e estruturas de dados, como arrays e registros”. Essas diferenças devem ser consideradas, caso programas escritos em diferentes linguagens precisem se comunicar.

“Programas escritos por diferentes desenvolvedores não podem se comunicar, a menos que eles utilizem padrões comuns; por exemplo, para realizar a comunicação via rede e usar uma mesma representação de tipos de dados primitivos e estruturas de dados das mensagens. Para que isto aconteça, padrões precisam ser estabelecidos e adotados. Assim é o caso dos protocolos internet”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 28-29).

3.8 ABERTURA

Segundo Coulouris, Dollimore e Kindberg (2007, p. 29), “um sistema computacional é aberto quando ele pode ser estendido e reimplementado de várias maneiras”. O fato de um sistema distribuído ser ou não um sistema aberto é determinado principalmente pelo grau com que novos serviços podem ser adicionados e disponibilizados para uso por uma variedade de programas clientes.


113

A característica de sistema aberto é obtida a partir do momento em que a especificação e a documentação das principais interfaces de software dos componentes de um sistema estão disponíveis para os desenvolvedores de software. Em uma palavra, as principais interfaces são publicadas. Esse processo é similar ao realizado por organizações de padronização, porém, frequentemente, ignora os procedimentos oficiais, os quais normalmente são pesados e lentos”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 29).

Entretanto, a publicação de interfaces é apenas o ponto de partida para adicionar e estender serviços em um sistema distribuído. “O maior desafio para os projetistas é encarar a complexidade de sistemas distribuídos compostos por muitos componentes e elaborados por diferentes pessoas. Os sistemas projetados a partir de padrões públicos são chamados de sistemas distribuídos abertos, para reforçar o fato de que eles são extensíveis”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 29).

Os projetistas dos protocolos internet elaboraram uma série de documentos, chamados RFC (Request For Comments), sendo que cada um destes é identificado por um número.

No início dos anos 80, as especificações dos protocolos de comunicação internet foram publicadas nessa série, acompanhadas de especificações de aplicativos com eles executados, como a transferência de arquivos, e-mail e telnet.

Essa prática continua, e forma a base da documentação técnica da internet. Essa série inclui discussões, assim como as especificações dos protocolos. Dessa forma, com a publicação dos protocolos internet, permitiu-se a construção de uma variedade de sistemas e aplicativos para a Internet, incluindo a web.

Podem-se obter cópias dos RFCs no endereço: <www.ietf.org>.

IMPORTANTE

RFCs não são os únicos meios de publicação. O CORBA, por exemplo, é publicado por intermédio de uma série de documentos técnicos, incluindo uma especificação completa das interfaces de seus serviços. Caso lhe interesse, acesse o endereço: <www.omg.org>.

NOTA


114

3.9 SEGURANÇA

Muitos recursos de informação que se tornam disponíveis e são mantidos em sistemas distribuídos têm um alto valor intrínseco para seus usuários. Portanto, sua segurança é de considerável importância. A segurança de recursos de informação tem três componentes: confidencialidade (proteção contra exposição e acesso para pessoas não autorizadas), integridade (proteção contra danos ou alterações) e disponibilidade (proteção contra interferência com os meios de acesso aos recursos) (COULOURIS; DOLLIMORE; KINDBERG, 2007).

De acordo com Coulouris, Dollimore e Kindberg (2007), ainda que a internet permita que um programa em um computador se comunique com um programa em outro computador, independentemente de sua localização, existem riscos de segurança associados ao livre acesso a todos os recursos de uma intranet. Embora um firewall possa ser usado para formar uma barreira em torno de uma intranet, restringindo o tráfego que pode entrar ou sair, isso não garante o uso apropriado dos recursos pelos usuários de dentro da intranet, nem o uso apropriado de recursos na internet, que não são protegidos por firewalls.

Segundo a Cyclades Brasil (2001, p. 109), “um firewall não é necessariamente um equipamento ou software; ele é um conjunto formado por hardware, software e uma política de segurança (documentos que contêm diretrizes para tomada de decisão sobre segurança na empresa). A função do firewall é controlar o tráfego entre duas ou mais redes, com o objetivo de fornecer segurança a uma (ou algumas) das redes que normalmente tem informações e recursos que não devem estar disponíveis aos usuários da(s) outra(s) rede(s).”

IMPORTANTE

“Um firewall é um computador que fica entre uma rede interna e a internet. Ele permite o acesso de sites específicos de entrada aos dados internos, mas tenta detectar tentativas de acesso não autorizado e impedir que ocorram”. (BALTZAN; PHILLIPS, 2012, p. 172).

Ainda segundo Baltzan e Phillips (2012, p. 108, 113 e 333), “um firewall é um hardware e/ou software que protege uma rede privada por meio da análise das informações que entram e saem da rede.”

IMPORTANTE


115

DICAS

É sempre bom aprender algum assunto novo assistindo a um bom filme. E existem vários filmes que retratam problemas de segurança na internet ou em redes de computadores. E este é um dos mais cativantes: A Rede.

Ela não tem mais cartão de crédito, conta bancária, carteira de motorista e perdeu ainda o número da identidade. Foi tudo “deletado”. Ela simplesmente deixou de existir! Sandra Bullock, Jeremy Northam e Dennis Miller estrelam este suspense sobre uma especialista em computadores cuja vida é apagada por uma conspiração eletrônica.

Angela Bennett (Sandra Bullock) é uma analista de sistemas freelance que passa os dias procurando por vírus de computador,

e as noites ‘conversando’ com outros tímidos fanáticos pelo cyber-espaço na rede internet. Nessa rotina solitária ela se sente tranquila e feliz, mantida em sua redoma protetora... até que o mundo eletrônico que ela criou a faz mergulhar numa criminosa teia de corrupção e conspiração. Enquanto conserta alguns defeitos num programa de games, Angela acessa um quebra-cabeças com dados altamente secretos do governo. Rapidamente percebe que penetrou numa conspiração por computador, e que sinistros piratas da informática não se deterão enquanto ela não for eliminada. Angela descobre que todos os traços de sua existência foram apagados e que recebeu uma nova identidade nos arquivos da polícia e se tornara uma criminosa com a cabeça a prêmio. Agora ela vai ter que sair da frente do computador e escapar com vida no mundo real.A REDE. Direção de Irwin Winkler. EUA: Sony Pictures Entertainment, 1995, DVD (114 min), color.

Ambos os exemplos, segundo Coulouris, Dollimore e Kindberg (2007, p. 30) “trazem como desafio enviar informações sigilosas em uma ou mais mensagens, por uma rede, de maneira segura. Mas a segurança não é apenas uma questão de ocultar o conteúdo de mensagens – ela também envolve saber com certeza a identidade do usuário, ou outro agente, em nome de quem uma mensagem foi enviada”. No primeiro exemplo, o servidor precisa saber se o usuário é realmente um médico, e no segundo exemplo o usuário precisa ter certeza da identidade da loja ou do banco com o qual está tratando. O segundo desafio aqui é identificar corretamente um usuário ou outro agente remoto. Esses dois desafios podem ser resolvidos com o uso de técnicas de criptografia desenvolvidas para este propósito. Elas são amplamente utilizadas na internet.


116

DICAS

De acordo com Dantas (2005, p. 54), “o atributo segurança é considerado sob dois aspectos, contra catástrofes e a segurança convencional. No primeiro caso o atributo é expresso como a probabilidade de um sistema não apresentar defeito que acarrete consequências catastróficas contra os usuários (ou contra o meio ambiente) em um intervalo de tempo”. No caso da segurança convencional, esta probabilidade é obtida através da combinação dos atributos: disponibilidade para usuários autorizados, pela confidencialidade e pela integridade. Então, a segurança pode ser definida como a probabilidade de que não ocorra acesso ou manipulação indevidos no estado do sistema, em um intervalo de tempo.

Prepare a pipoca! Este é mais um filme que ilustra al-guns pontos importantes sobre segurança. A Rede 2.0.

De um dos produtores do mega sucesso A Rede, esta sequência de ação é estrelada por Nikki DeLoach (da série de TV North Shore) que interpreta Hope Cassidy, uma linda especialista em computa-dores que viaja para Istambul em busca do trabalho perfeito, mas logo fica presa a uma enrascada de alta tecnologia. A perseguição interminável começa quando Hope tem que usar sua inteligência e beleza para recuperar seu nome e revelar o mistério. Graças à ajuda de um misterioso motorista de táxi e de uma sexy aeromoça, ela é capaz de descobrir a chocante

verdade sobre o que está acontecendo com ela. Será que ela poderá recuperar seu passado antes que os bandidos apaguem seu futuro? Ou será que ela será capturada na rede?A REDE 2.0. Direção de Mike Bigelow. EUA: Sony Pictures Entertainment, 2006, DVD (92 min.), color.

117

Caro acadêmico, neste primeiro tópico, você estudou os seguintes conceitos:

• Os sistemas distribuídos são aqueles que executam operações em diversos equipamentos que não possuem memória compartilhada e são percebidos por seus usuários como se estivessem sendo executados em apenas um processador.

• Um sistema distribuído permite melhorar o desempenho e reduzir o tempo de resposta na execução das atividades.

• O compartilhamento de recursos se refere ao conjunto de elementos que podem ser compartilhados num sistema computacional distribuído.

• A heterogeneidade permite acesso a serviços e execução de aplicativos por meio de uma grande variedade e diferença de computadores e redes.

• A transparência é uma característica que permite ao usuário visualizar um conjunto de recursos como sendo um sistema único.

• Os sistemas distribuídos abertos podem ser construídos a partir de hardware e software heterogêneos, tendo suas principais interfaces publicadas para garantir acesso aos seus recursos.

RESUMO DO TÓPICO 1

118

1 Os sistemas distribuídos surgiram sustentados por quais tecnologias?

2 Qual é o nível de acoplamento de um sistema distribuído?

3 Cite dois benefícios diretos proporcionados pela utilização de sistemas distribuídos.

4 Qual é a diferença entre crescimento incremental e escalabilidade?

5 A sincronização é elemento importante em quais das características de sistemas distribuídos?

AUTOATIVIDADE

119

TÓPICO 2

ARQUITETURA DE SISTEMAS DISTRIBUÍDOS

UNIDADE 3

1 INTRODUÇÃOSistemas usados no mundo real devem ser especificados, modelados

e projetados para que funcionem corretamente frente a várias circunstâncias possíveis, e inúmeras dificuldades e ameaças, compartilhando importantes propriedades subjacentes, dando origem a problemas de projeto comuns. Para tanto, “as propriedades e problemas comuns de projeto de sistemas distribuídos devem ser modelados de forma descritiva, sendo que cada modelo destina-se a fornecer uma descrição simples, abstrata e consistente de aspectos relevantes de projetos de sistemas distribuídos”. (GROSS, 2008, p. 41).

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 40), “a arquitetura de um sistema pode ser definida como sendo a sua estrutura de componentes especificados separadamente, com objetivo de garantir que atenda as atuais demandas, prevendo as futuras, tornando o sistema confiável, gerenciável, adaptável e rentável”.

O livro de Coulouris, Dollimore e Kindberg é tido como um livro de cabeceira para acadêmicos dos cursos de Análise e Desenvolvimento de Sistemas, Ciências da Computação e Sistemas de Informação. Caso você queira lê-lo e aprender ainda mais sobre sistemas distribuídos, procure por sua referência completa: COULOURIS, G; DOLLIMORE, J; KINDBERG, T. Sistemas Distribuídos: conceitos e projeto. 4. ed. Porto Alegre: Bookman, 2007. ISBN 978-85-60031-49-8.

NOTA

120

UNIDADE 3 |SISTEMAS DISTRIBUÍDOS

Modelos de arquitetura definem como ocorre a iteração dos componentes dos sistemas e a forma como são mapeados em uma rede de computadores, ou seja, simplifica e abstrai funções dos componentes individuais de um sistema distribuído, e considera o posicionamento dos componentes e seus inter-relacionamentos. Tanto a estrutura em camadas de software quanto os principais modelos de arquitetura que determinam localizações e iterações dos componentes precisam ser conhecidas e documentadas, desde o modelo cliente-servidor tradicional e suas variantes, até os modelos relacionados à utilização de código móvel. Todas as principais características de um sistema distribuído onde dispositivos móveis podem ser incluídos ou excluídos, bem como requisitos gerais de projeto para sistemas distribuídos devem ser conhecidos e abordados. (GROSS, 2008, p. 41-42).

Já, modelos fundamentais têm como objetivo, segundo Coulouris, Dollimore e Kindberg (2007, p. 39),

auxiliar a revelar aspectos importantes para projetistas de sistemas distribuídos, especificando os principais problemas, dificuldades e ameaças que devemos considerar no desenvolvimento de sistemas distribuídos para que executem suas tarefas de maneira correta, segura e confiável, além de fornecer visões abstratas de características dos sistemas distribuídos e como estas afetam sua confiabilidade, segurança e correção.

2 CAMADAS E MÓDULOSDe acordo com Coulouris, Dollimore e Kindberg (2007, p. 40), o termo

“arquitetura de software” originalmente se referia à estruturação do software em camadas ou módulos em um único computador, e mais recentemente, em termos de serviços oferecidos e solicitados entre processos localizados em um mesmo computador ou em computadores diferentes. Essa visão orientada a processos e serviços pode ser expressa em termos de “camadas de serviço”, conforme figura a seguir.

FIGURA 47 – CAMADAS DE SOFTWARE E HARDWARE EM SERVIÇOS DE SISTEMAS DISTRIBUÍDOS

FONTE: Adaptado de Coulouris, Dollimore e Kindberg (2007, p. 41)

TÓPICO 2 | ARQUITETURA DE SISTEMAS DISTRIBUÍDOS

121

Um servidor é um processo que aceita pedidos de outros processos. Um serviço distribuído pode ser fornecido por um ou mais processos servidores, interagindo uns com os outros e com processos clientes para manter uma visão consistente em nível de sistema dos recursos do serviço. Um exemplo disso é o serviço de sincronismo dos relógios de computadores, implementado na internet com base no protocolo NTP (Network Time Protocol) através de processos servidores que executam em diversos computadores em toda a internet. Esses servidores fornecem a hora atual para qualquer cliente que a solicite e acerta sua hora atual como resultado de interações realizadas com outros servidores. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 40 e 41).

“Middleware é uma camada de software que tem por objetivo mascarar a heterogeneidade e fornecer um modelo de programação conveniente para os programadores de aplicativos”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 41).

NOTA

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 41), “um middleware é composto por um conjunto de processos ou objetos, em um grupo de computadores, que interagem entre si de forma a implementar comunicação e oferecer suporte para compartilhamento de recursos a aplicativos distribuídos”. Ele se destina a fornecer blocos básicos de construção para a montagem de componentes de software que possam trabalhar juntos em um sistema distribuído.

O middleware simplifica as atividades de comunicação de programas aplicativos por meio do suporte de abstrações como a invocação a métodos remotos, a comunicação entre um grupo de processos, a notificação de eventos, o particionamento, posicionamento e recuperação de objetos de dados compartilhados entre computadores, a replicação de objetos de dados compartilhados e a transmissão de dados multimídia em tempo real. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 41).

“Na ciência da computação, a expressão tempo-real, é uma expressão referente a sistemas em que o tempo de execução de uma determinada tarefa é rígido. O tempo de execução de uma operação pode ser muito curto, ou não. O que importa para este tipo de sistema é que a tarefa seja executada. O sistema deve ser implementado visando principalmente a ordem de agendamento das tarefas e o gerenciamento de recursos para que possa executar a tarefa no tempo correto ou informar imediatamente que a tarefa não poderá ser executada”. Fonte: WIKIPÉDIA. Disponível em: <http://pt.wikipedia.org/wiki/Tempo_real>. Acesso em: 13 out. 2012).

IMPORTANTE

122


Segundo Gross (2008, p. 43), “pacotes de chamada a procedimentos remotos (Remote Procedure Call – RPC) como o RPC da Sun e os sistemas de comunicação em grupo como o Isis, são exemplos dos primeiros tipos de middleware. Hoje em dia existem muitos padrões e produtos de middleware orientados a objetos sendo empregados amplamente”. Entre outros, incluem-se:

• CORBA (Common Object Request Broker Architecture).• Java RMI (Remote Method Invocation).• Web services (serviços web).• Microsoft DCOM (Distributed Component Object Model).• ISO/ITU-T RM-ODP (Reference Model for Open Distributed Processing).

“O Middleware também pode fornecer serviços a serem usados por programas aplicativos. Essencialmente, eles são serviços de infraestrutura fortemente vinculados ao modelo de programação distribuída e fornecida pelo middleware.” (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 42).

NOTA

3 MODELOS DE ARQUITETURA“A divisão de responsabilidades entre os componentes de um sistema

(aplicativos, servidores e outros processos) e a atribuição destes nos diversos computadores de uma rede talvez seja o aspecto mais evidente do projeto de sistemas distribuídos. Isso tem implicações importantes no desempenho, na confiabilidade e na segurança do sistema resultante.” (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 42 e 43).

“Em um sistema distribuído, os processos possuem responsabilidades bem definidas e interagem para realizar uma atividade útil”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 43).

NOTA


123

3.1 MODELO CLIENT-SERVER

Segundo Fernandes (1999, p. 38), “o modelo cliente-servidor é uma resposta estratégica da tecnologia às novas exigências do mercado: maior flexibilidade, maior agilidade e maior competitividade no tratamento das informações da empresa, por possibilitar a criação de um ambiente “online” robusto e de alto desempenho, sendo considerada uma tecnologia emergente e que vem ganhando adeptos rapidamente.”

Surgiu como um aprimoramento do processamento distribuído baseado simplesmente na utilização de redes de PCs e no processo de Downsizing, que apresentava algumas desvantagens em relação à arquitetura centralizada do Mainframe, caracterizada principalmente pela maior dificuldade de administração dos dados, resultando em redundâncias e inconsistências das informações da empresa.

Downsizing (em português: achatamento) é uma das técnicas da Administração contemporânea, que tem por objetivo a eliminação da burocracia corporativa desnecessária, pois ela é focada no centro da pirâmide hierárquica, isto é, na área de recursos humanos (RH). Trata-se de um projeto de racionalização planejado em todas as suas etapas, que deve estar consistente com o Planejamento estratégico do negócio e cuja meta global é construir uma organização o mais eficiente e capaz possível, privilegiando práticas que mantenham a organização mais enxuta possível. A curto prazo envolve demissões, achatamento da estrutura organizacional, reestruturação, redução de custos, e racionalização. A longo prazo revitaliza a empresa com a expansão de seu mercado, desenvolve melhores produtos e serviços, melhora a moral dos funcionários, moderniza a empresa e principalmente, a mantém enxuta, de forma que a burocracia não venha a se instalar novamente, uma vez amenizadas as pressões. FONTE: WIKIPÉDIA. Disponível em: <http://pt.wikipedia.org/wiki/Downsizing>. Acesso em: 13 jul. 2012.

IMPORTANTE

Possibilita uma maior produtividade, característica do ambiente de redes de microcomputadores, e um maior controle, característica esta oriunda do ambiente Mainframe e da computação centralizada. Talvez sua maior vantagem seja a preservação dos investimentos já realizados em equipamentos e sistemas, pois os recursos existentes não precisam necessariamente ser descartados, mas redistribuídos segundo o enfoque do modelo cliente-servidor:

• Componentes consumidores de recursos (clientes).• Componentes fornecedores de recursos (servidores).• Componentes pares, tanto consumidores quanto fornecedores (peer-to-peer).

124


Componentes pares (peer-to-peer) são processos que colaboram e se comunicam de maneira simétrica para realizar uma tarefa, sem distinção entre processos clientes e servidores, nem entre os computadores em que são executados.

NOTA

Neste modelo, que possibilita grande flexibilidade, podem ser integrados desde o menor PC de uma corporação até o maior Mainframe, permitindo constantes realocações e crescimento incremental, de acordo com a evolução dos negócios da corporação. Um computador inicialmente alocado como servidor pode ser substituído por outro maior, passando a exercer funções de cliente em outra aplicação.

De acordo com Fernandes (1999, p. 38-39), “o hardware de uma arquitetura cliente-servidor é composto de computadores que se utilizam de serviços e dados e de outros computadores que administram e disponibilizam esses serviços e dados”. Todos os computadores, usuários ou fornecedores desses recursos são interconectados por meio de uma rede, local ou remota, não importando a tipologia de construção da rede ou o protocolo utilizado na comunicação.

O software de uma arquitetura Cliente/Servidor é aquele que garante que toda aplicação pode utilizar os recursos disponibilizados na rede, estabelecendo uma forma bem definida de comunicação entre a aplicação que fornece recursos à rede (aplicação servidora) e a aplicação que os consome (aplicação cliente).

Esta é, sem dúvida, a arquitetura mais citada quando se discutem sistemas distribuídos, sendo historicamente a mais importante e amplamente empregada atualmente. A figura a seguir mostra a disposição de processos (elipses) nos computadores (caixas cinza), ilustrando a estrutura simples na qual os processos clientes interagem com processos servidores, localizados em distintos computadores hospedeiros, para acessar os recursos compartilhados que estes gerenciam. Os termos “invoca” e “resultado” são usados para rotular as mensagens, que poderiam ser rotuladas também como pedido e resposta, ou ainda remessa e retorno.

FIGURA 48 – CLIENTES REALIZANDO PEDIDOS A SERVIDORES

FONTE: Adaptado de: COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems: concepts and design. 3. ed. England: Addison Wesley, 2001, p. 34.


125

Os servidores podem ser clientes de outros servidores, conforme indicado na figura acima. Um exemplo disso é um servidor internet, que é com frequência um cliente de um servidor de arquivos local que gerencia os arquivos nos quais as páginas web estão armazenadas. Por sua vez, os servidores internet e a maioria dos outros serviços internet são clientes do serviço DNS, que faz o mapeamento entre nomes de domínio internet e endereços IP de rede. Outro exemplo, também relacionado à internet, são os mecanismos de busca, “que permitem usuários efetuar pesquisas de informações disponíveis em páginas web em sites de toda a internet. Tais resumos são efetuados por programas web crawler, também chamados spiders, executados em segundo plano em sites de mecanismos de busca e usando requisições HTTP para acessar servidores web em toda a internet”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 43).

Conforme a Cyclades Brasil (2001, p. 22), “os equipamentos na internet são normalmente referenciados por um nome simbólico, que está associado ao seu endereço IP. Esta associação é feita por um conjunto de servidores, de forma que o conjunto formado por esses servidores e sua interface com as aplicações da internet é conhecido como Domain Name System (DNS), sendo estruturado em dois pontos básicos: a organização da internet em domínios, e a distribuição dos servidores DNS na internet.”

IMPORTANTE

No exemplo da figura acima, as tarefas do servidor – responder a consultas de usuários – e às tarefas da web crawler – fazer pedidos para outros servidores internet – são totalmente independentes, possuindo pouca necessidade de sincronismo, e podendo ser executadas de maneira concomitante. De fato, um mecanismo típico de busca normalmente é efetuado por muitas threads concorrentes, algumas servindo seus clientes e outras executando web crawlers. Portanto, um mecanismo de busca é tanto um servidor quanto um cliente, pois responde a requisições de clientes e executa web crawlers que atuam como clientes de outros servidores internet.

Segundo a Wikipédia (2012), “uma thread é uma forma de um processo dividir a si mesmo em duas ou mais tarefas que podem ser executadas concorrentemente. O suporte à thread é fornecido pelo próprio sistema operacional, ou implementada através de uma biblioteca de uma determinada linguagem de programação. Permite que o usuário de um programa utilize uma funcionalidade do ambiente enquanto outras linhas de execução realizam outros cálculos e operações.” Disponível em:<http://pt.wikipedia.org/wiki/Thread_(ci%C3%AAncia_da_computa%C3%A7%C3%A3o)>. Acesso em: 13 out. 2012.

NOTA

126


3.2 SERVIÇOS ATENDIDOS POR MÚLTIPLOS SERVIDORES

FIGURA 49 – UM SERVIÇO FORNECIDO POR VÁRIOS SERVIDORES

FONTE: Adaptado de: COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed systems: concepts and design. 3. ed. England: Addison Wesley, 2001, p. 35.

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 44-45), “os serviços podem ser implementados como vários processos servidores em diferentes computadores hospedeiros, interagindo conforme for necessário para fornecer um serviço para os processos clientes” (vide figura anterior). Os servidores podem particionar o conjunto de objetos nos quais o serviço é baseado e distribuí-los entre eles mesmos ou podem, ainda, manter cópias duplicadas deles em vários outros hospedeiros. Essas duas opções são ilustradas pelos exemplos a seguir.

“A web oferece um exemplo comum de particionamento de dados no qual cada servidor web gerencia seu próprio conjunto de recursos. Um usuário pode usar um navegador para acessar um recurso em qualquer um desses servidores”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 45).

Um exemplo de serviço baseado em dados replicados, de acordo com Coulouris, Dollimore e Kindberg (2007, p. 45), “é o NIS (Network Information Service) da Sun, usado por computadores em uma rede local quando os usuários se conectam. Cada servidor NIS tem sua própria cópia (réplica) de um arquivo de senhas que contêm uma lista de nomes de login dos usuários e suas respectivas senhas criptografadas”. Segundo Coulouris, Dollimore e Kindberg (2007, p. 45-46),


127

(...) um tipo de arquitetura onde ocorre uma interação maior entre vários servidores, e por isso, denominada de arquitetura fortemente acoplada, é o baseado em cluster. Essa arquitetura é comumente empregada por serviços web que necessitam oferecer um grande grau de escalabilidade, como os mecanismos de busca e as lojas online. Um cluster é construído a partir de várias, às vezes centenas, de unidades de processamento.

Nessa arquitetura, a execução de um serviço pode ser particionada ou duplicada entre as unidades de processamento.

De acordo com Dantas (2005, p. 265), “clusters são configurações que podem ser entendidas como uma agregação de computadores de uma forma dedicada (ou não) para a execução de aplicações específicas de uma organização”.

De acordo com nota de redação técnica de Coulouris, Dollimore e Kindberg (2007, p. 45), “é comum encontrarmos os termos agregados, ou agrupamentos, como tradução da palavra cluster. Na realidade, existem dois tipos de clusters. Os denominados de fortemente acoplados são compostos por vários processadores e atuam como multiprocessadores. Normalmente são empregados para atingir alta disponibilidade e balanceamento de carga. Os fracamente acoplados são formados por um conjunto de computadores interligados em rede e são comumente utilizados para processamento paralelo e de alto desempenho.”

NOTA

3.3 SERVIDOR PROXY E CACHE

“O cache tem por objetivo realizar o armazenamento de objetos de dados utilizados recentemente em um local mais próximo do que a original localização de tais objetos. Quando um novo objeto é recebido em um computador, ele é adicionado ao cache, substituindo, caso necessário, alguns objetos já existentes”. (GROSS, 2008, p. 49).

De acordo com Gross (2008, p. 49), “quando um processo cliente requisita um objeto, o serviço de cache primeiramente verifica se possui uma cópia atualizada desse objeto armazenada. Caso possua, ele é entregue ao processo cliente. Se o objeto não estiver armazenado, ou se a cópia armazenada não estiver atualizada, ele é acessado diretamente na sua origem”.

A figura a seguir mostra como um servidor proxy web fornece um cache compartilhado de recursos web para máquinas clientes de um ou vários sites. O objetivo dos servidores proxy é o aumento da disponibilidade e do desempenho do serviço, reduzindo a carga sobre a rede remota e sobre os servidores internet.

128


FIGURA 50 – SERVIDOR PROXY WEB


Conforme Coulouris, Dollimore e Kindberg (2007, p. 46), “a utilização de caches na prática é bastante comum. Por exemplo, os navegadores de internet mantêm no sistema de arquivos local um cache das páginas recentemente visitadas e, antes de exibi-las, com o auxílio de uma requisição HTTP especial, verifica nos servidores originais se as páginas armazenadas no cache estão atualizadas”.

“O cache pode ser mantido nos próprios clientes, ou localizados em um servidor proxy que possa ser compartilhado por eles”. (GROSS, 2008, p. 49).

NOTA

Os servidores proxy podem também assumir outras funções, tais como serem usados para acesso de servidores internet através de um firewall. Embora a função de um firewall seja a de controlar ou até mesmo isolar o tráfego entre duas redes quaisquer, a motivação principal para a sua popularização foi a de “proteger” redes corporativas ligadas à internet de ataques de usuários mal intencionados (hackers, crackers etc.). A utilização de firewall em se tratando de conexões à internet se aplicam sempre, independente do objetivo dessa conexão, especialmente quando existe informação vital a ser protegida, como é o caso de intranets (extranets) e provedores de informações. O nível de segurança desejado é o que vai determinar como será a implementação desse firewall (GROSS, 2008)


129

DICAS

Um excelente filme para conhecer mais sobre hacke-rs e crackers é o filme “Hackers: criminosos e anjos”.Enquanto as ciências da computação buscam abranger cada vez mais todas as áreas e atividades do nosso cotidiano, governos, empresas e o público em geral tornam-se vítimas do terroris-mo cibernético, da espionagem industrial e múltiplas formas de fraude. Este documentário investiga o mundo do crime ciberné-tico: as vítimas, os invasores, seus métodos e suas motivações. Vamos nos aprofundar nesse mundo sombrio, enquanto os or-ganismos da lei contam com a ajuda de ex-hackers para tentar proteger cidadãos e instituições do que se pode prever como um verdadeiro caos eletrônico.HACKERS: CRIMINOSOS E ANJOS. Direção de Mike Smith. EUA:Discovery Channel / September Films, 2002, DVD (50 min), color.

3.4 PROCESSOS PARES

Conforme Coulouris, Dollimore e Kindberg (2007, p. 44), nesta arquitetura, também conhecida como peer-to-peer, “todos os processos envolvidos em uma tare-fa ou atividade desempenham funções semelhantes, interagindo cooperativamente como pares (peers), sem distinção entre processos clientes e processos servidores, nem entre os computadores em que são executados”.

Embora o modelo cliente-servidor ofereça uma estratégia direta e relati-vamente simples para o compartilhamento de dados e outros recursos, ele não é flexível em termos de escalabilidade. “A centralização do fornecimento e gerenci-amento de serviços, acarretada pela colocação de um serviço em um único com-putador, não favorece um aumento de escala, além daquela limitada pela capaci-dade do computador que contém o serviço e da largura de banda de suas conexões de rede”. (GROSS, 2008, p. 51).

No subtópico 4 serão descritas algumas variações do modelo de arquitetu-ra cliente-servidor que evoluíram como uma resposta a este problema, contudo nenhuma trata do problema fundamental – a necessidade de se distribuir recursos compartilhados de maneira mais ampla para se dividir cargas de computação e co-municação entre um número muito grande de computadores e conexões de rede.

A capacidade do hardware e a funcionalidade do sistema operacional dos computadores desktop atuais, segundo Coulouris, Dollimore e Kindberg (2007, p. 44), “ultrapassam aquelas dos servidores antigos, e ainda, a maioria desses com-putadores está equipada com conexões de rede de banda larga e sempre ativas”.

130


O objetivo da arquitetura peer-to-peer é explorar os recursos (tanto dados como hardware) de um grande número de computadores para o cumprimento de uma determinada tarefa ou atividade. Tem-se construído, com sucesso, “aplicativos e sistemas peer-to-peer que permitem a dezenas, ou até mesmo a centenas de mil-hares de computadores fornecerem acesso a dados e a outros recursos que eles ar-mazenam e gerenciam coletivamente”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 44).

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 44), “o exemplo mais antigo e conhecido desse tipo de arquitetura é o aplicativo Napster, empre-gado para o compartilhamento de arquivos de música digital”. Embora tenha se tornado famoso por outro motivo que não sua arquitetura, sua demonstração de exequibilidade resultou no desenvolvimento desse modelo de arquitetura em dif-erentes e importantes diferentes direções.

De acordo com Gross (2008, p. 52), ”o Napster foi o primeiro programa de compartilhamento massivo de arquivos através de tecnologia ponto a ponto (peer-to-peer). Criado por Shawn Fanning, o programa compartilhava somente arquivos de música no formato MP3. O Napster permitia que os usuários baixassem arquivos diretamente nos computadores de outros usuários. Criou assim, uma imensa comunidade global com milhares de músicas disponíveis, onde um usuário baixava do outro e disponibilizava suas músicas para toda a rede.”

IMPORTANTE

A figura a seguir ilustra processos executando regras similares em computadores distintos, interagindo como pares, sem distinção entre clientes e servidores, com o código mantendo a consistência dos recursos em nível de aplicação e sincronizando ações, quando necessário. Em geral, um número n de processos pares pode interagir uns com os outros, sendo que o padrão de comunicação irá depender dos requisitos da aplicação.

FIGURA 51 – UMA APLICAÇÃO DISTRIBUÍDA BASEADA EM PROCESSOS PARES

FONTE: Adaptado de COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed systems: concepts and design. 3. ed. England: Addison Wesley, 2001, p. 37.


131

4 VARIAÇÕES DO MODELO CLIENTE-SERVIDORDe acordo com Gross (2008, p. 52), algumas variações dos modelos

anteriores podem ser extraídas considerando-se os seguintes fatores:

• O uso de código móvel e de agentes móveis.• A necessidade de usuários possuírem computadores de baixo custo, com

recursos de hardware limitados e fáceis de gerenciar.• O requisito de adição e remoção de dispositivos móveis de maneira conveniente.

4.1 CÓDIGO MÓVEL

Segundo Coulouris, Dollimore e Kindberg (2007, p. 29), o termo código móvel, ou ainda migração de código, é usado para se referir ao código que pode ser enviado de um computador para outro e ser executado no destino. Applets Java são exemplos bem conhecidos e muito utilizados de código móvel, onde o usuário, executando um navegador, seleciona um link que aponta para um applet, cujo código é armazenado em um servidor internet; o código é carregado no navegador e, como se vê na figura a seguir, posteriormente executado.

FIGURA 52 – APPLETS WEB

FONTE: Adaptado de COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed systems: oncepts and design. 3. ed. England: Addison Wesley, 2001, p. 37.

a) Requisição do cliente resulta no dowload do código de um applet

b) O cliente interage com o applet

132


Conforme a Wikipédia (2012), um applet é um software aplicativo que é executado no contexto de outro programa, geralmente possuindo algum tipo de interface com o usuário, ou fazem parte de uma parte destas dentro de uma página web, tendo a capacidade de interagir com e/ou influenciar seu programa hospedeiro. Diferente de um programa comum, um applet não pode rodar sozinho, devendo rodar em um container, um programa hospedeiro, através de um plugin ou uma variedade de outros aplicativos, incluindo aparelhos móveis que suportam o modelo de programação de applet. Outro exemplo de applet são os vídeos em Flash ou os applets de players de vídeo (como o Windows Media Player) que executam dentro de navegadores de internet que suportam os plugins. Disponível em: <http://pt.wikipedia.org/wiki/Applet>. Acesso em: 13 out. 2012.

IMPORTANTE

Um código destinado à execução em um computador não é necessariamente adequado para outro computador, pois, normalmente, os programas executáveis são específicos a um conjunto de instruções e a um sistema operacional. Por exemplo, “arquivos executáveis enviados como anexos de e-mail por usuários de Windows/x86 não funcionarão em um computador x86 executando Linux ou em um computador Macintosh executando Mac OS X”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 29).

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 29), “a estratégia de máquina virtual oferece uma maneira de tornar um código executável em qualquer tipo de processador (hardware) e sistema operacional. Nessa estratégia, o compilador de uma linguagem em particular gera código para uma máquina virtual, em vez de código para um processador e sistema operacional específicos”; por exemplo, o compilador Java produz código para a máquina virtual Java (JVM – Java Virtual Machine).

Ainda segundo Coulouris, Dollimore e Kindberg (2007, p. 29), “para permitir a execução de programas Java, torna-se necessário ter uma versão da JVM implementada para o processador e sistema operacional da máquina alvo”. Uma vantagem de se executar um código localmente é que ele pode dar uma boa resposta interativa, pois não sofre os atrasos, nem a variação da largura de banda associada à comunicação na rede. Entretanto, a solução Java não é aplicável de forma generalizada aos programas escritos em outras linguagens.

Acessar serviços significa executar código que pode ativar suas operações. Alguns serviços são tão padronizados que podemos acessá-los com um aplicativo já existente e bem conhecido – “a web é o exemplo mais comum disso, mas mesmo nela, alguns sites usam funcionalidades não disponíveis em navegadores padrão e exigem o download de código adicional. Esse código adicional pode, por exemplo, se comunicar com um servidor”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 47).


133

Considere uma aplicação que exige que os usuários precisem estar atualizados com relação às alterações que ocorrerem em uma fonte de informações em um servidor. Isso não pode ser obtido pelas interações normais com o servidor web, pois essas são sempre iniciadas pelo cliente. “A solução é usar software adicional que opere de uma maneira frequentemente referida como modelo push – no qual o servidor inicia as interações, em vez do cliente” (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 47).

Como exemplo disso, Coulouris, Dollimore e Kindberg (2007, p. 47) sugerem que um corretor de bolsa de valores poderia fornecer um serviço personalizado para notificar os usuários sobre alterações nos preços das ações. Para usar esse serviço, “cada indivíduo teria que fazer o download de um applet especial que recebesse atualizações do servidor do corretor, as exibisse para o usuário e, talvez, executasse automaticamente operações de compra e venda, disparadas por condições preestabelecidas e armazenadas por uma pessoa em seu computador”.

O uso de código móvel é uma ameaça potencial à segurança do computador destino. Como uma das formas empregadas para reduzir esse risco, os navegadores de internet dão aos applets um acesso limitado a seus recursos locais (GROSS, 2008, p. 54).

NOTA

4.2 AGENTES MÓVEIS

Coulouris, Dollimore e Kindberg (2007, p. 47) definem um agente móvel como sendo “um programa em execução (inclui código e dados) que passa de um computador para outro em um ambiente de rede, realizando uma tarefa em nome de alguém, como uma coleta de informações, e finalmente retornando com os resultados obtidos a esse alguém”.

Um agente móvel pode efetuar várias requisições aos recursos locais de cada site que visita como, por exemplo, acessar entradas de bancos de dados. “Se compararmos essa arquitetura com um cliente estático que solicita, via requisições remotas, acesso a alguns recursos, possivelmente transferindo grandes volumes de dados, há uma redução no custo e no tempo da comunicação graças à substituição das requisições remotas por requisições locais”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 47).

Segundo Coulouris, Dollimore e Kindberg (2007, p. 47), “podem ser usados para instalar e manter softwares em computadores dentro de uma empresa, ou para comparativo de preços de produtos de diversos fornecedores, visitando o site de cada fornecedor e executando uma série de operações de consulta”.

134


Ainda de acordo com Coulouris, Dollimore e Kindberg (2007), assim como o código móvel, os agentes móveis também são uma ameaça em potencial à segurança para os recursos existentes nos computadores que visitam. O ambiente que recebe um agente móvel deve decidir, com base na identidade do usuário, em nome de quem o agente está atuando, qual dos recursos locais ele pode usar. A identidade deve ser inclusa de maneira segura com o código e com os dados do agente móvel. Além disso, os agentes móveis, em si, podem ser vulneráveis – eles podem não conseguir completar sua tarefa, caso o acesso às informações de que precisam sejam recusadas.

Para contornar esse problema, as tarefas executadas pelos agentes móveis podem ser feitas usando-se outras técnicas. Por exemplo, os web crawlers que precisam acessar recursos em servidores web em toda a internet funcionam com muito sucesso, fazendo requisições remotas de processos servidores. Por esses motivos, “a aplicabilidade dos agentes móveis é limitada” (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 48).

“Os aglets são objetos Java que podem se mover de um lugar para outro da internet. Assim sendo, um aglet que está executando em uma determinada máquina pode interromper a sua execução, enviar-se para outra máquina remota e reassumir sua execução neste novo local. Quando um aglet se move, ele carrega consigo seu código de programa bem como o seu estado (dados correntes)”. (GROSS, 2008, p. 56).

“Aglets Workbench é uma plataforma de agentes móveis, desenvolvida em Java 1.1 pela IBM/Japão. Posteriormente, o código fonte dessa plataforma foi aberto, em uma tentativa de se obter voluntários, interessados em trabalhar no processo de adaptação desse código para as versões posteriores do Java”. (GROSS, 2008, p. 56).

NOTA

4.3 COMPUTADORES EM REDE

Na arquitetura ilustrada na figura a seguir, um usuário pode executar uma série de aplicativos localmente em seu computador desktop. Os sistemas operacionais e os softwares aplicativos desse tipo de computador exigem que grande parte do código e dos dados ativos esteja armazenada localmente em um disco rígido. Contudo, o gerenciamento de arquivos de aplicativos, e a própria manutenção de uma base de software local, exige um considerável esforço técnico, de uma maneira que a maioria dos usuários comuns não está qualificada a oferecer (COULOURIS; DOLLIMORE; KINDBERG, 2007).


135

FIGURA 53 – UMA TÍPICA INTRANET

FONTE: Braziltec. Disponível em: <http://braziltec.com/datacenter/images/intranet.jpg>. Acesso em: 14 out. 2012.

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 48), “o uso dos computadores em rede surge como uma resposta a esse problema, permitindo que tanto o sistema operacional como todo o software aplicativo necessário para o usuário, seja carregado a partir de um servidor de arquivos remoto. Os aplicativos são executados de forma local no computador do usuário, contudo são gerenciados pelo servidor de arquivos remoto”. Aplicativos de rede, como por exemplo, um navegador internet, também pode ser executado dessa forma. Como todos os dados e código de aplicativo são armazenados em um servidor de arquivos, os usuários podem migrar de um computador de rede para outro sem afetar o seu trabalho. A capacidade do processador e da memória de um computador em rede pode ser restrita de forma a reduzir o seu custo.

Ainda segundo Coulouris, Dollimore e Kindberg (2007), caso o computador em rede tenha um disco rígido, ele poderá conter um mínimo necessário de software. O restante do disco poderá ser usado como armazenamento cache, contendo cópias do software e dos arquivos de dados recentemente recuperados pelos servidores. A manutenção da validade das informações do cache não exige nenhum esforço por parte dos usuários: os objetos ali armazenados podem ser automaticamente invalidados quando uma nova versão de um arquivo for gravada em um determinado servidor.

136


4.4 CLIENTES FRACOS

FIGURA 54 – THIN CLIENTS E SERVIDORES DE COMPUTAÇÃO

FONTE: Adaptado de COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed Systems: concepts and design. 3. ed. England: Addison Wesley, 2001, p. 39.

Clientes fracos, clientes magros ou clientes leves (em inglês, thin clients), se referem a uma camada de software, em um computador local, que oferece ao usuário uma interface que se baseia em janelas para que este possa executar programas aplicativos em um computador remoto (figura anterior). Esta arquitetura, segundo Coulouris, Dollimore e Kindberg (2007, p. 48), “tem os mesmos baixos custos de gerenciamento e de hardware que o esquema de computadores em rede, porém, ao invés de fazer o download do código de aplicativos no computador do usuário, ela os executa em um servidor de computação – um computador com capacidade suficiente para executar um grande número de aplicativos simultaneamente”. Normalmente o servidor de computação é um computador com vários processadores ou um cluster executando uma versão para multiprocessadores de um sistema operacional, como o UNIX ou o Windows.

O principal inconveniente desta arquitetura está nas atividades gráficas altamente interativas, como CAD e processamento de imagens, onde os atrasos sentidos pelos usuários aumentam em função da necessidade de transferência de imagens entre o thin client e o processo aplicativo, o que provoca latências na rede e no sistema operacional (COULOURIS; DOLLIMORE; KINDBERG, 2007).

“CAD (Computer Aided Design), ou desenho auxiliado pelo computador, é o nome genérico dos sistemas computacionais utilizados para facilitar o projeto de desenhos técnicos, consistindo em uma série de ferramentas para construção de entidades geométricas planas (linhas, polígonos e curvas) ou ainda objetos tridimensionais (cubos, esferas, cilindros e outros)”. (GROSS, 2008, p. 58).

NOTA


137

Segundo Coulouris, Dollimore e Kindberg (2007, p. 48-49), “os sistemas thin client são conceitualmente simples e sua implementação em alguns ambientes é direta. Por exemplo, a maioria das variações do sistema operacional UNIX inclui o sistema de janelas X-11, um processo que gerencia a tela e dispositivos de entrada interativos (teclado, mouse) do computador no qual ele é executado, fornecendo uma ampla biblioteca de funções (o protocolo X-11) para exibição e modificação de objetos gráficos em janelas, assim como a criação e manipulação das próprias janelas”.

“X-11 é o toolkit e o protocolo padrão para GUI nos sistemas UNIX e assemelhados, como o Linux. Também existe em versões para outros sistemas operacionais, como, por exemplo, o Microsoft Windows e o Mac OS. Desenvolvido pelo Instituto de Tecnologia de Massachussets (MIT) em 1984, foi originalmente chamado simplesmente de X. Como atualmente encontra-se na versão 11, carrega este número em seu nome”. (GROSS, 2008, p. 58).

IMPORTANTE

O sistema X-11 é referenciado como um processo servidor de janelas. Os programas aplicativos com os quais o usuário está interagindo no momento são os clientes de um servidor X-11. Os programas clientes se comunicam com o servidor através de requisições ao protocolo X-11, o que inclui as operações para desenhar textos e objetos gráficos em janelas. Os clientes podem ou não executar no mesmo computador que o servidor, pois as funções disponibilizadas pelo servidor são sempre acionadas com um mecanismo RPC (Remote Procedure Call). Portanto, o servidor de janelas X-11 tem as principais propriedades de um thin client (COULOURIS; DOLLIMORE; KINDBERG, 2007).

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 49),

(...) existem vários pontos na sequência de tratamento de informações necessários para suportar adequadamente uma interface com o usuário, nos quais o limite entre cliente e servidor pode ser definido. O produto WinFrame da Citrix é uma implementação comercial, bastante utilizada, do conceito thin client que opera de maneira semelhante ao X-11. Esse produto fornece um processo cliente que pode ser executado em uma grande variedade de plataformas e oferece um ambiente de trabalho que permite o acesso interativo a aplicativos executados em máquinas Windows.

Outras implementações incluem o sistema VNC (Virtual Network Computer), desenvolvido nos laboratórios da AT&T em Cambridge, Inglaterra, suportando operações gráficas em nível de pixels de tela e salvando o contexto do ambiente gráfico dos usuários mesmo no caso de troca de computadores por parte destes.

138


4.5 DISPOSITIVOS MÓVEIS

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 49), “enquanto agentes móveis migram entre computadores físicos, dispositivos móveis são componentes de computação, em hardware, que se movem entre locais físicos e, portanto, em redes, transportando consigo componentes de software”.

Coulouris, Dollimore e Kindberg (2007) afirmam que há no mundo cada vez mais dispositivos móveis, incluindo, entre outros, laptops, equipamentos de mão, como os PDAs (Personal Digital Assistants - assistentes pessoais digitais), telefones móveis, câmeras digitais e computadores acoplados ao corpo humano, como os relógios de pulso inteligentes. Cada vez mais, muitos destes equipamentos possuem a capacidade de se comunicar através do uso de redes sem fio. O raio de ação das redes sem fio varia desde um nível nacional, ou mesmo maior, como as redes de comunicação GSM e 3G, a algumas centenas de metros, como redes WiFi (IEEE 802.11) ou ainda a cerca de uma dezena de metros, como o Bluetooth.

Se você quiser conhecer mais sobre a tecnologia Bluetooth, leia o artigo completo dessa tecnologia, publicado na Wikipédia, disponível em <http://pt.wikipedia.org/wiki/Bluetooth>.

DICAS

A mobilidade do dispositivo tem muitas implicações, dentre elas, várias para os sistemas baseados na arquitetura cliente-servidor. Tanto clientes quanto servidores podem coexistir em dispositivos móveis – sendo os clientes móveis o caso mais comum (COULOURIS; DOLLIMORE; KINDBERG, 2007).

Considere uma família de navegantes que realiza um passeio pelo mundo, explorando conectividade WiFi nos locais onde ela estiver disponível, ou a infraestrutura da rede de telecomunicações via satélite em outros lugares. Os familiares querem atualizar e ler um site que contém fotos e informações sobre o passeio. A maneira mais óbvia de se conseguir isto seria que todos acessassem um servidor fixo, com os navegantes fazendo upload e lendo dados a partir de seus clientes móveis. Mas uma alternativa possível seria executar o servidor web no próprio barco, para que o próprio servidor fosse móvel. “O servidor não apenas poderia fornecer fotos e informações para os usuários, mas também poderia fornecer um mapa mostrando a posição correta da embarcação, usando um receptor GPS (Global Positioning System)”. (GROSS, 2008, p. 59-60).


139

A transparência de mobilidade é um problema frequente para dispositivos móveis, assim como para agentes móveis. Em particular, os clientes de um servidor móvel, como o caso do exemplo da família de navegantes, não precisam saber de sua movimentação entre as diferentes redes (mesmo que a família possa estar interessada na localização geográfica de seu barco, conforme mostrado no mapa atualizado pelo GPS). O IP móvel oferece uma solução por meio da qual o servidor do barco mantém o seu endereço internet (IP), mesmo que se mova entre várias redes (GROSS, 2008).

A conectividade variável é outra questão importante, e que afeta tanto a capacidade do barco de atuar como servidor, como a capacidade de seus passageiros em acessar serviços externos. O barco pode perder a conexão com a rede sem fio de forma intermitente, por breves períodos de tempo, enquanto passa por obstáculos que bloqueiam o sinal de transmissão, como pontes, ou por períodos maiores, em regiões onde a conectividade à rede sem fio cessa completamente, como as áreas de sobra de sinal. Além disso, o servidor do barco está sujeito a uma largura de banda bastante variável, ao se mover entre conexões da rede WiFi e da rede de telecomunicações.

4.6 INTEROPERABILIDADE ESPONTÂNEA

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 50), “a interoperabilidade espontânea é uma variação do modelo cliente-servidor na qual associações entre dispositivos são rotineiramente criadas e destruídas”. Um usuário poderia visitar uma organização anfitriã e usando seus dispositivos móveis em conjunto com os dispositivos do anfitrião, como as impressoras.

Analogamente, poderiam ser oferecidos aos passageiros do barco, serviços integrados com os ambientes físicos pelos quais o barco passa, como informações sobre as atrações turísticas locais. O principal desafio que se aplica a tais situações é tornar a interoperabilidade rápida e conveniente (isto é, espontânea), mesmo que o usuário esteja em um ambiente que nunca tenha visitado antes. Isso significa ativar o dispositivo do visitante para se comunicar na rede do anfitrião e associá-lo convenientemente aos serviços locais – um processo chamado de descoberta de serviço.

4.7 COMPUTAÇÃO UBÍQUA OU PERVASIVA

Coulouris, Dollimore e Kindberg (2007, p. 568) relatam que Mark Weiser cunhou o termo computação ubíqua, em 1988. Às vezes, a computação ubíqua também é conhecida como computação pervasiva e os dois termos normalmente são considerados sinônimos. “Ubíquo” significa “em toda parte”. Weiser percebeu a predominância cada vez maior dos dispositivos de computação levando a mudanças revolucionárias na maneira como usaríamos os computadores.

140


“A computação ubíqua, também denominada de computação pervasiva, é a utilização de vários dispositivos computacionais pequenos e baratos, que estão presentes nos ambientes físicos dos usuários, incluindo suas casas, escritórios e até na rua”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 19).

IMPORTANTE

Cada pessoa no mundo utilizaria muitos computadores. Podemos comparar isso à revolução da computação pessoal anterior a essa, que viu um computador para cada pessoa. Embora pareça simples, essa mudança teve um efeito dramático sobre a maneira como usamos os computadores, em comparação à era anterior dos computadores de grande porte, quando havia apenas um computador para muitas pessoas. A ideia de Weiser de “uma pessoa, muitos computadores” significa algo muito diferente da situação comum, na qual cada um de nós tem vários computadores mais ou menos parecidos – um no trabalho, um em casa, um laptop e, talvez, um PDA que levamos conosco. Em vez disso, na computação ubíqua, os computadores se multiplicam na forma e na função e não apenas no número, para atender a diferentes tarefas (COULOURIS; DOLLIMORE; KINDBERG, 2007).

PDA – Personal Digital Assistant – Assistente pessoal digital, é um computador de dimensões reduzidas, dotado de grande capacidade computacional, cumprindo as funções de agenda e sistema informático de escritório elementar, com possibilidade de interconexão com um computador pessoal e uma rede informática sem fios para acesso a e-mail e internet. FONTE: <http://pt.wikipedia.org/wiki/Personal_digital_assistant>. Acesso em: 14 out. 2012.

DICAS

Considere o exemplo citado por Coulouris, Dollimore e Kindberg (2007, p. 568).

Suponha que todos os meios de exibição e escrita fixos em uma sala – quadros, livros, folhas de papel, notas adesivas etc. – fossem substituídos por dezenas ou centenas de computadores individuais com telas eletrônicas. Os quadros poderiam ajudar as pessoas a desenhar, organizar e arquivar suas ideias; os livros poderiam se tornar equipamentos que permitissem aos leitores pesquisarem seu texto, procurarem o significado de palavras, buscarem ideias relacionadas na web e verem conteúdo multimídia vinculado. Agora, incorpore funcionalidade de computação em todas as ferramentas de escrita. Por exemplo, as canetas e os marcadores se tornariam capazes de armazenar o que o usuário escreveu e desenhou, e de reunir, copiar e


141

mover conteúdo multimídia entre os muitos computadores situados nas imediações. Esse cenário levanta questões de capacidade de utilização e econômicos e toca apenas em uma pequena parte de nossas vidas, mas nos dá uma ideia do que a “computação por toda parte” poderia ser.

A segunda mudança que Weiser previu foi que os computadores “desapareceriam” – que eles “se incorporariam em utensílios e objetos do dia a dia, até se tornarem indistinguíveis”. Essa é principalmente uma noção psicológica, comparável ao modo como as pessoas aceitam normalmente a mobília de uma casa e mal a notam. Ela reflete a ideia de que a computação estará incorporada ao que consideramos itens do cotidiano – aqueles que normalmente não achamos que tenham recursos computacionais, nada diferente do que pensamos a respeito das máquinas de lavar, ou dos veículos como “equipamentos de computação”, mesmo tendo o controle de microprocessadores incorporados – cerca de 100 microprocessadores, no caso de alguns carros. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 568).

De acordo com Coulouris, Dollimore e Kindberg (2007), embora a visibilidade de certos dispositivos seja apropriada – nos casos como os sistemas de computadores incorporados em um carro –, isto não vale para todos os equipamentos que vamos considerar, particularmente para os dispositivos que os usuários móveis normalmente carregam. Por exemplo, os telefones móveis eram uns dos dispositivos de maior penetração, mas sua capacidade computacional dificilmente era visível e, com certeza, nem deveria ser.

142

Caro acadêmico! No Tópico 2, você estudou os seguintes conceitos:

• A arquitetura de um sistema tem como objetivo garantir que as necessidades atuais sejam supridas, prevendo também as futuras demandas, garantindo a confiabilidade, adaptabilidade, gerenciamento e rentabilidade do sistema.

• Os modelos de arquitetura definem como os componentes do sistema interagem e como são mapeados em uma rede de computadores, simplificando e abstraindo suas funções individuais, considerando seu posicionamento e inter-relacionamentos.

• Tanto a estrutura em camadas de software quanto os principais modelos de arquitetura que determinam localizações e iterações dos componentes precisam ser conhecidos e documentados, podendo esta documentação conter ainda as características do sistema distribuído prevendo a inclusão de dispositivos móveis, assim como os requisitos gerais de projeto.

• Os modelos fundamentais têm como objetivo auxiliar a revelar aspectos importantes para projetistas de sistemas distribuídos, especificando os principais problemas, dificuldades e ameaças que devem ser consideradas no desenvolvimento de sistemas distribuídos para que executem suas tarefas de maneira correta, segura e confiável. Também fornece visões abstratas de características dos sistemas distribuídos, e como estas afetam sua confiabilidade, segurança e correção.

• O middleware simplifica atividades de comunicação de programas aplicativos por meio do suporte de abstrações, como chamada de métodos remotos, comunicação em grupo de processos, notificações de eventos, particionamento, posicionamento e recuperação de objetos de dados compartilhados entre computadores, replicação de objetos de dados compartilhados e a transmissão de dados multimídia em tempo real.

• O modelo Cliente-Servidor é o modelo de arquitetura mais citado quando se discutem sistemas distribuídos, sendo historicamente a mais importante e amplamente empregada atualmente. Todos os demais modelos de arquitetura derivam ou variam a partir deste modelo fundamental.

RESUMO DO TÓPICO 2

143

AUTOATIVIDADE

1 Faça uma ilustração da arquitetura cliente-servidor contendo um ou mais servidores de aplicativos de internet (por exemplo, correio eletrônico ou proxy).

2 Para os aplicativos citados no exercício 1, explique como os servidores cooperam no fornecimento de seus serviços.

3 Cite quais são os recursos locais que podem ser vulneráveis a um ataque de um programa não confiável, cujo download foi feito a partir de um site remoto, sendo o mesmo executado localmente no computador do usuário.

4 Usualmente, computadores utilizados em sistemas peer-to-peer são computadores desktop domésticos ou de escritórios dos usuários. Quais são as implicações disso referindo-se à disponibilidade e segurança dos objetos de dados compartilhados contidos nos mesmos?

5 Cite três exemplos de aplicações em que o uso de código móvel seja vantajoso.

145

TÓPICO 3

COMUNICAÇÃO EM UM AMBIENTE DE

COMPUTAÇÃO DISTRIBUÍDA

UNIDADE 3

1 INTRODUÇÃODe acordo com Riccioni (2000, p. 19), “um ambiente de computação

distribuída é mais do que um simples recurso de computação”. Oferece grande faixa de recursos computacionais para a aplicação, independente da localização do usuário, do tipo de aplicação ou dos recursos computacionais requeridos. Esses recursos permitem que as aplicações ofereçam aos usuários melhor desempenho e uso mais eficiente dos serviços computacionais do sistema.

Neste tópico serão apresentadas as características da comunicação entre processos, contextualizando sockets e discutindo os protocolos UDP e TCP. Iniciaremos nossos estudos entendendo a questão das interfaces de programa aplicativo dos protocolos UDP e TCP.

2 PROTOCOLOSA API (Application Program Interface – Interface de Programa Aplicativo)

para o protocolo UDP fornece uma abstração de passagem de mensagem, ou seja, a forma mais simples de comunicação entre processos. “Este protocolo permite que um processo remetente transmita uma única mensagem para um processo destino. Os pacotes independentes contendo estas mensagens são chamados de datagramas. Na API do UNIX, o processo remetente especifica o destino utilizando um socket, ou seja, uma referência indireta para uma porta específica utilizada pelo processo de destino da mensagem”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 126).

A API para o protocolo TCP fornece a abstração de um fluxo (stream) bidirecional entre pares de processos. A informação transmitida consiste em um fluxo contínuo de dados sem dar a noção de limites de mensagem, ou seja, que ela tem um início e um término. Os fluxos fornecem uma base para a comunicação denominada produtor-consumidor. Neste contexto, um produtor e um consumidor formam um par de processos no qual a função do primeiro é produzir itens de dados e do segundo é consumi-los. Os itens de dados enviados pelo produtor para o consumidor são armazenados de forma enfileirada na chegada até que o consumidor esteja pronto para recebê-los. Quando nenhum item de dados estiver disponível, o consumidor deve aguardar. Caso o espaço de armazenamento usado para manter os itens de dados enfileirados esteja saturado, o produtor deve aguardar (COULOURIS; DOLLIMORE; KINDBERG, 2007).


146

2.1 CARACTERÍSTICAS DA COMUNICAÇÃO ENTRE PROCESSOS

A passagem de mensagens entre um par de processos pode ser realizada por duas operações de comunicação de mensagem denominadas send (envio) e receive (recebimento), definidas em termos de destinos e mensagens. Para que um processo se comunique com outro, um deles deve enviar (send) uma mensagem ou uma sequência de conteúdos (bytes) para um destino e o processo no destino deve receber (receive) a mensagem. Esta atividade envolve a comunicação de dados do processo remetente para o processo destino e pode implicar na sincronização dos dois processos. Uma fila de conteúdo é associada a cada destino de mensagem. “Os processos remetentes fazem as mensagens serem adicionadas em filas remotas e os processos destino removem mensagens de suas filas locais”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 127).

“Para que haja a comunicação entre dois processos, um deles deve enviar uma mensagem ou uma sequência de conteúdos para um destino e o outro processo deve receber esta mensagem”. (GROSS, 2008, p. 104).

IMPORTANTE

A comunicação entre os processos remetente e destino pode ser síncrona ou assíncrona. Na forma síncrona de comunicação, os processos remetente e destino são sincronizados a cada mensagem enviada. Neste caso, envio (send) e recebimento (receive) são operações que causam bloqueio. Quando um envio (send) é feito, o processo (também identificado como thread) remetente é bloqueado até que a recepção (receive) correspondente seja realizada. Quando uma recepção é executada, o processo é bloqueado enquanto a mensagem não chegar. O termo bloqueado se refere ao fato do processo aguardar o término do recebimento da mensagem. Na forma assíncrona de comunicação, o uso da operação envio (send) é dita não bloqueante, no sentido de que o processo remetente pode prosseguir assim que a mensagem tenha sido copiada para um pulmão (buffer) local, e a transmissão da mensagem ocorre em paralelo com o processo remetente. A operação de recepção (receive) pode ter variantes com e sem bloqueio. Na variante não bloqueante, o processo destino prossegue sua execução após ter realizado a operação de recepção, a qual fornece um buffer para ser preenchido em segundo plano (background). Nesse caso o processo deve receber separadamente uma notificação de que seu buffer possui conteúdos a serem lidos.

FONTE: Coulouris; Dollimore; Kindberg (2007, p. 128).

TÓPICO 3 | COMUNICAÇÃO EM UM AMBIENTE DE COMPUTAÇÃO DISTRIBUÍDA

147

Nos protocolos internet, as mensagens são enviadas para destinos identificados pelo par endereço IP e porta local. Uma porta local é um destino de mensagem dentro de um computador. Uma porta é referenciada por um número inteiro. Uma porta tem exatamente um destino (exceções são as portas multicast), mas pode ter vários remetentes.

Os processos podem utilizar várias portas para receber mensagens. Qualquer processo que possua o número de uma porta pode enviar uma mensagem para ela. Geralmente os servidores divulgam seus números de portas para os clientes acessarem. Se o cliente utiliza um endereço IP fixo para fazer referência a um serviço, esse serviço sempre deve ser executado no mesmo computador para que seu endereço permaneça válido. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 128).

Para proporcionar transparência de localização, pode-se utilizar um servidor de nomes que transforma os nomes nos endereços no momento da execução. Esta estratégia elimina a necessidade de utilização de um endereço fixo e rígido, e eliminação da rigidez permite que os serviços sejam movidos enquanto o sistema está em execução. Outra estratégia é trabalhar com identificadores independentes da localização para os destinos de mensagens, mapeando-os em um endereço de nível mais baixo para que as mensagens sejam entregues nas portas. Esta estratégia possibilita a migração e a movimentação do serviço de uma máquina para outra. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 128).

Uma alternativa à utilização de portas é o fato de que as mensagens devem ser endereçadas para processos. Entretanto, as portas têm a vantagem de fornecer vários pontos alternativos de entrada para um processo de destino. Em algumas aplicações, é muito útil poder distribuir a mesma mensagem para os membros de um conjunto de processos. Portanto, alguns mecanismos de IPC (InterProcess Communication) têm a capacidade de enviar mensagens para grupos de destinos, sejam eles processos ou portas (COULOURIS; DOLLIMORE; KINDBERG, 2007).

“Uma das principais formas de obtenção de transparência de localização é através da utilização de um servidor de nomes que converta o nome do destino em seu endereço atual.” (GROSS, 2008, p. 105).

IMPORTANTE


148

No que diz respeito à propriedade da validade, um serviço de mensagem ponto a ponto pode ser descrito como confiável se houver garantia que as mensagens forem entregues, independente do fato de uma quantidade de pacotes poderem ser eliminados ou perdidos. Em contraste, um serviço de mensagem ponto a ponto pode ser descrito como não confiável se não houver garantia de que as mensagens sejam entregues. Quanto à integridade, na chegada, as mensagens não devem estar corrompidas e também não devem ser duplicadas. Algumas aplicações exigem que as mensagens sejam entregues na ordem em que foram enviadas, ou seja, na ordem em que foram transmitidas pelo remetente. Aplicações que funcionam desta forma consideram a entrega da mensagem fora da ordem do remetente como uma falha (COULOURIS; DOLLIMORE; KINDBERG, 2007).

2.2 SOCKETS

A maioria dos computadores conectados à internet utiliza o protocolo TCP/IP para a comunicação. Um socket é uma abstração que representa um ponto de conexão para uma rede TCP/IP. No momento em que dois computadores se comunicam, cada um deles utiliza um socket para o estabelecimento da comunicação. Neste tipo de comunicação um dos computadores faz o papel de servidor que abre um socket e monitora a existência de requisições de conexão. Neste contexto, outro computador denominado cliente, faz uma requisição ao socket do servidor para iniciar uma conexão. Para que a conexão possa ser estabelecida, é necessário que haja pelo menos um endereço de destino e um número de porta de comunicação para ser utilizado (HOPSON; INGRAM, 1997).

Quando um aplicativo interage com o software de protocolo, ele deve especificar se é um cliente ou um servidor, ou seja, se ele iniciará ativamente a comunicação ou esperará passivamente pela comunicação (COMER, 2001).

IMPORTANTE

Em uma rede baseada no protocolo TCP/IP cada computador possui um endereço exclusivo e as portas representam conexões individuais dentro desse endereço. Cada porta de um computador compartilha o mesmo endereço, mas os conteúdos são roteados (direcionados) dentro de cada computador pelo número da porta. Quando um socket é criado, ele tem de estar associado a uma porta específica. Este processo de associação de um socket com uma porta é conhecido como acoplamento a uma porta (HOPSON; INGRAM, 1997).


149

A interface utilizada por um aplicativo na interação com o software de protocolos de transporte é conhecida como API (Application Program Interface – Interface de Programa Aplicativo). Uma API define um conjunto de operações que um aplicativo pode executar quando interage com um software de protocolo. Desta forma, a API determina a funcionalidade que está disponível a um aplicativo e também a dificuldade de se criar um programa para utilizar aquela funcionalidade. A origem da API de socket se deu como parte do sistema operacional BSD UNIX. O trabalho foi financiado pelo governo americano e a realização foi da Universidade de Berkeley que desenvolveu e distribuiu uma versão de UNIX que continha protocolos de ligação inter-redes baseado no protocolo TCP/IP. Muitos fabricantes de computadores portaram o sistema BSD para seus equipamentos e o utilizaram como base em seus sistemas operacionais comerciais. Desta forma a API de sockets se tornou um padrão reconhecido na indústria (COMER, 2001).

Os sockets utilizam como principais modos de operação o modo baseado em conexões e o modo sem conexão. Os sockets baseados no modo de operação com conexões funcionam de maneira similar a um telefone, que precisa estabelecer uma conexão e suspender a ligação. Todos os dados que fluem entre os dois eventos chegam na mesma ordem em que foram transmitidos. Já os sockets sem conexão funcionam de maneira similar ao correio no qual a entrega não é garantida e os diferentes itens da correspondência podem chegar a uma ordem diferente daquela em que foram enviados (HOPSON; INGRAM, 1997).

O modo a ser utilizado para a comunicação deve ser determinado pelo aplicativo que fará uso do socket. Caso a confiabilidade seja um requisito primordial, então a operação baseada em conexões é a melhor opção a ser escolhida. Os servidores de arquivos precisam fazer todos os seus dados chegarem com integridade e na sequência necessária. Se houver a perda de alguma parte dos dados, a utilidade do servidor seria inviabilizada. Quando houver necessidade de confiabilidade, é necessário estar ciente de que ela tem um custo. Garantir a sequência e a correção dos dados exige processamento extra e utilização de mais memória. Esse processamento extra ou overhead adicional pode reduzir os tempos de resposta de um servidor (HOPSON; INGRAM, 1997).

As operações sem conexão utilizam o protocolo UDP (User Datagram Protocol). Um datagrama é uma unidade autônoma que tem todas as informações necessárias para a realização da entrega dos conteúdos. Um datagrama pode ser análogo a um envelope que tem o endereço do destinatário e do remetente, e que contêm em seu interior os conteúdos (dados) a serem enviados. Um socket nesse modo de operação não precisa se conectar a um socket de destino, pois ele simplesmente envia o datagrama. O protocolo UDP realiza o melhor esforço possível para realizar a entregar do datagrama. A operação sem conexão é rápida e eficiente, mas não possui garantia de entrega do conteúdo (HOPSON; INGRAM, 1997).


150

“Sockets utilizam a abordagem abertura, leitura, escrita e fechamento (open-read-write-close) que é derivada da abordagem básica para entrada e saída do UNIX”. (GROSS, 2008, p. 107).

IMPORTANTE

A operação baseada em conexão utiliza o protocolo TCP (Transport Control Protocol). Um socket nesse modo de operação precisa se conectar ao destino antes de transmitir o conteúdo. Uma vez conectados, os sockets são acessados pelo uso de uma interface de fluxos através da sequência abertura, leitura, escrita e fechamento (open-read-write-close).

Tudo que é enviado por um socket é recebido pela outra extremidade da conexão, exatamente na mesma ordem em que foi transmitido na origem. A operação baseada em conexão é menos eficiente em termos de velocidade do que a operação sem conexão, mas possibilita a garantia de entrega do conteúdo (HOPSON; INGRAM, 1997).

Pelo fato dos sockets terem sido originalmente desenvolvidos como parte do sistema operacional UNIX, eles empregam muitos conceitos encontrados em outras partes do sistema UNIX. Os sockets possuem proximidade com as operações de entrada e saída (E/S). Uma aplicação se comunica com outras aplicações e dispositivos através de uma rotina similar ao socket que forma um caminho para a aplicação transferir dados para um dispositivo. Deste modo, compreender sockets requer também o entendimento das facilidades das operações de entrada e saída do UNIX.

O Sistema Operacional UNIX utiliza a sequência de abertura, leitura, escrita e fechamento para todas as operações de entrada e saída realizadas. Esta abordagem é derivada das operações de entrada e saída básicas, que são aplicadas tanto para dispositivos quanto para arquivos. Quando uma aplicação abre um arquivo ou dispositivo, a chamada de abertura (open) retorna um código de controle denominado descritor, que é um valor inteiro que identifica o arquivo. O aplicativo deve especificar o descritor ao solicitar transferência de dados, ou seja, o descritor é um argumento para o procedimento de leitura (read) ou escrita (write). Ao encerrar as atividades realizadas com o arquivo, deve ser efetuada uma chamada de fechamento (close) para indicar que a operação com o arquivo foi concluída (COMER, 2001).

2.3 COMUNICAÇÃO UDP

O protocolo UDP (User Datagram Protocol) foi definido para ser utilizado por aplicações que não necessitam trafegar um volume muito alto de dados na internet. Alguns protocolos definidos no nível de aplicação da arquitetura internet


151

estão baseados neste protocolo. Exemplos de utilização são os protocolos SNMP, BOOTP e o TFTP. Os protocolos UDP e TCP compõem o par de protocolos do nível de transporte da arquitetura Internet (MAZZOLA, 2002).

“O protocolo UDP possui como característica a introdução de baixa sobrecarga (overhead) para transmissão na rede”. (GROSS, 2008, p. 108).

IMPORTANTE

O protocolo UDP é muito mais simples e menos confiável que o protocolo TCP, mas apresenta como vantagem a introdução de um pequeno overhead ou sobrecarga para a rede. O UDP não faz uso de acknowledgements, janela deslizante e não utiliza nenhum mecanismo de sequenciamento. Desta forma, é considerado um protocolo com as mesmas características do IP em termos de qualidade em relação ao serviço oferecido. O único mecanismo importante utilizado pelo UDP é o controle de erros, realizado com o auxílio de um algoritmo de checksum que abrange o conteúdo transportado, ou seja, o cabeçalho e os dados (MAZZOLA, 2002).

Embora o protocolo UDP seja simples e leve, pelo fato de utilizar a comunicação por datagrama, pode apresentar alguns problemas relacionados à comunicação. Um dos problemas está relacionado ao tamanho das mensagens transmitidas, pois o processo destino precisa especificar um vetor de bytes de um tamanho em particular para receber as mensagens. Se a mensagem for grande demais para a capacidade desse vetor, ela estará incompleta na chegada. O bloqueio é outro problema, pois normalmente os sockets fornecem operações de envio (send) não bloqueantes e recebimento (receive) bloqueantes para comunicação por datagrama. A utilização de um receive não bloqueante é uma opção possível para utilização em determinadas aplicações. Em relação a timeouts (encerramento do processo por limite de tempo) a recepção bloqueante é conveniente para uso por um servidor que esteja esperando para receber as requisições de clientes. Mas em algumas situações, não é adequado que um processo espere indefinidamente para receber algo, pois o processo remetente pode ter falhado ou a mensagem esperada ter sido perdida na transmissão. Para atender a tais requisitos, limites temporais (timeouts) podem ser configurados nos sockets para tornar a comunicação adequada.

FONTE: Coulouris; Dollimore; Kindberg (2007, p. 129-130)


152

“Uma das propriedades fundamentais em canais de comunicação é a integridade. A integridade exige que as mensagens não estejam corrompidas nem duplicadas”. (GROSS, 2008, p. 109).

IMPORTANTE

O protocolo UDP tem funcionamento extremamente simples. Esta simplicidade explica o baixo overhead (sobrecarga) provocado pela sua utilização. A função básica do UDP é proporcionar um controle de canais virtuais entre as aplicações Internet, realizando a multiplexação na transmissão e reconversão (demultiplexação) na recepção. O controle é feito a partir da alocação de portas para cada aplicação (MAZZOLA, 2002).

2.4 COMUNICAÇÃO TCP

Na definição do protocolo TCP (Transmission Control Protocol) ele foi integrado com o protocolo IP (Internet Protocol) para oferecer um serviço confiável de comunicação na ARPANET, estando situado na camada internet no nível de transporte. Embora tenha sido definido para a arquitetura Internet, o TCP ou a família TCP/IP, pode ser utilizada em outras arquiteturas dado a sua independência com relação aos níveis adjacentes (MAZZOLA, 2002).

Tamanhos de blocos de dados diferentes podem ser manipulados no contexto das aplicações. Numa aplicação de correio eletrônico, por exemplo, pode ser composta de apenas uma linha ou transportar um arquivo relativamente grande. A diversidade de tamanho do conteúdo a ser transmitido deve ser gerenciada pelo protocolo TCP. O tratamento dos diferentes blocos de dados das aplicações é realizado basicamente em duas situações típicas. Primeiro, no caso de blocos de dados muito grandes, o TCP deve fragmentá-los de modo a entregar segmentos de tamanho mais adequado ao protocolo de nível inferior. Segundo, no caso de blocos de dados extremamente pequenos, o procedimento é inverso. O TCP bufferiza estes blocos e os envia em grupos encapsulados num mesmo segmento de nível inferior. Este procedimento permite diminuir o overhead do protocolo no envio de mensagens e otimizar a utilização da rede (MAZZOLA, 2002).

No protocolo TCP é realizada a abstração de fluxo (streaming) a qual possui características de rede que podem parecer ocultas. Algumas destas características são o tamanho da mensagem, mensagens perdidas, controle de fluxo, duplicação e ordenamento de mensagens e destinos de mensagens. Quanto ao tamanho das mensagens, o aplicativo pode escolher o volume de


153

conteúdo (dados) que vai ser enviado ou recebido em um fluxo. Ele pode tratar com conjuntos de dados muito pequenos ou muito grandes. A implementação da camada TCP possui estratégias para determinar o volume de dados a coletar, e transmiti-los efetivamente como um ou mais pacotes IP. Ao chegar, os dados são entregues para o aplicativo, conforme solicitado. Se necessário, os aplicativos podem exigir que os dados sejam enviados imediatamente.

FONTE: Coulouris; Dollimore; Kindberg (2007, p. 126)

No que diz respeito à questão de mensagens perdidas, o protocolo TCP usa uma sistemática de confirmação. Nessa sistemática, se o remetente não receber uma confirmação de recebimento dentro de um tempo limite, ele retransmite a mensagem para o destinatário. O esquema de janela deslizante, que é mais sofisticado, permite reduzir o número de mensagens de confirmação exigidas. Quanto ao controle de fluxo, o protocolo TCP tenta combinar a velocidade dos processos que leem e escrevem em um fluxo. Se o processo que escreve ou envia, for rápido demais para o processo que realiza a leitura, então ele será bloqueado até que o processo leitor tenha consumido dados suficientes.

FONTE: Coulouris; Dollimore; Kindberg (2007, p. 133)

Sobre a duplicação e ordenação de mensagens, os identificadores de mensagens são associados a cada datagrama IP, o que permite ao destinatário detectar e rejeitar duplicatas ou reordenar as mensagens que chegam fora da ordem de emissão. Em relação ao destino das mensagens, dois processos que estão em comunicação estabelecem uma conexão antes de poderem se comunicar por meio de um fluxo. Uma vez estabelecida a conexão, os processos simplesmente leem ou escrevem no fluxo, sem necessidade de usar endereços IP e portas.

“O estabelecimento de uma conexão envolve uma requisição de conexão (connect), do cliente para o servidor, seguido de uma requisição de aceitação (accept) do servidor para o cliente, antes que qualquer comunicação possa ocorrer”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 133).

Em um modelo cliente-servidor, isso causa uma sobrecarga considerável para cada requisição-resposta. Um aspecto importante deste procedimento é a transparência para o usuário, uma vez que os blocos de dados são entregues à aplicação destinatária na forma original. O protocolo TCP realiza também a recomposição ou fragmentação dos blocos de conteúdos transmitidos. Ainda com relação a esta função, o TCP permite que uma aplicação solicite o envio imediato de um bloco pequeno de conteúdos, eventualmente incorporado a outros blocos maiores, sem aguardar a chegada de outros blocos pequenos para armazenamento temporário (buffer) e consequente transmissão (MAZZOLA, 2002).


154

A garantia da integridade dos dados é uma tarefa crucial para o protocolo TCP, considerando que ele não utiliza nenhum mecanismo relacionado a esta tarefa. A fim de realizar eficientemente esta tarefa, é utilizado um algoritmo de detecção de erros denominado checksum, que verifica não apenas a integridade do cabeçalho da mensagem (header), como no caso do IP, mas também dos dados transmitidos.

Com o objetivo de evitar problemas de duplicação de mensagens, que podem ser consequência de um mecanismo de controle de erros pobremente especificado, o TCP gera um número de sequência que permite o controle por parte dos elementos envolvidos na comunicação, ou seja, o remetente e o destinatário. A confirmação das mensagens também utiliza este sequenciamento (MAZZOLA, 2002).

Quanto ao tipo de diálogo, o TCP permite a realização dos diálogos segundo um esquema de comunicação bidirecional simultâneo. Este esquema de comunicação é conhecido como full-duplex. Neste caso, uma aplicação que termine o envio de dados para outra aplicação pode encerrar sua transmissão, mas continuar a receber dados da outra aplicação até que esta encerre também a sua transmissão (MAZZOLA, 2002).

Em relação ao protocolo de transmissão implementado, o TCP utiliza um protocolo de transmissão denominado janela deslizante (sliding window). Esta abordagem propicia o envio de vários segmentos de dados encapsulados (embutidos) em seus datagramas IP, sem a necessidade de confirmação imediata da recepção do conteúdo. Segundo este protocolo, uma mesma confirmação pode ser utilizada para notificar a chegada de vários destes segmentos, aumentando a eficiência da comunicação (MAZZOLA, 2002).

“O TCP realiza diálogos de forma full-duplex, e realiza a transmissão com a abordagem conhecida como janela deslizante”. (GROSS, 2008, p. 111).

IMPORTANTE

Pelo fato do protocolo utilizado no TCP precisar fornecer um serviço de transporte fim-a-fim para as aplicações, ele executa um mecanismo baseado no estabelecimento simultâneo de vários canais, ou pipes, utilizando a técnica de circuito virtual. Segundo esta técnica, é estabelecido um canal lógico entre as aplicações fonte e destino, através do qual será realizado o diálogo segundo a abordagem full-duplex. Terminada a transmissão, o canal é automaticamente encerrado.


155

Devido à possibilidade de existência de vários destes canais, cada aplicação recebe um número lógico de identificação denominado porta (port). O endereço de uma porta (port) é entregue a uma dada aplicação apenas quando esta vai iniciar um canal. Sendo assim, um endereço de canal virtual TCP corresponde não apenas a um endereço IP, mas deste somado ao número da porta utilizada para o canal virtual (MAZZOLA, 2002).

O protocolo TCP permite a garantia da entrega confiável das mensagens utilizando um mecanismo baseado em reconhecimentos e retransmissões. Qualquer segmento de dados pode ser retransmitido, podendo inclusive conter uma quantidade maior de dados que o segmento original. Por esta razão, as confirmações não devem fazer referência ao datagrama ou ao segmento. A confirmação utilizada no TCP refere-se a uma ordem numérica da linha de transmissão, sendo que o receptor coleta os dados que a fonte enviou. Considerando o fato de que segmentos são encapsulados em datagramas que transmitem por rotas diferentes e podem, por consequência, ser perdidos, duplicados ou chegar com ordem invertida etc. Lembrando que o serviço provido pelo IP não implementa praticamente nenhum mecanismo para prevenir ou corrigir estes problemas, o receptor vai utilizar este número de ordem para reorganizar, e confirmá-los de modo positivo ou negativo (MAZZOLA, 2002).

“O TCP garante a entrega confiável das mensagens através do mecanismo de reconhecimentos e retransmissões, e utiliza a abordagem de timeout”. (GROSS, 2008, p. 112).

IMPORTANTE

A cada transmissão do protocolo TCP, um contador inicia um processo de contagem como forma de executar um mecanismo de temporização (timeout) que estará associado à recepção da confirmação. Este contador somente será reiniciado no instante da chegada de uma confirmação, antes que o limite de contagem de tempo tenha sido atingido. Caso contrário, quando o contador atingir o seu limite, o segmento será retransmitido.

A grande questão associada ao uso deste mecanismo é o estabelecimento do limite de espera pelo recebimento da confirmação. Principalmente em redes interconectadas, onde o datagrama pode percorrer diversas redes, com diferentes velocidades, até chegar ao seu destino. Ainda, considerando que cada datagrama pode seguir por trajetórias diferentes, o problema torna-se ainda mais complexo. Para resolver este impasse, o TCP utiliza um algoritmo eficiente que calcula automaticamente o timeout de retransmissão, adequando-se, inclusive, a eventuais alterações nas condições de tráfego da rede (MAZZOLA, 2002).


156

3 COMUNICAÇÃO CLIENTE-SERVIDORO modelo cliente/servidor surgiu, de forma relativamente conveniente, da

convergência entre computadores e comunicações, da disponibilidade de estações de trabalho poderosas, contando com interfaces GUI (Graphical User Interface) e sistemas de multimídia para apresentações. Por aproximar a computação dos usuários finais e de seus negócios, provendo mais flexibilidade e facilidades de uso, os sistemas cliente/servidor se propõem a aumentar a produtividade, a satisfação dos clientes, e reduzir, de maneira significativa, os custos envolvidos com manutenção/atualização dos sistemas, infraestrutura e treinamento (FREITAS FILHO, 2002).

Uma classe especialmente importante dos sistemas cliente/servidor é a WWW (World Wide Web). Observa-se que à medida em crescem o interesse e as aplicações voltadas para a web e para sistemas cliente/servidor distribuídos, mais importantes se tornam as considerações referentes à questão do desempenho das comunicações (FREITAS FILHO, 2002).

3.1 O PARADIGMA CLIENTE/SERVIDOR

O modelo de computação cliente/servidor é baseado na noção de dividir o trabalho a ser realizado por uma aplicação entre dois processos, ou seja, um processo cliente e um processo servidor. Trata-se de um conceito lógico, pois sua tecnologia implica num modelo, ou paradigma, para a interação entre processos de software em execução concorrente.

Embora os processos cliente e servidor possam coexistir até mesmo numa única máquina, de maneira geral, pode-se dizer que o processo cliente, ou simplesmente cliente (FREITAS FILHO, 2002):

• executa numa estação de trabalho de um usuário, disponibilizando o código da GUI para a captura de dados e visualização;

• realiza requisições para serviços específicos que devem ser realizados por um ou mais processos servidores, usualmente localizados em máquinas remotas;

• executa parte do código da aplicação.

Quanto ao processo servidor pode-se dizer que (FREITAS FILHO, 2002):

• executa em máquinas usualmente mais poderosas que as máquinas dos clientes. Executam sistemas operacionais para multiprogramação, tipo UNIX ou Windows. Possui mais memória RAM e mais área disponível em disco que as estações de trabalho;

• executa um conjunto de serviços funcionalmente relacionados os quais, usualmente, requerem componentes especializados de software e hardware;

• nunca inicia um processo de troca de mensagens com qualquer cliente. Os servidores são entidades passivas que recebem as requisições dos clientes, as executam e respondem a estes.


157

Na prática, temos a maioria dos sistemas cliente/servidor implementados em máquinas distintas conectadas por uma rede. O protocolo implementado entre clientes e servidores é do tipo requisição-resposta, no qual os clientes enviam uma requisição e o servidor responde às requisições. Clientes e servidores podem rodar sobre TCP ou sobre um protocolo não orientado a conexão como o UDP (FREITAS FILHO, 2002).

Pelo fato de um servidor poder receber requisições de vários clientes, uma fila pode ser formada na entrada do mesmo. Se apenas uma requisição é servida por vez, os recursos de máquina do servidor poderão ser subutilizados, o throughput poderá ser baixo e o tempo de resposta aos clientes crescerá na medida do aumento da carga no servidor (FREITAS FILHO, 2002).

“Throughput, segundo a Wikipédia (2012), é a quantidade de dados transferidos de um lugar a outro, ou a quantidade de dados processados em um determinado espaço de tempo.” Disponível em: <http://pt.wikipedia.org/wiki/Throughput>. Acesso em: 15 out. 2012.

DICAS

A maioria dos servidores utiliza múltiplos processos (multithreads) de execução, de forma a lidar com a fila de requisições que chegam dos clientes. O uso de múltiplos processos contribui para a redução do tempo de resposta por requisição. Deve-se observar, no entanto, que na medida em que todos os processos no servidor competem pelos mesmos recursos de hardware (CPU, memória, discos etc.), o ganho no desempenho se reduz quando a utilização de tais recursos beira o limite dos recursos, ou seja, os 100% (FREITAS FILHO, 2002).

3.2 SERVIDORES

Em ambientes de rede são utilizados vários tipos de servidores. Entre os mais conhecidos temos os servidores de arquivos, de bases de dados, de aplicações, de objetos e servidores web. Os servidores de arquivos permitem que os computadores da rede tenham acesso a sistemas de arquivos compartilhados. Os clientes fazem requisições objetivando visualizar diretórios, capturar atributos de arquivos e ler ou escrever blocos de arquivos. Um dos sistemas mais conhecidos é o NFS (Network File System – Sistema de Arquivos de Rede), que permite facilmente o compartilhamento de dados em redes heterogêneas. O protocolo NFS permite que tanto o UDP quanto o TCP possam ser utilizados como protocolo de transporte (FREITAS FILHO, 2002).


158

Os servidores de base de dados permitem o acesso a uma ou mais bases de dados compartilhadas. As requisições dos clientes se dão na forma de comandos SQL (Structured Query Language), uma linguagem padronizada para acesso a banco de dados relacionais. O servidor de base de dados recebe um comando SQL e o repassa ao gerenciador da base de dados. Este realiza ou um questionamento à base na busca de informações ou atualiza as informações nela contidas. Mesmo que o gerenciador tenha que realizar centenas de leituras nos registros da base de dados para satisfazer a necessidade de um cliente, que busca somente alguns destes registros, apenas o resultado da pesquisa é enviado de volta ao cliente. Este procedimento, típico dos sistemas cliente/servidor, reduz significativamente o tráfego na rede e o número de interações entre cliente e servidor. Há uma crença comum de que a tecnologia C/S é sinônima de bancos de dados SQL. Apesar de este ser o uso mais frequente desta tecnologia, é possível a existência de sistemas cliente/servidor que não empregue SQL (FREITAS FILHO, 2002).

Já os servidores de aplicações permitem o acesso a procedimentos remotos executados pelos clientes através do mecanismo conhecido como RPC (Remote Procedure Call ou Chamada de Procedimento Remoto). Ao ativar uma RPC, o cliente deixa de processar (se não possuir mecanismos de não bloqueamento) após emitir um pedido ao servidor, e espera a resposta. O servidor começa a processar o pedido do cliente, terminando de processar após emitir uma resposta (até que chegue outro pedido). Quando o cliente recebe a resposta, ele recomeça seu processamento. O sincronismo entre cliente e servidor está implícito no mecanismo de passagem de mensagem. Estes mecanismos utilizam a lógica da aplicação emitindo comandos SQL a um gerenciador de base de dados. Assim, ao invés da ocorrência de uma interação entre cliente/servidor a cada comando SQL, nesta abordagem o cliente fica resguardado pelo servidor de aplicações, este sim, interagindo com o servidor. Com relação aos servidores web, estes permitem o acesso a documentos, imagens, sons, executáveis e o carregamento de aplicações (tipo Java applets), via protocolo HTTP (FREITAS FILHO, 2002).

3.3 ARQUITETURA DOS SISTEMAS C/S

Um elemento importante da arquitetura dos sistemas cliente/servidor é a definição sobre projetos com dois ou três níveis. Na arquitetura com dois níveis, a GUI e a lógica da aplicação são executadas no cliente, enquanto o SQL roda no servidor SQL. Já na arquitetura com três níveis, a GUI continua sendo executada no cliente, a lógica da aplicação passa a rodar num servidor de aplicações, que atua como cliente de um servidor SQL.

Outra questão importante com relação à arquitetura diz respeito aos tipos de clientes. Neste sentido, denominam-se os clientes como “pesados” ou “leves”. Os clientes pesados incorporam mais da lógica da transação do que clientes considerados leves. Desta forma, realizam menos interações com os servidores, mas em contrapartida, requerem mais poder de processamento (FREITAS FILHO, 2002).


159

As requisições geradas pelos clientes aos servidores, assim como as respostas geradas, fazem uso de largura de banda das redes, processamento junto às CPUs e roteadores, e dos recursos de I/O. Na medida em que a carga de um sistema cresce, o desempenho pode cair rapidamente. Para melhorar o desempenho e aumentar a escalabilidade do sistema, é possível fazer uso de caches em diversos níveis que podem melhorar bastante o desempenho dos sistemas cliente/servidor. Caches são cópias de dados armazenados nos servidores, as quais são mantidas mais próximas dos clientes. Às vezes nos próprios clientes, e às vezes nos chamados servidores de cache (FREITAS FILHO, 2002).

O uso de caches reduz o número de interações necessárias com o servidor, levando a uma redução no tempo de resposta. Clientes podem manter cópias em cache de arquivos ou de blocos de arquivos, de tal forma que não será necessário acessar o servidor a cada necessidade de leitura por exemplo. Pelo lado dos servidores, estes poderão manter caches na memória principal, com redução de I/Os.

Atualmente é comum observarmos, também, servidores de web próximos de clientes mantendo documentos mais populares em cache, evitando a constante necessidade de acesso a sites disponíveis em servidores remotos, com uma grande redução no tempo de resposta e no uso de largura de banda. No entanto, existe um preço a ser pago pelo uso de caches: é necessária a manutenção da consistência dos dados (FREITAS FILHO, 2002).

3.4 SGBD DISTRIBUÍDO

A utilização de sistemas de bancos de dados distribuídos é vantajosa sob diversos aspectos, tais como, o compartilhamento de dados, a autonomia e a disponibilidade. É desejável criar um ambiente no qual os usuários de um site podem ter acesso a dados residentes em outros sites (compartilhamento), a possibilidade de que cada site possa manter certo nível de controle sobre os dados armazenados localmente (autonomia) e a possibilidade de um site continuar em operação a despeito da queda de outro site (disponibilidade). Isto é particularmente interessante se os itens de dados são replicados em diversos sites (BRAGA et al., 2002).

A principal desvantagem dos sistemas distribuídos é o acréscimo de complexidade necessário para assegurar a coordenação entre os sites que ocasionam, entre outros, um maior custo de desenvolvimento de software, maior possibilidade de bugs, um aumento do processamento e overhead. Uma das causas que exigem um maior custo e overhead na implementação de um banco de dados distribuído é o particionamento da rede (BRAGA et al., 2002).

4 OBJETOS DISTRIBUÍDOS E RPC


160

4.1 INTRODUÇÃO

Um dos grandes assuntos relacionados aos sistemas distribuídos está relacionado à questão da comunicação remota entre aplicações. Uma das mais modernas formas de concretização da comunicação distribuída é realizada através de objetos distribuídos. “Objetos distribuídos fazem uso de chamadas remotas para realizarem a comunicação a distância”. (GROSS, 2008, p. 127).

4.2 OBJETOS DISTRIBUÍDOS

Segundo Gross (2008, p. 127), “objetos distribuídos oferecem a possibilidade de múltiplas execuções independentes”. A informação exigida para a execução de um objeto distribuído pode ser decomposta em duas partes: uma parte permanente, que consiste da estrutura dos dados e da sequência de instruções a serem executadas, e uma parte temporária, que consiste de dados e outras informações contextuais que variam a cada execução do objeto distribuído.

Conforme Gross (2008), a parte permanente ou estrutural, uma vez determinada pelo projeto do objeto distribuído, permanece invariante, e as correspondentes estruturas de dados e as instruções são reutilizadas ao longo das diversas execuções. Além disso, podem ser transportadas para outros programas ou sistemas sem exigir alterações.

Ainda de acordo com Gross (2008), a parte temporária ou comportamental é ditada pela interação dos objetos distribuídos e determina, a cada instante, o estado da execução do objeto distribuído. Portanto, a parte temporária é específica de cada interação entre objetos distribuídos e se constitui no diferencial mais importante entre aplicações que usam um mesmo objeto distribuído.

Gross (2008, p. 127-128) cita que as formas de interação entre os objetos distribuídos e, em consequência, as maneiras de combiná-los para formar sistemas, se constituem em um dos mais importantes aspectos do projeto arquitetônico. Típicas interações entre objetos distribuídos são:

• chamadas de procedimentos: consiste na ativação de um objeto distribuído que contém a parte permanente e abriga a parte temporária, fornecendo-lhe as informações temporárias necessárias à sua execução. O objeto distribuído é univocamente identificado por seu nome, estaticamente associado ao ponto de chamada e retorno, e podem ser utilizados parâmetros como parte das informações temporárias;• chamadas de métodos: similar à chamada de procedimentos, mas exige a identificação do objeto sobre o qual o método será executado. A classe de um objeto contém as informações permanentes e a instância guarda a maioria das informações temporárias;• envio de mensagens: é uma forma mais sofisticada de ativar um objeto distribuído com a semântica de processo, visto que pode envolver protocolos de comunicação entre objetos distribuídos remotos, restrições temporais e mecanismos de interações entre objetos distribuídos.


161

Objetos distribuídos, de acordo com Gross (2008, p. 128), representam abstrações de funcionalidades, implementadas em uma linguagem de programação. Em consequência, a estruturação de programas a partir de objetos distribuídos, encontra barreiras como:

• diferenças nas linguagens de programação: Oferecem problemas de interação de objetos distribuídos implementados em distintas linguagens de programação;• diferenças na forma de implementação: A mesma funcionalidade pode ser implementada como um módulo, um processo ou um objeto, exigindo distintas formas de comunicação.

Sob o ponto de vista da arquitetura de software, “os objetos distribuídos podem ser considerados como unidades atômicas, cuja composição e interação devem atender aos aspectos funcionais e não funcionais exigidos pelo sistema”. Um objeto distribuído pode ser responsável pelo completo atendimento de um requisito, ou um requisito pode ser atendido por um grupo de objetos distribuídos, ou ainda, os objetos distribuídos podem atender a mais de um requisito. Além dos objetos distribuídos relacionados com os requisitos de uma aplicação, podem existir objetos distribuídos que não são diretamente relacionados com requisitos da aplicação (GROSS, 2008, p. 128).

Considerando isoladamente alguns destes relacionamentos, segundo Gross (2008, p. 128), é possível identificar problemas similares que ocorrem com certa frequência em diferentes sistemas. Estes problemas comuns podem ter uma solução padrão, em termos de estruturação e forma de interação de objetos distribuídos. A descrição de uma solução padronizada para um problema recorrente de software é conhecida como um padrão de software (software pattern). Padrões de software podem ser classificados como padrões de projeto (design patterns) e padrões de arquitetura (architectural pattern).

O conceito de um padrão de projeto de software é apresentado, de acordo com Gross (2008, p. 128), “como um agrupamento de objetos distribuídos ligados por determinados relacionamentos e as regras que expressam uma ligação entre o contexto, o problema de projeto e sua solução”. Agrupamentos assim caracterizados são considerados módulos de arquitetura de software.

Conforme Gross (2008, p. 129), a utilização de objetos distribuídos padronizados parte do princípio que conjuntos de objetos distribuídos podem ser usados como subconjuntos de objetos distribuídos de arquiteturas em diferentes produtos de software. A adoção de um padrão de projeto não influencia na estrutura fundamental de um sistema, mas pode ter grande influência em seus subsistemas. Modelos formam a base conceitual de diferentes arquiteturas de software, e podem ser agrupados em cinco categorias:


162

• modelos estruturais: esta família de modelos considera os aspectos de estrutura de uma arquitetura, com base em objetos distribuídos e conectores. É o modelo mais comum de arquitetura, geralmente baseada em decomposição de objetos distribuídos;• modelos de framework: geralmente se concentram em estruturas específicas, que atendem a classes de problemas e domínios específicos. Exemplos incluem as arquiteturas de domínio específico, CORBA e protocolos de meta-objetos – MOPs;• modelos dinâmicos: preocupam-se com as propriedades comportamentais de sistemas, a exemplo de sistemas reativos, aspectos de reconfiguração e evolução;• modelos de processos: arquiteturas são obtidas segundo um script que determina a sequência de etapas de construção, denominadas de processos de software;• modelos funcionais: se concentram em arquiteturas obtidas a partir de um conjunto de objetos distribuídos funcionais, organizados em camadas que prestam serviços aos objetos distribuídos localizados nas camadas superiores.

De acordo com Gross (2008), os modelos de arquitetura podem originar diversos estilos ou padrões de arquitetura: estilo hierárquico, fluxo de dados, cliente/servidor, reflexiva, entre outros. Os estilos de arquitetura se distinguem pelos aspectos estruturais de seus objetos distribuídos e a semântica das interações entre eles. A seleção de um estilo é orientada pelas propriedades gerais da aplicação, incluindo exigências de adaptabilidade e confiabilidade.

4.3 CHAMADAS REMOTAS DE PROCEDIMENTOS

O uso intensivo de estações de trabalho, computadores pessoais e servidores especializados interconectados através de redes locais ou de longa distância têm criado uma demanda para as aplicações distribuídas. Porém, para construir aplicações distribuídas, os desenvolvedores necessitam de um paradigma de programação de fácil uso e que permita obter vantagens da arquitetura de computação distribuída. Este paradigma é o RPC (Remote Procedure Call) ou Chamada Remota de Procedimentos (FERREIRA; KOCHANSKI; SCHROEDER, 2002).

Usando a tecnologia RPC e seguindo o modelo cliente/servidor, desenvolvedores podem facilmente criar aplicações distribuídas para uso em ambientes de computação heterogêneos. O mecanismo RPC particiona as várias tarefas requeridas por uma aplicação em vários procedimentos que podem ser executados em diferentes servidores. Esta tecnologia oferece vários benefícios: o modelo de programação de fácil uso, o balanceamento, o uso distribuído dos recursos computacionais, alta disponibilidade dos serviços através da replicação e a habilidade das aplicações em executar em diversas plataformas de hardware e de software (FERREIRA; KOCHANSKI; SCHROEDER, 2002).


163

O paradigma RPC implementa o modelo de chamada de procedimento tradicional dentro da arquitetura cliente/servidor. Ele esconde do programador várias complexidades de redes como o conhecimento da localização e acesso aos hosts, nos quais os serviços requeridos estão executando. Como resultado, o RPC é uma ferramenta de propósito geral que pode ser usada universalmente, para aplicações nos mais diversos campos como serviços de escritórios, automação industrial, sistemas de arquivos distribuídos, e outros (FERREIRA; KOCHANSKI; SCHROEDER, 2002).

4.4 ARQUITETURA OSF RPC

Em um sistema orientado a objetos, todos os recursos numa rede são caracterizados como objetos. Objetos são organizados em tipos de objetos e são manipulados através de operações bem definidas (procedimentos). Uma interface é um conjunto de operações relacionadas. Cada tipo de objeto tem uma ou mais interfaces associadas a ele. Todos os acessos a um objeto particular são feitos através das operações definidas nas interfaces associadas com seus tipos de objetos. A abordagem OSF (Open Software Foundation) RPC possibilita a definição e construção de aplicações distribuídas de forma orientada a objetos. Procedimentos remotos são vistos como operações em objetos (impressora, arquivos, etc.) ao invés de chamadas às máquinas ou servidores de processos. Esta abordagem para solução de problemas possibilita engenheiros de software a criarem programas que são independentes de configuração de hardware assim como nomes e localizações de hosts (FERREIRA; KOCHANSKI; SCHROEDER, 2002).

O OSF RPC utiliza o NIDL (Network Interface Definition Language) para a especificação das interfaces RPC. O NIDL consiste de uma simplificação da sintaxe e semântica da linguagem C padrão ANSI, com construções adicionais para atender às exigências da interface RPC. Uma definição de interface descreve as constantes, tipos, operações e parâmetros para uma interface. Em resumo, uma definição de interface especifica a interface entre um cliente de um serviço e o provedor do serviço. Isto define como um cliente ”vê” um serviço remoto e como um servidor “vê” as requisições dos serviços por ele providos. Note que NIDL é estritamente uma linguagem declarativa; ela não contém algoritmo, nem construções executáveis (if-then-else, laços, cálculos etc.) (FERREIRA; KOCHANSKI; SCHROEDER, 2002).

Um compilador NIDL recebe uma definição de interface escrita em NIDL como entrada e gera código fonte em C portável para o módulo cliente e servidores de stub, os quais são integrados com as aplicações cliente e servidor respectivamente. Os stubs produzidos pelo compilador NIDL manipulam e escondem todo o “distanciamento” numa aplicação distribuída. Ele representa dados codificados / decodificados e empacotamento / desempacotamento, e interage com o sistema de execução do RPC. A gramática do NIDL consiste de um rico conjunto de produção de regras. Seria muito tedioso cobrir o assunto em detalhes. Em substituição serão sumarizadas as principais funcionalidades exigidas para uso do OSI RPC (FERREIRA; KOCHANSKI; SCHROEDER, 2002):


164

• suportar a construção de chamadas de procedimentos locais das linguagens de programação ISO. NIDL permite utilizar várias linguagens de programação ISO utilizando diretivas de compilação NIDL;

• ACF (Attribute Configuration Facility) permite a um usuário RPC especificar atributos específicos para o cliente ou servidor RPC, que estão separados pelo contrato de rede. Exemplos são políticas de conexão, opções de geração de código etc.;

• suportar todos os atributos de parâmetros e tipos de dados necessários. Além disso, a NIDL permite declarar constantes, tipos customizados (como ‘typedef’ em C), e tipos pré-definidos como status de erros. Declarações de tipos em uma interface podem ser exportadas ou importadas de outras interfaces;

• a NIDL suporta ponteiros tipados e permite total transparência em chamadas remotas, suportando valor de ponteiro NULL, mudança do valor do ponteiro do outro lado de uma chamada remota, e pseudônimos;

• suporta todas as definições de agregação de dados, especialmente registros com campos que devem ser ignorados pelo processo de empacotamento. A NIDL também permite que parâmetros sejam ignorados;

• suporta configurações de caracteres internacionais.

A NIDL também suporta muitas outras funcionalidades de valor agregado além do que é exigido pelo OSI RPC. Um exemplo notável é o tipo de dado ‘pipe’. O pipe possibilita a transferência de grandes quantidades de dados tipados em um bloco, usando dois comandos de callback (pull e push). O pipe está se mostrando bastante útil na transferência de grandes volumes de dados entre arquivos e no envio de dados de tamanho irrestrito entre um produtor open-ended e um receptor (FERREIRA; KOCHANSKI; SCHROEDER, 2002).

5 FALHAS DE COMUNICAÇÃOEm um sistema distribuído, tanto os processos como os canais de comunicação

podem falhar – isto é, eles podem divergir do que é considerado um comportamento correto ou desejável. O modelo de falhas, de Coulouris, Dollimore e Kindberg (2007, p. 59), define “como uma falha pode se manifestar em um sistema de forma a proporcionar um entendimento dos seus efeitos e consequências, apresentado sob os títulos falhas por omissão, falhas arbitrárias e falhas de sincronização”.

5.1 FALHAS POR OMISSÃO

As falhas classificadas como falhas por omissão se referem aos casos em que um processo ou canal de comunicação deixa de executar as ações que deveria.


165

5.1.1 Falhas por omissão de processo

A principal falha por omissão de um processo é quando ele entra em colapso, parando e não executando outro passo de seu programa. Popularmente, isso é conhecido como “dar pau” ou “pendurar”. O projeto de serviços que podem sobreviver na presença de falhas pode ser simplificado, caso se possa supor que os serviços dos quais dependem colapsam de modo limpo, isto é, ou os processos funcionam corretamente ou param (COULOURIS; DOLLIMORE; KINDBERG, 2007).

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 60),

(...) outros processos podem detectar essa falha pelo fato do processo deixar repetidamente de responder às mensagens de invocação. Entretanto, esse método de detecção de falhas é baseado no uso de timeouts – ou seja, considera a existência de um tempo limite para que uma determinada ação ocorra. Em um sistema assíncrono, a ocorrência de um timeout indica apenas que um processo não está respondendo – porém ele pode ter entrado em colapso, estar lento, ou ainda, as mensagens podem não ter chegado.

O colapso de um processo, segundo Coulouris, Dollimore e Kindberg (2007, p. 60-61) “é chamado de parada por falha se outros processos puderem detectar, com certeza, a ocorrência dessa situação”. Em um sistema síncrono, uma parada por falha ocorre quando timeouts são usados para determinar que certos processos deixassem de responder a mensagens sabidamente entregues. Por exemplo, se os processos P e Q estiverem programados para Q responder a uma mensagem de P, se o processo P não receber nenhuma resposta do processo Q dentro de um tempo máximo (timeout), medido no relógio local de P, então o processo P poderá concluir que o processo Q falhou.

5.1.2 Falhas por omissão na comunicação

Considere as primitivas de comunicação send e receive. Um processo P realiza um send inserindo a mensagem M em sem buffer de envio. O canal de comunicação transporta M para o buffer de recepção Q. O processo Q realiza uma operação receive recuperando M de seu buffer de recepção, conforme ilustra a figura a seguir. Normalmente, os buffers de envio e de recepção são fornecidos pelo sistema operacional.


166

FIGURA 55 – PROCESSOS E CANAIS DE COMUNICAÇÃO

FONTE: Adaptado de COULOURIS, G.; DOLLIMORE, J.; KINDBERG, T. Distributed systems: concepts and design. 3. ed. England: Addison Wesley, 2001, p. 55.

O canal de comunicação produz uma falha por omissão, segundo Coulouris, Dollimore e Kindberg (2007), quando não concretiza a transferência de uma mensagem M do buffer de transmissão de P para o buffer de recepção de Q. Isso é conhecido como “perda de mensagens” e geralmente é causado pela falta de espaço no buffer de recepção, ou pela mensagem ser descartada ao ser detectado que houve um erro durante sua transmissão (isso é feito através de soma de verificação sobre os dados que compõem a mensagem, como por exemplo, cálculo de CRC).

A perda de mensagens entre o processo remetente e o buffer de envio é também referenciada como falha por omissão de envio; a perda de mensagens entre o buffer de recepção e o processo destino é também conhecida como falha por omissão de recepção; e a perda de mensagens no meio de comunicação é também chamada de falha por omissão de canal. No quadro a seguir, veja que as falhas por omissão estão classificadas junto com as falhas arbitrárias.

5.2 FALHAS ARBITRÁRIAS

Também conhecido como bizantina, “o termo falha arbitrária é usado para descrever a pior semântica de falha possível na qual qualquer tipo de erro pode ocorrer. Por exemplo, um processo pode atribuir valores incorretos a seus dados ou retornar um valor errado em resposta a uma invocação”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 61).

Uma falha arbitrária de um processo, de acordo com Coulouris, Dollimore e Kindberg (2007, p. 61) “é aquela em que ele omite arbitrariamente passos desejados do processamento ou efetua processamento indesejado”. Portanto, as falhas arbitrárias não podem ser detectadas verificando-se se o processo responde às invocações, pois ele poderia omitir arbitrariamente a resposta.

Conforme Coulouris, Dollimore e Kindberg (2007), os canais de comunicação podem sofrer falhas arbitrárias; por exemplo, o conteúdo da mensagem pode ser corrompido, mensagens inexistentes podem ser enviadas ou mensagens reais podem ser entregues mais de uma vez.


167

QUADRO 1 – FALHAS POR OMISSÃO E ARBITRÁRIAS

Classe Impacto Descrição

Parada por Falha Processo O processo para e permanece parado. Outros processos devem detectar este estado.

Colapso Processo O processo para e permanece parado. Outros processos podem não ser aptos a detectar este estado.

Omissão Canal Uma mensagem inserida em um buffer de mensagens enviadas nunca chega ao buffer de recepção do receptor.

Omissão de envio Processo Um processo completa o envio, mas a mensagem não é inclusa no buffer de transmissão.

Omissão de recepção Processo A mensagem é colocada no buffer de entrada de mensagens, mas o processo não a recebe.

Arbitrária (Bizantina) Processo ou Canal

Processos/canais exibem procedimentos arbitrários: podem enviar/transmitir mensagens arbitrárias em tempos arbitrários; um processo pode parar ou executar algo incorretamente.


As falhas arbitrárias dos canais de comunicação são raras, segundo Coulouris, Dollimore e Kindberg (2007, p. 61), “pois o software de comunicação é capaz de reconhecê-las e rejeitar as mensagens com problemas”. Por exemplo, somas de verificação são usadas para detectar mensagens corrompidas e números de sequência de mensagens podem ser usados para detectar mensagens inexistentes ou duplicadas.

5.3 FALHAS DE SINCRONIZAÇÃO

As falhas de sincronização são aplicáveis aos sistemas distribuídos síncronos, onde limites de tempo são estabelecidos para o tempo de execução do processo, para o tempo de entrega de mensagens e para a taxa de desvio do relógio. As falhas de sincronização estão listadas no quadro a seguir. Qualquer uma dessas falhas pode resultar em indisponibilidade de respostas para os clientes dentro de um intervalo de tempo predeterminado (COULOURIS; DOLLIMORE; KINDBERG, 2007).

QUADRO 2 – FALHAS DE SINCRONIZAÇÃO

Classe da falha Afeta Descrição

Relógio Processo O relógio local do processo ultrapassa os limites de sua taxa de desvio em relação ao tempo físico.

Desempenho Processo O processo ultrapassa os limites do intervalo de tempo entre duas etapas

Desempenho Canal A transmissão de uma mensagem demora mais do que o limite definido

FONTE: Adaptado de: COULOURIS, G.; DOLLaIMORE, J.; KINDBERG, T. Distributed systems: concepts and design. 2. ed. England: Addison Wesley, 2001, p. 57.


168

De acordo com Coulouris, Dollimore e Kindberg (2007), em um sistema distribuído assíncrono, um servidor sobrecarregado pode responder muito lentamente, mas não podemos dizer que ele apresenta uma falha de sincronização, pois nenhuma garantia foi oferecida.

“Os sistemas operacionais de tempo real são projetados visando ao fornecimento de garantias de sincronização”, conforme Coulouris, Dollimore e Kindberg (2007, p. 62), mas seu projeto é mais complexo e pode exigir hardware redundante. A maioria dos sistemas operacionais de propósito geral, como o UNIX, não precisa satisfazer restrições de tempo real.

Segundo Coulouris, Dollimore e Kindberg (2007, p. 62), “a sincronização é particularmente relevante para aplicações multimídia, com canais de áudio e vídeo”. As informações de vídeo podem exigir a transferência de um volume de dados muito grande. Distribuir tais informações sem falhas de temporização pode impor exigências muito especiais sobre o sistema operacional e sobre o sistema de comunicação.

5.4 MASCARAMENTO DE FALHAS

Cada componente em um sistema distribuído, de acordo com Coulouris, Dollimore e Kindberg (2007, p. 62), geralmente “é construído a partir de um conjunto de outros componentes”. É possível construir serviços confiáveis a partir de componentes que exibem falhas. Por exemplo, vários servidores que contêm réplicas dos dados podem continuar a fornecer um serviço quando um deles apresenta um defeito.

O conhecimento das características de uma falha de um determinado componente pode permitir que um novo serviço fosse projetado de forma a mascarar a falha dos componentes dos quais ele dependa. Um serviço mascara uma falha ocultando-a completamente ou convertendo-a em um tipo de falha mais aceitável. Como um exemplo dessa última opção, somas de verificação são usadas para mascarar mensagens corrompidas – convertendo uma falha arbitrária em uma falha por omissão (COULOURIS; DOLLIMORE; KINDBERG, 2007).

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 63), “as falhas por omissão podem ser ocultadas caso se utilize um protocolo que retransmite as mensagens que não chegam ao seu destino” (efetuando um mascaramento por meio de replicação). Até mesmo o colapso de um processo pode ser mascarado – criando-se um novo processo e restaurando, a partir de informações previamente gravadas no disco, o estado da memória do seu predecessor.

5.5 CONFIABILIDADE DA COMUNICAÇÃO 1 PARA 1

Embora um canal de comunicação possa exibir as falhas por omissão que foram descritas anteriormente, “é possível usá-lo para construir um serviço de comunicação que mascare algumas dessas falhas”. (COULOURIS; DOLLIMORE; KINDBERG, 2007, p. 63).


169

O termo comunicação confiável, segundo Coulouris, Dollimore e Kindberg (2007, p. 63), é definido em termos de validade e integridade, conforme segue:

• validade: qualquer mensagem do buffer de envio é entregue ao buffer de recepção de seu destino, independente do tempo necessário para tal;• integridade: a mensagem recebida é idêntica à enviada e nenhuma mensagem é entregue duas vezes.

De acordo com Coulouris, Dollimore e Kindberg (2007, p. 63), as ameaças à integridade vêm de duas fontes independentes:

• Qualquer protocolo que retransmita mensagens, mas que não rejeite uma mensagem que é entregue duas vezes. Os protocolos podem incluir números de sequência nas mensagens para detectar aquelas entregues em duplicidade.• Usuários mal-intencionados que podem injetar mensagens espúrias, reproduzir mensagens antigas ou falsificar mensagens. Medidas de segurança podem ser tomadas para manter a propriedade da integridade diante de tais ataques.

Segundo o Wikcionário, a palavra espúrias refere-se a algo não genuíno; suposto, hipotético. Fonte: <http://pt.wiktionary.org/wiki/esp%C3%BArio>. Acesso em: 15 out. 2012.

NOTA


Artigo: Objetos distribuídos: conceitos e padrões A tecnologia de distribuição de objetos (Distributed Object Technology –

DOT) pode ser definida, de forma ampla, como a agregação de três tecnologias sinergicamente acopladas, a saber:

• Tecnologia de Objetos.• Tecnologia de Distribuição.• Tecnologia Web.


170

A tecnologia de objetos foi introduzida na computação por Adele Golderg e Alan Kay, através da linguagem Smalltalk, na década de 70. No modelo orientado a objeto, os sistemas são vistos como objetos que cooperam entre si e encapsulam a estrutura de dados e comportamento pertencentes a classes hierarquicamente construídas. Ela pode ser considerada uma tecnologia que permite lidar com complexidades, assim como aumentar a “manutenabilidade”, proporcionar reuso e redução do custo do ciclo de vida de software (Wallnau et al., 1997).

A tecnologia de distribuição envolve computadores autônomos que estão conectados a uma rede, não possuem memória física compartilhada e se não utilizam de um mesmo relógio. Essa tecnologia data do final dos anos 70 e início dos anos 80 com as pesquisas de banco de dados distribuídos (Nakanishi, 1981). O advento de CPUs, cada vez menores, mais baratas e mais potentes, precipitou o interesse em mover aplicações dos “mainframes” para PCs e estações de trabalho, assim como distribuir funcionalidades entre vários computadores conectados e comunicando-se entre si. Com o tempo, a noção de distribuição foi se generalizando, passando daquela que ligava computadores homogêneos fortemente acoplados e geograficamente próximos, para a distribuição entre computadores heterogêneos e geograficamente remotos. A distribuição tradicional emprega o modelo cliente/servidor no qual o processamento numa máquina (cliente) invoca o processamento em outra máquina (servidor) de uma maneira conhecida como chamada de procedimento remoto (Remote Procedure Call - RPC). O processo servidor é um provedor de serviços e dados e o processo cliente é o consumidor.

O desenvolvimento da tecnologia de distribuição levou ao uso da tecnologia “middleware”. Pode-se considerar, de forma geral, que essa tecnologia propõe a disponibilidade de um conjunto de facilidades comumente necessárias para integrar componentes (objetos ou não) num sistema distribuído (Rymer, 1996). Os detalhes desta tecnologia variam consideravelmente. Produtos com característica de “middleware” proveem uma infraestrutura de serviço, em tempo de execução, possibilitando aos componentes interagirem. O foco da tecnologia de distribuição é tornar o ambiente computacional mais e mais transparente com respeito à localização de máquinas e objetos (Wallnau et al., 1997).

A tecnologia Internet/Web nasceu nos anos 90 e causou uma explosão no uso da internet. Essa globalizou a computação, pois habilitou a criação de páginas de informação acessíveis em qualquer lugar e por qualquer pessoa, mas a principal característica é a possibilidade de se construírem grandes sistemas aplicativos ou promover a reengenharia de sistemas aplicativos antigos. A internet é uma plataforma que provê “conectividade” (Dick, 1997). A combinação do uso destas tecnologias mudou de uma maneira fundamental a forma como sistemas são construídos. Objetos são adicionados a redes e integrados via “middleware”, frequentemente chamados de “Object Request Brokers” (ORBs). Objetos representam unidades de distribuição, movimento e comunicação.


171

A tecnologia Web pode ser utilizada para prover “portabilidade” para a aplicação. Existe, com efeito, um novo paradigma em computação cujo foco é a “interoperabilidade” de objetos (Wallnau et al., 1997), entendendo-se por “interoperabilidade” a possibilidade de um programa, em um sistema, acessar programas e dados em outros sistemas (Bernstein, 1996). A tecnologia de distribuição de objetos dá a oportunidade de distribuir e globalizar, de forma transparente, uma aplicação. Várias vantagens técnicas resultam deste novo paradigma, como descrito a seguir (Fingar et al., 1997):

• Empacotamento em objeto (object wrapper). Esse empacotamento em objeto consiste no encapsulamento de um conjunto de serviços providos por uma aplicação não orientada a objeto ou no encapsulamento de uma interface de programa de maneira a poder tratar essa aplicação ou interface como um objeto (Fingar, 1998). Por exemplo, esse empacotamento poderá ser utilizado para criar uma interface para uma aplicação legada, isto é, já existente, para que a mesma possa ser tratada como um objeto. Desta forma, um sistema legado pode ser utilizado em um ambiente distribuído encapsulado como um objeto, poupando o desenvolvimento de um novo sistema orientado a objeto que ofereça as funcionalidades do sistema já existente. Esse empacotamento pode também ser aplicado a vários recursos já existentes, simplificando, assim, a comunicação entre eles através da rede.

• Distribuição dos objetos locais e remotos de uma determinada aplicação em computadores que melhor realizem as tarefas a eles definidas. Essa distribuição pode ser feita sem a necessidade de alterar a localização da aplicação que se utiliza destes objetos. Por exemplo, um objeto que realiza uma computação pesada pode ser colocado em um computador mais rápido, enquanto objetos que interagem com o usuário ficariam em uma estação de trabalho mais lenta. Essa distribuição permite uma melhor utilização de recursos de hardware.

• Facilidade na migração da implementação de um objeto de uma plataforma a outra. Isto é possível, pois os objetos mesmo remotos podem parecer como sendo locais aos seus clientes. O cliente não sabe onde e em que tipo de máquina realmente reside a implementação de um objeto utilizado por ele. Essa migração pode ser feita em etapas, sem a necessidade de alteração nos clientes.

• Recursos de hardware e software disponíveis em plataformas heterogêneas podem ser utilizados por uma aplicação. Tem-se a imagem de um sistema único que, na realidade, é formado por uma aplicação construída por objetos distribuídos.

De forma geral, a distribuição de objetos permite um avanço objetivando tornar a informação distribuída mais eficiente, mais flexível e menos complexa e ao mesmo tempo propondo soluções aos problemas existentes nos paradigmas cliente/servidor monolíticos (Fingar et al., 1997).


172

Deve-se notar que distribuição implica em “overhead” e naturalmente no gerenciamento deste “overhead”. Entretanto, quando um único sistema computacional não é grande o bastante para prover armazenagem necessária e capacidade de processamento para a informação, esta deve ser mantida em múltiplas plataformas. Existem muitas dificuldades para construir aplicações distribuídas orientadas a objetos, por exemplo (Eastman, 1997):

• Como essas aplicações devem ser implementadas.• Como esses sistemas irão se comunicar.• Como manter as informações num estado consistente.

Como situar serviços de forma a satisfazer as necessidades dos usuários.

• Como manter a segurança de acesso.• Como as falhas podem ser resolvidas.• Como gerenciar a evolução dos sistemas.

A distribuição de objetos pode ser utilizada na construção de base para a solução destes problemas, pois ela permite que (Eastman, 1997):

• Objetos de uma aplicação possam residir em qualquer lugar da rede.• Serviços de persistência possam armazenar e recuperar objetos eficientemente.• Serviços de pesquisa possam localizar objetos apropriadamente onde quer que

eles residam.• Serviços de segurança possam restringir o acesso a objetos sensíveis.• Serviços de concorrência possam prover isolamento de ações entre usuários.• Serviços de transações possam coordenar atualizações em múltiplos objetos.

Concluindo, a distribuição de objetos faz com que objetos distribuídos através de uma rede heterogênea se “interoperabilizem” formando um todo. Para obter as vantagens deste novo paradigma em computação é necessário conhecer os conceitos que envolvem objetos, distribuição e Internet. Trata-se de áreas do conhecimento muito vastas, interessantes, atuais e com uma gama muito grande de métodos e ferramentas a serem estudados.

FONTE: COSTA, Samira Rachid da. Objetos distribuídos: conceitos e padrões. São José dos Campos: INPE, 2000.

173

Caro acadêmico! Neste terceiro tópico, você estudou os seguintes conceitos:

• A comunicação entre os processos remetente e destino pode ser síncrona ou assíncrona, e na forma síncrona os processos remetente e destino são sincronizados a cada mensagem.

• Servidores de nomes eliminam a necessidade de utilização de endereços fixos na comunicação.

• Sockets utilizam a abordagem abertura, leitura, escrita e fechamento (open-read-write-close) que é derivada da abordagem básica para entrada e saída do UNIX.

• Uma das propriedades fundamentais em canais de comunicação é a integridade. A integridade exige que as mensagens não estejam corrompidas nem duplicadas.

• O TCP realiza diálogos de forma full-duplex, e realiza a transmissão com a abordagem conhecida como janela deslizante.

RESUMO DO TÓPICO 3

174

AUTOATIVIDADE

1 O que é uma thread?

2 O que é uma API?

3 Quais são os principais modos de operação dos sockets?

4 Em relação ao TCP, como é a confiabilidade do UDP?

5 Como o protocolo TCP trata a diversidade de tamanho de mensagens?

175

REFERÊNCIAS

BALTZAN, Paige; PHILLIPS, Amy. Sistemas de informação. Porto Alegre: AMGH, 2012.

BRAGA, Eduardo L. de; FERREIRA, Clélio M.; KOCHANSKI, Djone; POSSAMAI, Antônio C.; STEFFEN, Luiz F. Confiabilidade de sistemas gerenciadores de bancos de dados distribuídos. Florianópolis: UFSC, 2002.

COMER, Douglas Earl. Redes de computadores e Internet. Porto Alegre: Bookman, 2001.

COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Distributed systems: concepts and design. 3 ed. England: Addison Wesley, 2001.

COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Sistemas distribuídos: conceitos e projeto. 4 ed. Porto Alegre: Bookman, 2007.

CYCLADES Brasil. Guia internet de conectividade. 8 ed. São Paulo: SENAC, 2001.

DANTAS, Mario. Computação distribuída de alto desempenho: redes, clusters e grids computacionais. Rio de Janeiro: Axcel Books, 2005.

ENIAC. Disponível em: <http://pt.wikipedia.org/wiki/ENIAC>. Acesso em: 28 dez. 2012.

FERNANDES, Daniel Batista. Metodologia Dinâmica para o Desenvolvimento de Sistemas Versáteis. 1 ed. São Paulo: Erica, 1999.

FERREIRA, Clélio Marcos; KOCHANSKI, Djone; SCHROEDER, Rúbia Marli. RPC – Remote Procedure Call. Florianópolis: UFSC, 2002.

FLYNN, Ida M.; MCHOES, Ann Mclver. Trad.: Marcelo Alves Mendes. Introdução aos sistemas operacionais. São Paulo: Pioneira Thomson Learning, 2002.

FREITAS FILHO, Paulo José de. Apostila de modelagem, projeto e avaliação de desempenho de redes. Florianópolis: UFSC, 2002.

FRIEDRICH, Luís Fernando. Apostila de sistemas distribuídos: fundamentos. Florianópolis: UFSC, 2002.

GROSS, Jan Charles. Sistemas distribuídos. Indaial: Ed. Asselvi, 2008.

176

GUNTHER, Neil J. The practical performance analyst. Estados Unidos: McGraw Hill, 2000.

HOPSON, K. C.; INGRAM, Stephen E. Desenvolvendo applets com java. Rio de Janeiro: Campus, 1997.

MACHADO, Francis Berenger; MAIA, Luiz Paulo. Arquitetura de sistemas operacionais. 2 ed. Rio de Janeiro: LTC, 2000.

__________. Arquitetura de sistemas operacionais. 3 ed. Rio de Janeiro: LTC, 2002.

MAZZOLA, Vitório Bruno. Apostila de internet e intranets. Florianópolis: UFSC, 2002.

RIBEIRO, Uirá. Sistemas Distribuídos: Desenvolvendo Aplicações de Alta Performance no LINUX. Rio de Janeiro: Axcel Books, 2005.

RICCIONI, Paulo Roberto. Introdução a objetos distribuídos com CORBA. 1 ed. Florianópolis: Visual Books, 2000.

SILBERSCHATZ, A.; GALVIN, P. B.; GAGNE, G. Sistemas operacionais – Conceitos e Aplicações. Rio de Janeiro: Campus, 2004.

___________. Sistemas operacionais – Conceitos e Aplicações. Rio de Janeiro: Campus, 2001.

SILBERSCHATZ, A.; GALVIN, P. B. Sistemas operacionais – Conceitos. São Paulo: Pretince Hall, 2000.

SISTEMAS OPERACIONAIS. Disponível em: <http://www.lume.ufrgs.br/bitstream/handle/10183/19242/000102159.pdf>. Acesso em: 21 fev. 2013.

TANENBAUM, Andrew S. Sistemas operacionais modernos. São Paulo: Prentice Hall, 2003.

___________. Redes de computadores. Rio de Janeiro: Elsevier, 2004.

177

ANOTAÇÕES

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

178

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

____________________________________________________________

sistemas e aplicações distribuídas - uniasselvi

Documents