|
|
| (36 revisões intermediárias por 2 usuários não estão sendo mostradas) |
| Linha 1: |
Linha 1: |
| = Objetivos = | | = Resumo = |
| | |
| O objetivo deste projeto é implementar a arquitetura AutoI, uma das soluções atuais que permitem integrar um ambiente que leva semântica e autonomia a rede e que elimina ou minimiza os problemas do TCP/IP fazendo uso de ontologias a fim de dar inteligência às rígidas camadas da arquitetura atual.
| |
| | |
| A finalidade adicional é colaborar com os esforços da comunidade global para a implementação da Internet do Futuro, implementando protocolos e testes nas soluções desenvolvidas até agora para suportar os novos desafios.
| |
| | |
| = Justificativa =
| |
| | |
| Desde que foi criado uma maneira prática e simplificada de se alocar conteúdos em servidores que pudessem ser acessados rapida e facilmente por usuários no mundo inteiro, uma nova fase se iniciou e revolucionou a comunicação no mundo. Essa facilidade implementada por meio de marcações via hipertextos alavancou uma revolução chamada Internet. A partir daí, páginas e mais páginas começaram ser publicadas diariamente na grande rede e esta ação veio se multiplicando a cada dia provocando uma avalanche de endereços que armazenam informações das mais diversas.
| |
| | |
| Com tanta gente incluindo conteúdos, desde profissionais até leigos, fatalmente teria que provocar alguns problemas, e isso de fato aconteceu. Foram várias situações indesejáveis criadas que foram gradativamente exigindo a criatividade dos esepcialistas para uma solução. Algumas consequências foram mais sérias, entre elas, ocorre uma falta de padronização dessas informações que originou um problema para os usuários na hora de navegar na Internet e assim descobrir as informações desejadas. Esse fato foi denominado ''Information Overload''.
| |
| | |
| Outra consequência desse acúmulo de dados é que a Internet atual não consegue associar informações de várias páginas exatamente por essa despadronização e também devido à limitação dos protocolos que suportam estas atividades. Diante deste caos, a Web Semântica vem como uma possibilidade de solução permitindo criar um contexto onde a informação possa ter significado para as máquinas, que se encarregarão de levar a informação relevante ao seu usuário.
| |
| | |
| A web atual é um conjunto de recursos e links. Os recursos são identificados pelos seus URIs (''Uniform Resource Identifiers''). A URL (''Uniform Resource Location'') faz parte de um subconjunto da URI. Essa forma de descrição é bem tranquila para um internauta pois este tem condições de ler a descrição do link, identificar o sentido semântico intrínseco naquele contexto e a partir daí vai fazendo suas navegações consciente do rumo a ser seguido. Já a máquina, que ainda não entende segundo o raciocínio humano, não consegue fazer uma análise do juízo transmitido por um link pois muita pouca informações “machine-readable” está disponível.
| |
| | |
| O significado dos links só é evidente no contexto em torno do documento base portanto depende essencialmente da origem que o está chamando para se avaliar o sentido da informação. Exemplificando uma situação onde dois sites publiquem uma informação sobre ranking de determinado artista, onde em um a nota é positiva e no outro a nota é negativa. Para o entendimento humano, ocorre uma séria incoerência, em se tratando da mesma pessoa, já para a máquina, o procedimento é normal já que percebe uma simples ligação.
| |
| | |
| Na futura web, ou na web semântica, o conjunto de recursos e links também são identificados por URI's, mas podem ser "tipados". Consiste em atribuir um tipo à relação entre dois recursos. Forma-se o conceito de ontologia (Um recurso, uma propriedade e um valor). Neste contexto, uma relação entre dois recursos possui uma propriedade que permite atribuir significado à ligação. No exemplo dos sites de ranking, pode-se atribuir a propriedade "nota positiva" ao link no primeiro site e a propriedade "nota negativa" ao link no segundo site. A diferença entre os modelos é que agora o conhecimento está formalizado de uma maneira estruturada.
| |
| | |
| Antes da internet, o homem viveu o grande desafio de recuperar o conhecimento perdido em livros, documentos ou peças de museu esquecidas ou depositadas em lugares inalcançáveis. Contudo, a internet mudou este cenário tornando a informação e o conhecimento disponíveis a um clique. Entretanto, tal fato gerou a sobrecarga de informações que dificulta distinguir entre a informação relevente e o lixo. Enfrenta-se, novamente, o problema de encontrar a informação certa, na hora certa.
| |
| | |
| Os usuários, inevitavelmente, recorrerão aos mecanismos de busca, que avançam em iniciativas como a web semântica, buscando tornarem-se verdadeiros oráculos do meio digital. Mas para estabelecer a relação semântica entre as diversas fontes de informação, é necessário um esforço descentralizado, que pode demorar anos para se concretizar. Mas como toda novidade gera oportunidade, beneficiar-se-ão aqueles que alcançarem uma posição onde possam ser facilmente localizados por meio das relações semânticas criadas.
| |
| | |
| A mudança da Internet para atender estes novos padrões é obrigatória, porém a maneira de se fazer essa migração ainda é uma incógnita. Para isso, um número altíssimo de pessoas no mundo estão atualmente envolvidas na pesquisa e implementação de novas propostas que poderão atender às ansiedades atuais dos internautas.
| |
| | |
| Essas linhas de pesquisa buscam acompanhar e compreender o potencial de mudança da Web, especialmente sua evolução para uma estrutura na qual o conteúdo seja o elemento fundamental e que está levando ao desenvolvimento e ampliação das capacidades dos dispositivos computacionais. Não em termos quantitativos de potência de processamento, mas em termos de qualidade de processamento, uma vez que eles passarão a “compreender” os objetos digitais a partir da sua semântica intrínseca. A interação homem-máquina ocorrerá num nível mais elevado, num nível cooperativo entre as máquinas (''machine-to-machine''). Uma nova geração de ferramentas e dispositivos computacionais está surgindo. Assim, as ontologias terão papel fundamental, provendo contextos, conceitos e padrões de metadados para classificação e descrição a priori, manipulação, armazenamento, transmissão e apresentação dos objetos digitais.
| |
| | |
| Atualmente a internet pode ser considerada o principal meio de comunicação e a maior fonte de informações disponível. Devido a este sucesso, a demanda se torna cada vez maior, e consequentemente as expectativas dos seus usuários também são maiores, e para atender essa diversidade de expectativas, novos serviços e aplicações são criados a todo momento. Muitas dessas novas aplicações encontram diversas barreiras, deixando bem claro que a arquitetura atual da Internet não consegue suportar todos esses novos serviços por si só, tornando-se um fator limitante da internet.
| |
| | |
| Essa necessidade de evolução se faz obrigatória porque existe uma demanda por novas situações que não conseguem ser atendidas pela estrutura atual. Os revolucionários protocolos TCP/IP provocaram uma mudança radical porém não suportam as atuais necessidades. Baseado nisso, é fatop que a arquitetura do protocolo TCP/IP está com seus dias contados. No início da Internet, em que a mesma só era utilizada por alguns órgãos governamentais, indústrias de alta tecnologia e universidades, este protocolo atendia de forma satisfatória seus usuários. Com a explosão do uso da Internet surgiu a necessidade de se trabalhar em uma nova versão do IP, muito em função da recente saturação no número de endereços IPv4 disponíveis no mundo e que forçaram a criação de novos protocolos como o IPv6 que é na realidade um paliativo já que também não atende a algumas exigências como mobilidade, segurança, expansão ilimitada dos endereços IPS e outras demandas.
| |
| | |
| O datagrama do IPv4 em si é relativamente simples, mas quando associado aos seus componentes de controles que são incrementados ao longo do tempo (cabeçalhos) se torna extenso e as vezes com informações redundantes, tornando suas interações mais complexas. Essa complexidade leva a conseqüências prejudiciais para as entidades, como falhas e instabilidade, dando incoerência às informações.
| |
| | |
| Os protocolos e o modelo TCP/IP não diferenciam com clareza os conceitos de serviço, interface e protocolo. A boa prática da engenharia de software exige uma diferenciação entre especificação e implementação. Conseqüentemente, o modelo TCP/IP não é o melhor dos guias para a criação de novas redes com base em novas tecnologias. O modelo TCP/IP não é nem um pouco abrangente e não consegue descrever outras pilhas de protocolos que não a pilha TCP/IP, sendo praticamente impossível por exemplo, descrever a Bluetooth usando este modelo. A camada host/rede não é realmente uma camada no sentido em que o termo é usado no contexto dos protocolos hierarquizados. Trata-se, na verdade, de uma interface (entre as camadas de rede e de enlace de dados). A distinção entre uma interface e uma camada é crucial, mas não é feita no modelo TCP/IP.
| |
| | |
| O modelo TCP/IP não faz distinção entre as camadas física e de enlace de dados. Elas são completamente diferentes. A camada física está relacionada às características de transmissão do fio de cobre, dos cabos de fibra óptica e da comunicação sem fio. A tarefa da camada de enlace de dados é delimitar o início e o final dos quadros e enviá-los de um lado a outro com o grau de confiabilidade desejado. Um modelo mais adequado deve incluir as duas camadas como elementos distintos. O modelo TCP/IP não faz isso. Porém, apesar de ser praticamente inexistente o modelo TCP/IP seus protocolos se tornaram absurdamente populares e usados em larga escala.
| |
| | |
| Outro problema do protocolo TCP/IP é a falta de segurança deste. Uma das principais deficiências no aspecto de segurança deste protocolo é a incapacidade deste de autenticar uma máquina na rede. Em outras palavras, com base no endereço IP de origem de um pacote recebido, é impossível determinar com certeza a identidade da máquina que o tenha originado. Há também poucas garantias de que o conteúdo de um pacote recebido não tenha sido alterado, muito menos ainda que a privacidade dos dados nele contidos tenha sido preservada. Ou seja, visto que o IPv4 não foi projetado para ser seguro, qualquer maquina conectada a uma rede TCP/IP corre o risco de perder informações armazenadas nele.
| |
| | |
| Frente a tantos problemas no protocolo IPv4, a proposta adotada como evolução do IPv4 foi a SIPP (Simple Internet Protocol Plus), que foi atribuído o nome de IPv6. Este protocolo seria uma evolução que permite um número muito maior de IPs que o IPv4 e uma série de modificações no datagrama, com acréscimo de alguns cabeçalhos a fim e solucionar alguns problemas referentes ao IPv4.
| |
| | |
| Outra falha que podemos citar no protocolo TCP/IP está relacionada à redes sem fio. Quando projetado, o protocolo TCP/IP não previa que deveria suportar as redes ''wireless'', por isso não apresenta qualquer tipo de teste de congestionamento, apenas de chegada de pacotes, por esse motivo, muitas vezes o pacote é enviado e tarifado pelo provedor, mas devido a um congestionamento de rede, ou pelo fato deste usuário sair de uma região atendida por um determinado ponto de acesso para outro, o pacote tem que voltar ao provedor para ser novamente enviado, e como o TCP/IP não compreende tais situações, ele admite que o pacote foi perdido e envia outro, o qual será novamente tarifado ao ser enviado para o usuário desta rede sem fio.
| |
| | |
| Quando falamos em limitação da internet autal, já pensamos logo em numero de endereços IPs. Obviamente o numero de endereços IPs do protocolo IPv4 atual é um fator limitante. Quando iamos pensar que o nosso telefone celular fosse ter um endereco IP? E as nossas geladeiras? A LG lancou uma geladeira com acesso a internet. E o nosso carro? A BMW vende carros que ficam conectados 24h na internet via 3G ou GPRS. Cada um desses dispositivos possui um endereço IP. Imagine a quantidade de endereços que precisaremos para cada um desses dispositivos.
| |
| Mas as limitações da internet atual não se encontram apenas na quantidade de endereços. Novas applicações surgiram desde que o protocolo IPv4 foi desenhado. A Internet mudou. Na época não se falavam em video 3D FULL-HD sendo transmitido em tempo real para milhares de hosts, por exemplo. São milhares de exabytes sendo transportado por um protocolo que foi desenhado para alguns megabits por segundo. Novas demandas de muita informação e muita velocidade surgem e surgirão.
| |
| | |
| Existem ainda outras limitações nas compatibilidades do protocolo com novas tecnologias, principalmente, tecnologias wireless que necessitam de camadas para adaptar o protocolo com o protocolo da internet.
| |
| Limitações no gerenciamento de tanta informação, manuseio, roteamento de pacotes que não nos dá um retorno da saude da internet, por exemplo, se um determinado pacote demora para chegar, não sabemos onde ele demorou, dificultando o diagnostico de problemas.
| |
| | |
| Apesar de apresentar vantagens claras frente ao IPv4 e ser uma proposta que ajudaria a resolver alguns destes problemas, o IPv6 não poder ser considerado como solução. Ele ainda é um protocolo muito rígido, limitado em diversos aspectos. A verdadeira solução para os protocolos atuais está na possibilidade de darmos a capacidade de inferência para a máquina, ou seja, inserir semântica de modo a estabelecer conexão entre as informações, tornando os protocolos mais flexíveis a ponto de podermos encurtar as camadas de rede, transporte em enlace, etc.
| |
| | |
| == A amplitude da Internet ==
| |
| | |
| Propor alternativas para alterar a arquitetura atual de uma tecnologia tão útil não seria obrigatório se não fosse a abrangência conseguida por ela. Desde que foi colocada a disposição da comunidade, teve um crescimento nunca dantes visto no mundo. Atualmente, temos mais de 2 bilhões de usuários internautas que utilizam a Internet podendo ler e receber emails, navegar por páginas das mais diversas, baixar vídeos e arquivos em geral e outras tantas aplicações criadas pela inteligência humana. Deste total de fervorosos navegadores, uma média de 10% se encontra na Amércia Latina e o Brasil, especificamente tem se tornado arrebatado o maior percentual no nosso continente. Imaginem um dado de 2010, onde tivemos, em relação ao serviço de e-mail, 107 trilhões de mensagens no ano, numa média de 294 bilhões por dia. Ainda neste ano de 2010, os sites publicados chegaram a 255 milhões, num crescimento de 8% em relação ao ano anterior. Supondo que continue esse aumento proporcional, chegaríamos a 340 milhões em 5 anos e assim pelos próximos anos. Levando em conta que a Internet supera seus próṕrios números, provavelmente teríamos muito mais que isso.
| |
| | |
| Outro crescimento assustador, que ocorreu em função da facilidade de captar imagens e vídeos, pelo volume estrondoso de vendas de equipamentos como webcams, máquinas fotográficas digitais e filmadoras, foi o upload e download de vídeos, de musicais a eróticos e culturais. O Youtube, lider nesta categoria, recebe a cada minuto. o upload de 35 horas de conteúdo e todos os dias são assistidos 2 bilhões de vídeo no mundo, já no Facebook, são 2 bilhões por mes. A vedete do momento, as midias sociais, evoluiram de tal forma, em poucos anos, que já temos mais 152 milhões de blogs na rede; no Twitter, há 175 milhões de usuários (100 milhões a mais do que em 2009). A Lady Gaga possui, sozinha, 7,7 milhões de seguidores – sendo o perfil mais seguido. No Flickr, existem mais de 5 bilhões de fotos, sendo que mais de 3 mil são colocadas a cada minuto, o que dá uma média de 130 milhões de novas fotos ao mês.
| |
| | |
| Outro indicativo do poder desta rede é o número de domínios existentes, já são mais de 9 milhões de extensões COM. Com tantos números indicando uma população de usuários tão impressionante não é novidade, os apertos por que tem passado a estrutura atual e mais ainda as dificuldades que estão por vir para assumir números cada vez crescentes.
| |
| | |
| Soluções nessa linha de raciocínio já estão sendo desenvolvidas. Existem propostas de mudança de arquitetura e propostas para embutir mais inteligência na rede, ou as duas juntas. Com relação a primeira, o AutoI, uma das muitas soluções em fase de desenvolvimento a nível mundial, se encaixa de forma a tentar resolver os eventuais problemas que já foram detectados e outros que ainda devem surgir. Com relação à segunda, podemos citar a OWL ( ''Ontology Web Language'') que apresenta ferramentas como Protegé, Oracle 11g, OntoStudio entre outros; e ambientes nos quais testes deste tipo já estão sendo feitos e implementados sobre estruturas inavoadores, uma delas, o próprio AUTOI que trabalha em cima de uma topologia de planos.
| |
| | |
| Em função do histórico da evolução da Internet, das limitações que está sentindo e pela perspectiva de crescimento desenfreado, se faz necessário propor novas arquiteturas e soluções. Este projeto visa avaliar, selecionar, instalar, homologar e testar em várias situações do mundo real, as propostas disponíveis atualmente no mundo e em particular o AutoI, que pode vir a ser escolhida como uma das melhores estruturas para resolver os desafios discutidos até aqui.
| |
| | |
| = Introdução =
| |
| | |
| A Internet, como solução eficiente e econômica foi totalmente adotada pela comunidade mundial para prover uma comunicação efetiva e prática baseado no conceito de páginas que podem ser facilmente ligadas e a partir daí prover uma navegação amigável para o usuário de qualquer nível de conhecimento. Para suportar, tanto os ambientes necessários a essas atividades e também o numero de usuários que cresce exponencilamente, é necessária uma infraestrutura de rede organizada e padronizada. Esta rede para ter eficiência e boa performance em termos de comunicação é baseada em procedimentos pré-definidos denominados de protocolos.
| |
|
| |
|
| Para estruturar o processo de comunicação entre dois usuários na rede foi implementada uma proposta de pilhas de protocolos que atendem às mais diversas finalidades. Esta pilha denominada inicialmente de modelo OSI, conforme figura abaixo:
| | Este artigo tem o objetivo de propor uma colaboração para a comunidade mundial que desenvolve soluções para a Internet do Futuro. Por meio de implementações baseadas na plataforma AutoI, patrocinada pelo projeto FP7, que libera mihões de euros para o avanço da internet, a proposta é implantar um ambiente que possa ser estudado e evoluido a partir dos esforços de pesquisadores. Como resultado prático, prover a avaliação dos módulos do AutoI, submetidos a situações comuns nas redes locais e teste com protocolos específicos. |
| <br> | | <br> |
|
| |
|
| Mudar Figura para alguma que não tenha a marca How Stuff Works
| | = Palavras-Chave = |
| | | * AutoI, Fire, Geni, Internet do futuro, Ontologia, Web semântica. |
| [[Arquivo:osi-model.jpg|center]]
| |
| <br>
| |
| Esse modelo contém 7 camadas distribuidas da seguinte forma a partir da visão inferior:
| |
| <br>
| |
| '''Camada física'''<br>
| |
| Os protocolos desta camada são os que realizam a codificação/decodificação de símbolos e caracteres em sinais elétricos lançados no meio físico, que fica logo abaixo dessa camada. A camada física tem a função de transmitir uma seqüência de bits através de um canal de comunicação. As funções típicas dos protocolos desta camada são fazer com que um bit "1" transmitido por uma estação seja entendido pelo receptor como bit "1" e não como bit "0". Assim, esta camada trabalha basicamente com as características mecânicas e elétricas do meio físico, como por exemplo:
| |
| *Número de volts que devem representar os níveis lógicos "1" e "0";
| |
| *Velocidade máxima da transmissão;
| |
| *Transmissão simplex, half duplex ou full duplex;
| |
| *Número de pinos do conector e utilidade de cada um;
| |
| *Diâmetro dos condutores.
| |
| <br>
| |
| '''Camada de Enlace de Dados'''<br>
| |
| O principal objetivo da camada de enlace é receber/transmitir uma seqüência de bits do/para o nível físico e transformá-los em uma linha que esteja livre de erros de transmissão, a fim de que essa informação seja utilizada pela camada de rede. A camada de enlace está dividida em dois subníveis:
| |
| *Subnível superior - controle lógico do enlace (LLC - Logical Link Control) - O protocolo LLC pode ser usado sobre todos os protocolos IEEE do subnível MAC, como por exemplo, o IEEE 802.3 (Ethernet), IEEE 802.4 (Token Bus) e IEEE 802.5 (Token Ring). Ele oculta as diferenças entre os protocolos do subnível MAC. Usa-se o LLC quando é necessário controle de fluxo ou comunicação confiável;
| |
| *Subnível inferior – controle de acesso ao meio (MAC - Medium Access Control) possui alguns protocolos importantes, como o IEEE 802.3 (Ethernet), IEEE 802.4 (Token Bus) e IEEE 802.5 (Token Ring). O protocolo de nível superior pode usar ou não o subnível LLC, dependendo da confiabilidade esperada para esse nível.
| |
| <br>Outras funções desta camada são: fornecer controle de tráfego de quadros, seqüenciamento de quadros, quadro de confirmação, quadro que delimita, verificação de erro de quadro e também o gerenciamento de acesso de mídia.
| |
| <br>
| |
| '''Camada de rede'''<br>
| |
| A camada de rede tem a função de controlar a operação da rede de um modo geral. Suas principais funções são o roteamento dos pacotes entre fonte e destino, mesmo que estes tenham que passar por diversos nós intermediários durante o percurso, o controle de congestionamento e a contabilização do número de pacotes ou bytes utilizados pelo usuário, para fins de tarifação. Uma das questões é qual rota escolher. Esta tarefa é feita baseada em tabelas estatísticas, que são configuradas na criação da rede e são raramente modificadas. Outra característica desta camada é o controle de congestionamento. Se em uma mesma rota estão sendo transmitidos muitos pacotes a performance da rede será pior. O IPX (Internetwork Packet Exchange Protocol) é um protocolo da camada de rede que oferece serviço sem conexão (datagrama) e é responsável pelo roteamento dos pacotes na rede. É nessa camada que o IP começa a surgir.
| |
| <br>
| |
| '''Camada de transporte'''<br>
| |
| A camada de transporte é a primeira que trabalha com conexões lógicas fim a fim, ou seja, um programa na máquina fonte conversa com um programa similar na máquina destino, diferente dos níveis anteriores, que conversavam somente com o nó vizinho. Lembremos que a conexão criada pelo nível de transporte é uma conexão lógica, e os dados são transmitidos somente pelo meio físicos, através da camada física do modelo. Assim, os dados devem descer nível a nível até atingir o nível 1, para então serem transmitidos à máquina remota. A camada de transporte garante que as mensagens são entregues sem erros na seqüência e sem perdas ou duplicações. O SPX (Sequenced Packet Exchange) é um protocolo da camada de transporte que estende o IPX para fornecer serviço baseado em conexão com uma transmissão confiável, como foi dito anteriormente. A transmissão confiável é garantida pela retransmissão dos pacotes quando há algum erro. Outros protocolos da camada de transporte são o TCP (Transmission Control Protocol) e o UDP (User datagram Protocol), que são bastante conhecidos. A camada de transporte inclui funções relacionadas com conexões entre a máquina fonte e máquina destino, segmentando os dados em unidades de tamanho apropriado para utilização pelo nível de rede, seguindo ou não as orientações do nível de sessão. As principais funções da camada de transporte são: a criação de conexões para cada requisição vinda da camada superior, multiplexar as várias requisições vindas da camada superior em uma única conexão de rede, dividir as mensagens em tamanhos menores, a fim de que possam ser tratadas pela camada de rede e estabelecer e terminar conexões através da rede. O tamanho e a complexidade de um protocolo de transporte depende do tipo de serviço pode ser da camada de rede. A camada de transporte fornece:
| |
| *Mensagem de segmentação: aceita uma mensagem da camada (sessão) acima dela, divide a mensagem em unidades menores (se já não é pequena o suficiente) e passa as menores unidades para a camada de rede;
| |
| *Mensagem de confirmação: fornece entrega de mensagens confiável de ponta a ponta com confirmações;
| |
| *Mensagem de controle de tráfego: informa a estação de transmissão para "back-off" quando nenhum buffer de mensagem está disponível;
| |
| *Multiplexação de sessão: multiplexação de vários fluxos de mensagem, ou sessões em um vínculo lógico e controla as mensagens que pertencem a quaisquer sessões. | |
| Foram especificadas cinco classes de protocolos orientados à conexão:
| |
| *Classe 0: simples, sem nenhum mecanismo de detecção e recuperação de erros;
| |
| *Classe 1: recuperação de erros básicos sinalizados pela rede;
| |
| *Classe 2: permite que várias conexões de transporte sejam multiplexadas sobre uma única conexão de rede e implementa mecanismos de controle de fluxo;
| |
| *Classe 3: recuperação de erros sinalizados pela rede e multiplexação de várias conexões de transporte sobre uma conexão de rede;
| |
| *Classe 4: detecção e recuperação de erros e multiplexação de conexões de transporte sobre uma única conexão de rede.
| |
| <br>
| |
| '''Camada de Sessão'''<br>
| |
| A camada de sessão permite o estabelecimento da sessão entre processos em execução em estações diferentes. A função dela é administrar e sincronizar diálogos entre dois processos de aplicação. Este nível oferece dois tipos principais de diálogo: half duplex e full duplex. Esta camada fornece:
| |
| *Estabelecimento da sessão, manutenção e o encerramento: permite que dois processos de aplicativo em máquinas diferentes para estabelecer, usar e encerrar uma conexão, chamada de uma sessão;
| |
| *Suporte de sessão: executa as funções que permitem que esses processos para se comunicar pela rede, executar segurança, reconhecimento de nome, log e assim por diante;
| |
| *Mecanismos que permitem estruturar os circuitos oferecidos para o nível de transporte.
| |
| Neste nível ocorre a quebra de um pacote com o posicionamento de uma marca lógica ao longo do diálogo. Esta marca tem como finalidade identificar os blocos recebidos para que não ocorra uma recarga, quando ocorrer erros na transmissão. Uma sessão pode ser aberta entre duas estações a fim de permitir a um usuário se logar em um sistema remoto ou transferir um arquivo entre essas estações. Os protocolos desse nível tratam de sincronizações (checkpoints) na transferência de arquivos.
| |
| <br>
| |
| '''Camada de apresentação'''<br>
| |
| A camada de apresentação formata os dados a serem apresentados para a camada de aplicativo assegurando que a informação seja transmitida de tal forma que possa ser entendida e usada pelo receptor. Dessa forma, este nível pode modificar a sintaxe da mensagem, mas preservando sua semântica. Essa camada pode converter dados de um formato usado pela camada de aplicativo em um formato comum na estação de envio, converter o formato comum para um formato conhecido para a camada de aplicativo na estação de recebimento. A camada de apresentação fornece:
| |
| *Tradução do código de caractere: por exemplo, ASCII para EBCDIC;
| |
| *Conversão de dados: bit de ordem, ponto de CR-CR/LF, flutuante inteiro e assim por diante;
| |
| *Compactação de dados: reduz o número de bits que precisam ser transmitidos na rede;
| |
| *Criptografia de dados: criptografar dados para fins de segurança. Por exemplo, criptografia de senha.
| |
| <br> | | <br> |
| '''Camada de aplicação'''<br>
| |
| A camada de aplicação é a camada que possui o maior número de protocolos existentes, devido ao fato de estar mais perto do usuário e os usuários possuírem necessidades diferentes. Alguns desses protocolos são: HTTP (HyperText Transfer Protocol secure), FTP(File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), Telnet (protocolo de login remoto), dentre muitos outros. A camada de aplicativo serve como a janela para usuários e processos de aplicativos acessar os serviços de rede, ou seja, essa camada é a interligação dos usuários com os serviços. Ela fornece ao usuário uma interface que permite acesso a diversos serviços de aplicação, convertendo as diferenças entre diferentes fabricantes para um denominador comum. Essa camada contém uma variedade de funções normalmente necessárias:
| |
| *Redirecionamento de recursos de compartilhamento e dispositivo;
| |
| *Acesso remoto a arquivos;
| |
| *Acesso remoto de impressora;
| |
| *Comunicação entre processos;
| |
| *Gerenciamento de rede;
| |
| *Serviços de diretório;
| |
| *Eletrônica de mensagens (como email);
| |
| *Rede virtuais terminais.
| |
|
| |
|
| Na visão do usuário internauta, que manipula páginas com conteúdos dos mais diversos, das quais ele pode ser também responsável pela criação, destacou-se um padrão que revolucionou a arte de se confeccionar páginas, o HTML.
| | = Abstract = |
| <br><br><br>
| |
|
| |
|
| '''Descrever o HTML''' => tirar de algum livro ou artigo
| | Collaboration with the future internet in the autoi environment |
| <br> Felipe
| |
|
| |
|
| O HTML (acrônimo para HyperText Markup Language, que significa Linguagem de Marcação de Hipertexto) é a linguagem de marcação predominante nas páginas web.
| | The objective of this document is to instruct the authors about the preparation of the manuscript for its submission to the proceedings of the Conference of Studies in Electric Engineering. The authors should use these guidelines for preparing both the initial and final versions of their paper. They will only be accepted for publication works that are integrally in accordance with these norms. When the paper is written in English, this same layout must be observed. |
|
| |
|
| O HTML é escrito na forma de elementos HTML que consistem em etiquetas dentro de parênteses angulares (como <html>) dentro do conteúdo das páginas web. As etiquetas normalmente aparecem em pares como <nowiki><h1> e </h1></nowiki>. A primeira é uma etiqueta de início e a segunda de final. Dentro dessas etiquetas é possível adicionar texto, tabelas, imagens e etc.
| | = Keywords = |
| | * AutoI, Fire, Future internet, Geni, Ontology, Semantic Web |
| | <br> |
|
| |
|
| O propósito de um navegador (browser) é ler documentos HTML, interpretar e apresentar em forma visual ou audível. O navegador não mostra as etiquetas HTML, mas as usa para interpretar o conteúdo da página e apresentá-la em um formato adequado.
| | = Objetivos = |
|
| |
|
| Elementos HTML são os construtores de blocos de todos os sites. Ele provê meios de criar documentos estruturados ao aplicar uma estrutura semântica para textos como cabeçalhos, parágrafos, listas, links, citações e outros ítens. É possível também embarcar scripts em linguagens como o JavaScript que afetam o comportamento das páginas HTML. [Referência: RFC 1866: Hypertext Markup Language - 2.0 (T. Berners-Lee, 1995) http://www.ietf.org/rfc/rfc1866.txt]
| | O objetivo deste projeto é implementar a arquitetura AutoI, uma das soluções atuais que permitem integrar um ambiente que leva semântica e autonomia a rede e que elimina ou minimiza os problemas do TCP/IP fazendo uso de ontologias a fim de dar inteligência às rígidas camadas da arquitetura atual. |
|
| |
|
| <br><br>
| | A finalidade adicional é colaborar com os esforços da comunidade mundial para a implementação da Internet do Futuro, introduzindo protocolos e testes nas soluções desenvolvidas até agora para suportar os novos desafios. |
|
| |
|
| Atualmente, a grande maioria das aplicações criadas no mundo usam ou pretendem usar o ambiente web para facililitar o trabalho de publicação e utilização destas páginas. Com a característica marcante do ser humano, que sempre procura incrementar suas atividades exigindo o máximo das soluções disponíveis, com a Internet não poderia ser diferente. Com o absurdo crescimento no número de internautas e consequentemente dos serviços na rede, a demanda por novas necessidades também foi marcante e acabou por forçar a implementação de técnicas que resolvessem problemas atuais.
| | = Justificativa = |
|
| |
|
| Um dos tantos exemplos foi a limitação do protocolo IPv4 com relação ao número de endereços IPs, um desafio que surgiu para a comunidade científica que se envolveu na procura de uma solução. Uma delas foi a proposta de criação de um novo protocolo e neste contexto, surgiu o IPv6
| | *[[Semantic Web - Justificativa]] |
| <br><br><br>
| |
|
| |
|
| '''Descrever protocolo IPv6''' => tirar de algum livro ou artigo. Incluir alguma figura [Caio]
| | = Introdução = |
| <br><br><br>
| |
|
| |
|
| A longo prazo, o IPv6 tem como objetivo substituir o IPv4, que só suporta cerca de 4 bilhões (4x109) de endereços IP, contra cerca de 3,4x1038 endereços do novo protocolo. O principal motivo para a implantação do IPv6 na Internet é a necessidade de mais endereços, porque os endereços livres IPv4 estão se acabando.
| | * [[Semantic Web - Introdução]] |
|
| |
|
| Ainda assim, já no início de sua utilização comercial, em 1993, acreditava-se que o espaço de endereçamento da Internet poderia se esgotar num prazo de 2 ou 3 anos. Isso não ocorreu por conta da quantidade de endereços, mas sim por conta da política de alocação inicial, que não foi favorável a uma utilização racional desses recursos. As previsões iniciais, no entanto, de esgotamento quase imediato dos recursos, não se concretizaram devido ao desenvolvimento de uma série de tecnologias, que funcionaram como uma solução paliativa para o problema trazido com o crescimento acelerado:
| | = Desenvolvimento = |
|
| |
|
| • O CIDR (Classless Inter Domain Routing), ou roteamento sem uso de classes, que é descrito pela RFC1519. Com o CIDR foi abolido o esquema de classes, permitindo atribuir blocos de endereços com tamanho arbitrário, conforme a necessidade, trazendo um uso mais racional para o espaço.
| | * [[Semantic Web - Desenvolvimento]] |
|
| |
|
| • O uso do NAT e da RFC 1918, que especifica os endereços privados, não válidos na Internet, nas redes corporativas. O NAT permite que com um endereço válido apenas, toda uma rede baseada em endereços privados, tenha conexão, embora limitada, com a Internet.
| | = Metodologia = |
|
| |
|
| • O DHCP (Dynamic Host Configuration Protocol), descrito pela RFC 2131. Esse protocolo trouxe a possibilidade aos provedores de reutilizarem endereços Internet fornecidos a seus clientes para conexões não permanentes.
| | *[[Semantic Web - Metodologia]] |
|
| |
|
| | = Plano de Trabalho = |
|
| |
|
| Dentre as novidades propostas podemos citar: o espaço de endereços foi ampliado, sendo que o IPv6 têm um tamanho de 128 bits; a inclusão de endereçamento hierárquico, a qual simplifica as tabelas de encaminhamento dos roteadores da rede, diminuindo assim a carga de processamento dos mesmos; um novo formato do cabeçalho totalmente remodelados em relação ao IPv4, apresentando cabeçalhos de extensão, uma opção para guardar informação adicional; suporte a qualidade diferenciada à aplicações de áudio e vídeo passam a estabelecer conexões apropriadas tendo em conta as suas exigências em termos de qualidades de serviços (QoS; a capacidade de extensão permitindo adicionar novas especificações de forma simples e encriptações, pois diversas extensões no IPv6 permitem, à partida, o suporte para opções de segurança como autenticação, integridade e confidencialidade dos dados.
| | = Resumo = |
| | |
| Um datagrama IPv6 é constituído por um cabeçalho base, ilustrado na figura que se segue, seguido de zero ou mais cabeçalhos de extensão, seguidos depois pelo bloco de dados.
| |
| | |
| [[Arquivo:Ipv6Image.gif]]
| |
| | |
| Formato do cabeçalho base do datagrama IPv6:
| |
| • Tem menos informação que o cabeçalho do IPv4. Por exemplo, o checksum será removido do cabeçalho, que nesta versão considera-se que o controle de erros das camadas inferiores é confiável.
| |
| • O campo Traffic Class é usado para assinalar a classe de serviço a que o pacote pertence, permitindo assim dar diferentes tratamentos a pacotes provenientes de aplicações com exigências distintas. Este campo serve de base para o funcionamento do mecanismo de qualidade de serviço(QoS) na rede.
| |
| • O campo Flow Label é usado com novas aplicações que necessitem de bom desempenho. Permite associar datagramas que fazem parte da comunicação entre duas aplicações. Usados para enviar datagramas ao longo de um caminho pré-definido.
| |
| • O campo Payload Length representa, como o nome indica, o volume de dados em bytes que pacote transporta.
| |
| • O campo Next Header aponta para o primeiro header de extensão. Usado para especificar o tipo de informação que está a seguir ao cabeçalho corrente.
| |
| • O campo Hop Limit tem o número de hops transmitidos antes de descartar o datagrama, ou seja, este campo indica o número máximo de saltos (passagem por encaminhadores) que o datagrama pode dar, antes de ser descartado.
| |
| | |
| No IPv6 o responsável pela fragmentação é o host que envia o datagrama, e não os roteadores intermédios como no caso do IPv4. No IPv6, os roteadores intermédios descartam os datagramas maiores que o MTU da rede. O MTU será o MTU máximo suportado pelas diferentes redes entre a origem e o destino. Para isso o host envia pacotes ICMP de vários tamanhos; quando um pacote chega ao host destino, todos os dados a serem transmitidos são fragmentados no tamanho deste pacote que alcançou o destino.
| |
| | |
| O processo de descoberta do MTU tem que ser dinâmico, porque o percurso pode ser alterado durante a transmissão dos datagramas. No IPv6, um prefixo não fragmentável do datagrama original é copiado para cada fragmento. A informação de fragmentação é guardada num cabeçalho de extensão separado. Cada fragmento é iniciado por uma componente não fragmentável seguida de um cabeçalho do fragmento.
| |
| | |
| Uma das novidades do IPv6, é a possibilidade de utilização de múltiplos cabeçalhos encadeados. Estes cabeçalhos extra permitem uma maior eficiência, devido a que o tamanho do cabeçalho pode ser ajustado às necessidades. Também permite uma maior flexibilidade, porque podem ser sempre adicionados novos cabeçalhos para satisfazer novas especificações.
| |
| | |
| O endereçamento no IPv6 é de 128 bits, e inclui prefixo de rede e sufixo de host. No entanto, não existem classes de endereços, como acontece no IPv4. Assim, a fronteira do prefixo e do sufixo pode ser em qualquer posição do endereço.
| |
| Os endereços IPv6 são normalmente escritos como oito grupos de 4 dígitos hexadecimais. Por exemplo,
| |
| | |
| 2001:0db8:85a3:08d3:1319:8a2e:0370:7344
| |
| | |
| Se um grupo de vários dígitos seguidos for 0000, pode ser omitido. Por exemplo,
| |
| | |
| 2001:0db8:85a3:0000:0000:0000:0000:7344
| |
|
| |
|
| é o mesmo endereço IPv6 que:
| | = Referências = |
|
| |
|
| 2001:0db8:85a3::7344
| | * [[Semantic Web - Referências]] |
|
| |
|
| Existem no IPv6 tipos especiais de endereços: unicast, onde cada endereço corresponde a uma interface (dispositivo); multicast, em que cada endereço corresponde a múltiplas interfaces e é enviada uma cópia para cada interface, e por último o anycast, que corresponde a múltiplas interfaces que partilham um prefixo comum. Um datagrama é enviado para um dos dispositivos, por exemplo, o mais próximo.
| | = Rascunho = |
|
| |
|
| O protocolo IPv6 não é um "upgrade" do IPv4, é um protocolo totalmente novo. O seu endereçamento é diferente, os seus cabeçalhhos são especializados e flexíveis, permite o controlo de fluxo, segurança, auto-configuração e outros aspectos novos.
| | * [[Semantic Web - Rascunho]] |
| Mas suporta o modelo iPv4, já que qualquer endereço que começe com 80 bits zero (0) seguidos de 16 bits um (1) ou 16 bits zero (0) contém um endereço de IPv4 nos 32 bits à direita
| |
|
| |
|
| Além desta, podemos citar outros fatores que tornam a Internet atual despreparada para as demandas do futuro,
| | = Objetivos do Aluno = |
| <br><br><br>
| |
|
| |
|
| '''Descrever limitações da internet''' => Artigo: Fundamental Limitations of current Internet
| | Ao final do projeto de Iniciação Científica os alunos participantes terão conhecimentos das arquiteturas previstas para a implantação da Internet do Futuro e terão experimentado algumas iniciativas de grupos que participam desta empreitada. |
| and the path to Future Internet1 - EC FIArch Group2 - Release Date: 1 March 2011 [João Paulo]
| |
| <br><br><br>
| |
|
| |
|
| Muitos grupos se encontram atualmente desenvolvendo soluções para a Internet do Futuro e entre várias opções, a proposta do AutoI parece ser bem interessante. Ela propõe uma arquitetura em planos que ...
| | Para alcançarmos tal objetivo, é necessário ao aluno adquirir conhecimentos básicos de arquitetura de redes, protocolos básicos de comunicação, ferramentas disponíveis e as soluções em desenvolvimento que poderão assumir as demandas atuais e futuras da internet. Devido a estes fatores, dividimos o programa de Iniciação Científica em semestres. |
| <br><br><br>
| |
|
| |
|
| Descrever o AutoI => incluir figura<br> [Alex]
| | No primeiro semestre os Alunos vinculados pesquisarão sobre as soluções disponíveis e procurarão selecionar a proposta mais interessante. Os frutos da pesquisa permitirão tomar decisões de qual a melhor solução proposta pelo projeto, como também quais os recursos físicos e lógicos necessários para a construção de um projeto piloto. |
|
| |
|
| | No segundo semestre, o desafio é adquitir, planejar a implantação, instalar e trabalhar em cima da plataforma escolhida tentando resolver os possíveis problemas de integração, performance e qualidade. |
|
| |
|
| OSKMV: Orchestration, Service Enablers, Knowledge, Management e Virtualisation. | | No terceiro semestre, a intenção é validar as várias funções disponíveis e submeter a solução a stress de tráfego e situação de segurança. |
|
| |
|
| Uma proposta que pretendemos apoiar e utilizar como plataforma para o desenvolvimento de soluções para a Internet do Futuro é o AutoI. Desenvolvido na Europa, este propõe corrigir os problemas da Internet atual, visto que esta alcançou proporções muito grandes e necessita de melhorias para poder interconectar sistemas e conhecimento. O grande desafio e objetivo é projetar e desenvolver uma solução que possa abranger redes heterogêneas, que suporte um serviço de mobilidade, confiabilidade e qualidade de serviço, sendo que esta solução seja uma rede de infraestrutura aberta (open source) baseado em ontologias de informações e modelos de dados.
| | NO quarto semestre, o objetivo é comparar a solução com outras em desenvolvimento no mundo e avaliar em condições de funcionamento tradicional e para as novas demandas. |
| A arquitetura deste modelo é estruturada em cinco abstrações, os planos OSKMV: Orchestration, Service Enablers, Knowledge, Management e Virtualisation. Cada um destes planos executaria funções que abrangem desde a aplicação ao seu controle, para que todos os objetivos e melhorias propostas fossem alcançadas.
| |
| [[Arquivo:planosAUTOI.jpg|center|frame|Figura: Representação dos planos do AutoI, Fonte:(“Platforms and Software Systems for an Autonomic Internet")]]
| |
| O plano de orquestração (Orchestration) é uma definição conceitual para uma série de ferramentas que governam, integram e policiam os processos e aplicações da Internet através de sistemas autonômicos de controle, os quais tem a capacidade de cancelar ou corrigir processos, além de interagirem. O controle destes sistemas é feito por componentes de orquestração distribuídos, chamados DOCs, os quais possuem uma visão da arquitetura de processos específicos e atuam através de comandos específicos para interferir em cada processo.
| |
| O plano de abilitadores de serviço (Service Enablers) é um conjunto de funções de reimplantação automática de protocolos, serviços de controle e serviços prestados ao usuário. Isto permite que os códigos sejam ativados ou executados sobre entidades da rede, aumentando o controle e a segurança sobre estes serviços.
| |
| O plano de conhecimento (Knowledge) consiste de modelos e ontologias com a capacidade de fazer análises e integrar conhecimentos através de inferências, assim a rede tem a capacidade de executar auto-monitoramento, auto-análise, entre outros processos que possibilitam a conexão entre dados conforme características comuns, o que cria uma estrutura circular entre as informações e deixa todo o processo mais inteligente e eficiente.
| |
| O plano de gestão (Management) é justamente formado pelos sistemas autonômicos de controle que agem nos processos da rede em loops constantes, controlados pelo plano de orquestração. É importante destacar que cada sistema atua sobre um processo específico de forma automática, através de funções de monitoramento. Este plano tem a capacidade de gerar funções embarcadas na rede que se adaptam ao meio e que podem ser extendidas conforme necessidade, sem perturbar o funcionamento do sistema, além de minimizarem o custo computacional das operações e o consumo de energia.
| |
| O plano de virtualização (Virtualisation) são mecanismos de software que tratam recursos físicos selecionados como recursos virtuais de programação organizados pelos planos de orquestração e gestão para a criação de componentes, dispositivos ou redes. Este plano é utilizado pelo plano de orquestração para governar os recursos virtuais e construir redes e instrumentos para serviços específicos.
| |
|
| |
|
| Além dos planos, pode ser destacada uma interface que providencia um meio para acessar o plano de controle de forma a configurar componentes para iniciar roteadores virtuais que formam novas redes, chamada de vCPI(Virtualisation Component Programming Interface). Estes roteadores chamados Virtual Routers(VR), surgem através de máquinas virtuais (Virtual Machines - VM) graças a um sistema de operação presente em cada uma delas que podem atuar em cada processo local. Abaixo o ciclo de vida de uma VM, que representa cada um dos estados possíveis desta, que variam desde parada ou indefinida, até em funcionamento ou suspensa conforme necessidade.
| | * 1º Semestre |
| [[Arquivo:ciclodevidaVM.jpg|center|frame|Figura: Ciclo de vida de uma VM, Fonte:(Autonomic Internet Framework)]]
| | ** 1.Estudo da literatura de dados sobre FI |
| | ** 2 semanas |
| | ** Felipe e Caio |
|
| |
|
| Existem métodos pré-definidos para cada VM, os quais podem receber como parâmetros que variam desde uma URL até um objeto identificador da própria máquina. Estes métodos retornam mensagens de erro e podem modificar o estado, iniciar migrações e criar instâncias na VM. Por exemplo, existe um método chamado por changeVMState, para o qual são passados um objeto de identificação de uma VM e o novo estado que esta deve assumir.
| | * 2.Acompanhamento das publicações no site do FIABook; |
| Existem processos para controle de Virtual Links, cujo objetivo é conectar dois VRs. Estes devem ser chamados por ambos componentes e podem desde criar, a modificar e remover conexões entre os roteadores . Um exemplo é o método que cria um link, instantiateLink, que recebe como parâmetros os identificadores das duas VM e os parâmetros do link, e retorna o identificador do link.
| | ** Aprofundamento no XML, RDF e Sparql |
| Para segurança e bom funcionamento dos componentes configurados nesta interface, existem também métodos de monitoramento que permitem a outros planos o acesso a valores de cada componente, além de retornarem listas de identificadores de links ou de VMs. Exemplos desses processos são: getMonitoringValues e getVMList que não necessitam de parâmetros e retornam valores de RAM e HD disponíveis, entre outros, e listas de identificadores de VMs, especificamente.
| | ** 4 semanas |
| | ** Felipe |
| | ** Acompanhamento das publicações no site dos EUA; |
| | ** Caio |
|
| |
|
| Artigos:
| | * 3.Participação no fórum da solução mais relevante Europa |
| * Platforms and Software Systems for an Autonomic Internet. J. Rubio-Loyola1, A. Astorga2, J. Serrat2, W. K. Chai3, L. Mamatas3, A. Galis3, S. Clayman3, A. Cheniour4, L. Lefevre4, A. Fischer5, A. Paler5, Y. Al-Hazmi5, H. de Meer5. CINVESTAV Tamaulipas - Mexico, 2Universitat Politècnica de Catalunya - Spain, 3University College London – U.K., 4INRIA- France, 5University of Passau - Germany | | ** Avaliação do Evento W3C |
| | ** Aprofundamento em HTML5, CSS3 e OWL |
| | ** Felipe |
| | ** Participação no fórum da solução mais relevantes EUA |
| | ** Caio |
| | ** 3 semanas |
|
| |
|
| * Autonomic Internet Framework. Deliverable D6.3 Final Results of the Autonomic Internet Approach Autonomic Internet (AUTOI) Project. FP7-ICT-2007-Call 1 - 216404. | | * 3a. Desenvolvimento de aplicações básicas para Web Semântica |
| <br><br><br>
| | ** 4 semanas |
| | ** Felipe |
|
| |
|
| | * 4.Seleção da melhor solução para Internet do Futuro na visão do grupo; |
| | ** Felipe |
| | ** 3 semanas |
| | ** Caio e Felipe |
|
| |
|
| | * 4a. Análise de artigos do W3C |
| | ** 3 semanas |
| | ** Felipe |
|
| |
|
| * a necessidade de "dar" semântica aos protocolos, para que possam possibitar conexões entre informações, além de aproximar as camadas, reduzindo algumas destas. [Alex] | | * 5.Instalação e adequação das soluções escolhidas; |
| | ** Configuração do ambiente |
| | ** Caio |
| | ** Anaĺise do código |
| | ** Felipe |
| | ** 10 semanas |
|
| |
|
| ** Procurar exemplos de aplicação da semântica | | * 6.Documentação dos resultados da pesquisa; |
| ** Exemplo: Estou numa cidade estranha, são 2 hs da manhã, minha esposa está grávida e com desejo. Preciso achar um disk-food que me entregue rápido o meu pedido. Ao buscar o pedido, o sistema me retorna, centenas de páginas com informações desconexas. | | ** 2 semanas |
| | ** Felipe e Caio |
|
| |
|
| = Desenvolvimento =
| | * 2º Semestre |
| | ** 7.Definição dos requisitos e premissas da arquitetura; |
| | ** 8.Planejamento da infraestrutura adequada; |
| | ** 9.Aquisição da infraestrutura; |
| | ** 10.Instalação em ambiente definitivo para implementação da solução; |
| | ** 11.Correção de bugs e homologação de resultados; |
| | ** 12.Documentação dos resultados da pesquisa; |
|
| |
|
| | 3º Semestre |
| | 13.Validação das funcionalidades da solução; |
| | 14.Submissão da plataforma implantada à situações de tráfego; |
| | 15.Submissão da plataforma implantada à situações de segurança; |
| | 16.Elaboração da documentação de especificação de processos do sistema; |
|
| |
|
| * Estudar as soluções disponíveis no mundo
| | 4º Semestre |
| ** Descrever os resultados de algumas soluções [Caio]
| | 17.Comparação da solução implantada com padrão da internet tradicional; |
| * Selecionar a mais adequada
| | 18.Resposta da solução à serviços convencionais; |
| * Baixar o código do AutoI
| | 19.Documentação dos resultados da pesquisa; |
| ** Descrever os procedimentos para instalação do AutoI [Felipe]
| |
| * Executar a solução
| |
| * Estudar o código
| |
| * Corrigir os bugs
| |
| * Avaliar requisitos
| |
| * Submeter o patch
| |
| | |
| * Testar casos específicos
| |
| * Benchmarking
| |
| * Documentar
| |
| | |
| = Metodologia =
| |
| | |
| = Plano de Trabalho =
| |
| | |
| = Resumo =
| |