https://wiki.sj.ifsc.edu.br/api.php?action=feedcontributions&user=Kristhine.sf&feedformat=atomMediaWiki do Campus São José - Contribuições do(a) usuário(a) [pt-br]2024-03-29T11:22:33ZContribuições do(a) usuário(a)MediaWiki 1.35.9https://wiki.sj.ifsc.edu.br/index.php?title=Sistema_de_detec%C3%A7%C3%A3o_de_m%C3%BAsicas_em_emissoras_de_RF_r%C3%A1dio_e_WEB_r%C3%A1dio&diff=155450Sistema de detecção de músicas em emissoras de RF rádio e WEB rádio2019-03-13T23:12:09Z<p>Kristhine.sf: /* Links auxiliares */</p>
<hr />
<div>Estudo de técnicas relacionadas a detecção automática de padrões de audio. A proposta inicial não é desenvolver nenhum aplicativo para smartphone ou web, no entanto, servem de inspiração os seguintes sites e apps: [https://www.shazam.com Shazam], [https://www.soundhound.com/soundhound SoundHound], [https://www.midomi.com/ Midomi], [https://acoustid.org/chromaprint Chromaprint], [https://www.musixmatch.com/pt-br musiXmatch]. Algumas perguntas que devem ser respondidas na pesquisa: 1) quais as técnicas utilizadas na detecção; 2) Qual é a robustez para ruídos; 3) Qual é a influencia das diferentes formas de codificação de audio na detecção; 4) Quais são as patentes existentes? <br />
<br />
==Links auxiliares==<br />
*[[G6: Audio Fingerprinting | Audio Fingerprinting]] - acesso restrito.<br />
*[[G6: Audio Coding | Audio Coding]] - acesso restrito.<br />
*[[G6: TCC Kristhine FS]] - acesso restrito.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=An%C3%A1lise_de_criptografia_fim-a-fim_em_servi%C3%A7os_de_mensagens_instant%C3%A2neas_para_aplica%C3%A7%C3%B5es_corporativas&diff=145598Análise de criptografia fim-a-fim em serviços de mensagens instantâneas para aplicações corporativas2018-05-29T01:21:21Z<p>Kristhine.sf: Criou página com '==RESUMO EXPANDIDO== <center> <big><big> ;Análise de criptografia fim-a-fim em serviços de mensagens instantâneas para aplicações corporativas </big></big> :Autor: '''Kris...'</p>
<hr />
<div>==RESUMO EXPANDIDO==<br />
<br />
<center><br />
<big><big><br />
;Análise de criptografia fim-a-fim em serviços de mensagens instantâneas para aplicações corporativas<br />
</big></big><br />
<br />
:Autor: '''Kristhine Schaeffer Fertig'''<br />
:Orientador: '''Prof. Dr. Emerson Ribeiro de Mello'''<br />
:Curso: '''Engenharia de Telecomunicações'''<br />
:Instituto Federal de Santa Catarina (IFSC), São José – SC<br />
:Trabalho realizado como parte das atividades da disciplina TCC29009<br />
:''kristhine.sf@aluno.ifsc.edu.br, mello@ifsc.edu.br'' <br />
</center><br />
<br />
;Resumo:<br />
Nos últimos 10 anos, a Internet e a comunicação móvel têm reformulado intensamente a forma como vivemos e nos comunicamos no dia a dia. Surge então uma infinidade de sistemas e aplicações voltadas à comunicação multimídia em tempo real e instantânea. Para uma aplicação de mensagens instantâneas (IM) de única finalidade, independente de sua utilização em âmbito popular ou organizacional, novos métodos e protocolos já são desenvolvidos para cenários Web e Móvel. Tais serviços possuem ainda a característica de interoperabilidade e multiplataforma, sendo na maioria das vezes apresentados de forma distribuída. Assim, com este aumento da interconectividade, do número de usuários e da variedade de dados transmitidos, cresce cada vez mais a preocupação com a segurança dos dados e privacidade dos usuários de tais serviços. Este trabalho têm como objetivo analisar as principais ferramentas e atuais cenários adotados no mercado de serviços de mensagens instantâneas. Será realizado um comparativo de tais tecnologias atentando-se à aplicação de criptografia fim-a-fim com a finalidade de garantir a privacidade dos usuários e segurança de seus respectivos dados. Propõe-se ainda apresentar uma solução de estrutura básica para um serviço IM com segurança ponta a ponta (E2E). Por fim, a proposta é implementada a fim de fornecer prova de conceito e avaliar a dificuldade técnica de satisfazer os requisitos de segurança e privacidade estipulados na transmissão de informações classificadas em um ambiente de uso corporativo.<br />
<br />
;Palavras-chave: <br />
Mensagens Instantâneas. Criptografia. Fim-a-Fim.<br />
<br />
;Resumo Expandido:<br />
<br />
*[[Media:Resumo_Criptografia_E2E_em_servicos_IM.pdf | ResumoExpandido.pdf]]<br />
<br />
[[Categoria: TCC]]</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132763PTC-2017-22017-07-27T14:11:47Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || Usa dois canais TCP paralelos para intercâmbio de de dados de controle e arquivos. Garante confiabilidade, ou seja, entrega do arquivo enquanto protege de erros de transmissão. || Conjunto de comandos: USER, PASS, LIST, STOR, PORT, QUIT. || Textual (ASCII ou EBCDIC) ou binária. ( ver [https://tools.ietf.org/html/rfc959 RFC 959]) || 1- Cliente realiza conexão de controle (porta 21) com servidor (modo passivo ou ativo). 2- Com a confirmação positiva, servidor mantém a conexão de controle aberta e aguarda as solicitações de transferência. 3- Em modo de execução ativo o servidor inicia a conexão de dados. 4- Em modo de execução passivo o cliente inicia a conexão de dados para iniciar a transferência.<br />
|-<br />
|SSH ||Transferência remota de arquivos criptografados entre duas entidades. (ver [https://www.ietf.org/rfc/rfc4253.txt RFC 4253]) || || (ver [https://www.ietf.org/rfc/rfc4253.txt RFC 4253]) || ISO-10646 UTF-8 (ver [https://tools.ietf.org/html/rfc3629 RFC 3629]) || <br />
|-<br />
|SMTP || Envio de transferência de e-mail || Funciona online, encapsulado numa trama TCP/IP, por padrão na porta 25. || HELO: Inicia a comunição. Mail from: Endereço do remetente. 250 OK: Confirmação de recebmento. RCPT TO: Endereço do destinatário. DATA: Corpo da mensagem. || ASCII || https://blog.saphir.com.br/smtp-o-que-e-e-como-funciona/<br />
|-<br />
|TELNET || Permitir obter uma interface de terminais e aplicações pela Internet. || Baseia-se em uma conexão TCP para enviar dados entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex). || https://tools.ietf.org/html/rfc854 || Codificado em formato ASCII de 8 bits. || As opções do Telnet afetam separadamente cada direção do canal de dados. Assim, cada extremidade pode negociar com as opções, ou seja, definir as opções desejadas, como utilizar (DO), não utilizar (DON' T), permitir que a outra extremidade utilize (WILL), não permitir que a outra extremidade utilize (WON' T). Desta maneira, cada uma das partes pode emitir um pedido de utilização de uma opção. A outra parte deverá, então, responder se aceita ou não a utilização da opção.<br />
http://br.ccm.net/contents/286-o-protocolo-telnet#qual-e-o-principio-das-opcoes-negociadas<br />
|-<br />
|RTP || Entrega de áudio e vídeo sobre IP. || implementado sobre canal UDP. Apresenta perda. || [http://www.idc-online.com/technical_references/pdfs/data_communications/RTP_packet_header.pdf RTP Header] || Binária. || [http://www.cse.wustl.edu/~jain/books/ftp/rtp.pdf Overview] interessante do protocolo<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || Utiliza TCP como canal de comunicação. Geralmente utilizado para acesso remoto. || As mensagens possuem suas próprias RFCs e podem ser conferidas no item 10.1 de [https://www.ietf.org/rfc/rfc4251.txt RFC 4251] || Byte ([https://www.ietf.org/rfc/rfc4253.txt RFC 4253]) || Resumo neste [https://blog.myhro.info/2017/01/how-ssh-authentication-works documento] (em inglês) ||<br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132758PTC-2017-22017-07-27T14:08:44Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || Usa dois canais TCP paralelos para intercâmbio de de dados de controle e arquivos. Garante confiabilidade, ou seja, entrega do arquivo enquanto protege de erros de transmissão. || Conjunto de comandos: USER, PASS, LIST, STOR, PORT, QUIT. || Textual (ASCII ou EBCDIC) ou binária. ( ver [https://tools.ietf.org/html/rfc959 RFC 959]) || 1- Cliente realiza conexão de controle (porta 21) com servidor (modo passivo ou ativo). 2- Com a confirmação positiva, servidor mantém a conexão de controle aberta e aguarda as solicitações de transferência. 3- <br />
|-<br />
|SSH ||Transferência remota de arquivos criptografados entre duas entidades. (ver [https://www.ietf.org/rfc/rfc4253.txt RFC 4253]) || || || ISO-10646 UTF-8 (ver [https://tools.ietf.org/html/rfc3629 RFC 3629]) || <br />
|-<br />
|SMTP || Envio de transferência de e-mail || Funciona online, encapsulado numa trama TCP/IP, por padrão na porta 25. || HELO: Inicia a comunição. Mail from: Endereço do remetente. 250 OK: Confirmação de recebmento. RCPT TO: Endereço do destinatário. DATA: Corpo da mensagem. || ASCII || <br />
|-<br />
|TELNET || Permitir obter uma interface de terminais e aplicações pela Internet. || Baseia-se em uma conexão TCP para enviar dados entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex). || https://tools.ietf.org/html/rfc854 || Codificado em formato ASCII de 8 bits. || As opções do Telnet afetam separadamente cada direção do canal de dados. Assim, cada extremidade pode negociar com as opções, ou seja, definir as opções desejadas, como utilizar (DO), não utilizar (DON' T), permitir que a outra extremidade utilize (WILL), não permitir que a outra extremidade utilize (WON' T). Desta maneira, cada uma das partes pode emitir um pedido de utilização de uma opção. A outra parte deverá, então, responder se aceita ou não a utilização da opção.<br />
http://br.ccm.net/contents/286-o-protocolo-telnet#qual-e-o-principio-das-opcoes-negociadas<br />
|-<br />
|RTP || Entrega de áudio e vídeo sobre IP. || implementado sobre canal UDP. Apresenta perda. || [http://www.idc-online.com/technical_references/pdfs/data_communications/RTP_packet_header.pdf RTP Header] || Binária. || [http://www.cse.wustl.edu/~jain/books/ftp/rtp.pdf Overview] interessante do protocolo<br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132755PTC-2017-22017-07-27T14:05:56Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || Usa dois canais TCP paralelos para intercâmbio de de dados de controle e arquivos. Garante confiabilidade, ou seja, entrega do arquivo enquanto protege de erros de transmissão. || Conjunto de comandos: USER, PASS, LIST, STOR, PORT, QUIT. || Textual (ASCII ou EBCDIC) ou binária. ( ver [https://tools.ietf.org/html/rfc959 RFC 959]) || <br />
|-<br />
|SSH ||Transferência remota de arquivos criptografados entre duas entidades. (ver [https://www.ietf.org/rfc/rfc4253.txt RFC 4253]) || || || ISO-10646 UTF-8 (ver [https://tools.ietf.org/html/rfc3629 RFC 3629]) || <br />
|-<br />
|SMTP || Envio de transferência de e-mail || Funciona online, encapsulado numa trama TCP/IP, por padrão na porta 25. || HELO: Inicia a comunição. Mail from: Endereço do remetente. 250 OK: Confirmação de recebmento. RCPT TO: Endereço do destinatário. DATA: Corpo da mensagem. || ASCII || <br />
|-<br />
|TELNET || Permitir obter uma interface de terminais e aplicações pela Internet. || Baseia-se em uma conexão TCP para enviar dados entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex). || https://tools.ietf.org/html/rfc854 || Codificado em formato ASCII de 8 bits. || As opções do Telnet afetam separadamente cada direção do canal de dados. Assim, cada extremidade pode negociar com as opções, ou seja, definir as opções desejadas, como utilizar (DO), não utilizar (DON' T), permitir que a outra extremidade utilize (WILL), não permitir que a outra extremidade utilize (WON' T). Desta maneira, cada uma das partes pode emitir um pedido de utilização de uma opção. A outra parte deverá, então, responder se aceita ou não a utilização da opção.<br />
http://br.ccm.net/contents/286-o-protocolo-telnet#qual-e-o-principio-das-opcoes-negociadas<br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132754PTC-2017-22017-07-27T14:05:20Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || Usa dois canais TCP paralelos para intercâmbio de de dados de controle e arquivos. Garante confiabilidade, ou seja, entrega do arquivo enquanto protege de erros de transmissão. || Conjunto de comandos: USER, PASS, LIST, STOR, PORT, QUIT. || Textual (ASCII ou EBCDIC) ou binária. ( ver <br />
[https://tools.ietf.org/html/rfc959 RFC 959]) || <br />
|-<br />
|SSH ||Transferência remota de arquivos criptografados entre duas entidades. (ver [https://www.ietf.org/rfc/rfc4253.txt RFC 4253]) || || || ISO-10646 UTF-8 (ver [https://tools.ietf.org/html/rfc3629 RFC 3629]) || <br />
|-<br />
|SMTP || Envio de transferência de e-mail || Funciona online, encapsulado numa trama TCP/IP, por padrão na porta 25. || HELO: Inicia a comunição. Mail from: Endereço do remetente. 250 OK: Confirmação de recebmento. RCPT TO: Endereço do destinatário. DATA: Corpo da mensagem. || ASCII || <br />
|-<br />
|TELNET || Permitir obter uma interface de terminais e aplicações pela Internet. || Baseia-se em uma conexão TCP para enviar dados entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex). || https://tools.ietf.org/html/rfc854 || Codificado em formato ASCII de 8 bits. || As opções do Telnet afetam separadamente cada direção do canal de dados. Assim, cada extremidade pode negociar com as opções, ou seja, definir as opções desejadas, como utilizar (DO), não utilizar (DON' T), permitir que a outra extremidade utilize (WILL), não permitir que a outra extremidade utilize (WON' T). Desta maneira, cada uma das partes pode emitir um pedido de utilização de uma opção. A outra parte deverá, então, responder se aceita ou não a utilização da opção.<br />
http://br.ccm.net/contents/286-o-protocolo-telnet#qual-e-o-principio-das-opcoes-negociadas<br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132749PTC-2017-22017-07-27T14:01:21Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || Usa dois canais TCP paralelos para intercâmbio de de dados de controle e arquivos. Garante confiabilidade, ou seja, entrega do arquivo enquanto protege de erros de transmissão. || Conjunto de comandos: USER, PASS, LIST, STOR, PORT, QUIT. || Textual (ASCII ou EBCDIC) ou binária (modo imagem ou local) || <br />
|-<br />
|SSH ||Transferência remota de arquivos criptografados entre duas entidades. || || || ISO- 10646 UTF-8 (ver [https://tools.ietf.org/html/rfc3629 RFC 3629]) || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132745PTC-2017-22017-07-27T13:58:40Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || Usa dois canais TCP paralelos para intercâmbio de de dados de controle e arquivos. Garante confiabilidade, ou seja, entrega do arquivo enquanto protege de erros de transmissão. || Conjunto de comandos: USER, PASS, LIST, STOR, PORT, QUIT. || || <br />
|-<br />
|SSH ||Transferência remota de arquivos criptografados entre duas entidades. || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132744PTC-2017-22017-07-27T13:54:59Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || Protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || Usa dois canais TCP paralelos para intercâmbio de de dados de controle e arquivos. Garante confiabilidade, ou seja, entrega do arquivo enquanto protege de erros de transmissão. || || || <br />
|-<br />
|SSH ||Transferência remota de arquivos criptografados entre duas entidades. || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132739PTC-2017-22017-07-27T13:52:50Z<p>Kristhine.sf: /* Análise dos protocolos */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor SSH é a porta 22.<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || Funciona como roteador do correio eletrônico. É transmitido sobre o protocolo TCP, sendo composto por 3 entidades: Agente do usuário, emissor e receptor. A comunicação entre o emissor e receptor é feita através do código ASCII. <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|-<br />
|SSH || É um protocolo de rede que estabelece uma conexão criptografada em meio de comunicação não seguro na estrutura cliente-servidor. || O cliente conecta-se ao servidor através de autenticação com troca de chaves (um exemplo de troca de chaves é a de Diffie-Hellman). Ao iniciar a comunicação a autenticação e criptografia são negociados entre as entidades e a comunicação é estabelecida de forma segura, possibilitando o acesso remoto de dispositivos e transferência de arquivos. Implementado sobre o TCP. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Usa um canal UDP para intercâmbio de mensagens. Pode perder mensagens. Latências de transmissão variáveis (ex: devido a congestionamentos) podem ocorrer. || [https://www.meinbergglobal.com/english/info/ntp-packet.htm NTP Data packet] || binária (ver [https://tools.ietf.org/html/rfc5905 RFC 5905])|| Há um bom resumo [https://www.meinbergglobal.com/english/info/ntp-packet.htm neste documento].<br />
|-<br />
|FTP || Transferência de arquivos entre computadores conectados em uma rede. || || || || <br />
|-<br />
|SSH || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132730PTC-2017-22017-07-27T13:32:06Z<p>Kristhine.sf: /* Protocolos reais */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de arquivos em ambas as direções (download e upload) de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). Caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA. A porta padrão do servidor ssh é a porta 22<br />
|-<br />
|TELNET || Fornece as regras básicas para ligar um cliente a um intérprete de comando (servidor). || O protocolo Telnet baseia-se em uma conexão TCP para enviar dados em formato ASCII codificados em 8 bits entre os quais se intercalam sequências de controle Telnet. Ele fornece, assim, um sistema orientado para a comunicação, bidirecional (half-duplex), codificado em 8 bits, fácil de aplicar.<br />
|-<br />
|SMTP || Usado para a transferência de e-mail || <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Funciona apenas em redes locais e em ambientes de redes com e sem fio. || Dados e frames de informação. || || Quando um equipamento entra na rede as trocas de mensagens para a obtenção do endereço acionam o protocolo que já sincroniza o novo equipamento com a rede, e quando não há manda dados periodicamente.<br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132726PTC-2017-22017-07-27T13:29:09Z<p>Kristhine.sf: /* Protocolos reais */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de dados de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente). caracteriza-se por ser um protocolo de padrão aberto.<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados entre duas entidades.|| Modelo de comunicação é cliente e servidor, utilizando para geração das chaves públicas o algoritmo RSA.<br />
|-<br />
|??? || || <br />
|-<br />
|??? || || <br />
|-<br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Funciona apenas em redes locais e em ambientes de redes com e sem fio. || Dados e frames de informação. || || Quando um equipamento entra na rede as trocas de mensagens para a obtenção do endereço acionam o protocolo que já sincroniza o novo equipamento com a rede, e quando não há manda dados periodicamente.<br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132723PTC-2017-22017-07-27T13:27:18Z<p>Kristhine.sf: /* Protocolos reais */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente-servidor para a transferência de dados de maneira eficaz. Estabelece duas conexões TCP paralelas: uma para controle (persistente) e outra para dados (não-persistente).<br />
|-<br />
|SSH || Transferência remota de arquivos criptografados, cujo modelo de comunicação é cliente servidor|| <br />
|-<br />
|??? || || <br />
|-<br />
|??? || || <br />
| RTP || É um protocolo de redes utilizado para entregar áudio e vídeo sobre IP. || É implementado tipicamente sobre UDP e usado em conjunto com o RTCP (RTP Control Protocol). Enquanto o RTP lida com a mídia em sí, o RTCP monitora as estatísticas de transmissão e o Controle de Qualidade e lida com a sincronização de multiplos streams. ||<br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Funciona apenas em redes locais e em ambientes de redes com e sem fio. || Dados e frames de informação. || || Quando um equipamento entra na rede as trocas de mensagens para a obtenção do endereço acionam o protocolo que já sincroniza o novo equipamento com a rede, e quando não há manda dados periodicamente.<br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132720PTC-2017-22017-07-27T13:24:09Z<p>Kristhine.sf: /* Protocolos reais */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente - servidor para a transferência de dados de maneira eficaz, permitindo conexões persistentes e não-persistentes. Estabelece duas conexões: uma para controle e outra para dados.<br />
|-<br />
|SSH || || <br />
|-<br />
|??? || || <br />
|-<br />
|??? || || <br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Funciona apenas em redes locais e em ambientes de redes com e sem fio. || Dados e frames de informação. || || Quando um equipamento entra na rede as trocas de mensagens para a obtenção do endereço acionam o protocolo que já sincroniza o novo equipamento com a rede, e quando não há manda dados periodicamente.<br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132719PTC-2017-22017-07-27T13:22:44Z<p>Kristhine.sf: /* Protocolos reais */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || Utiliza um modelo cliente - servidor para a transferência de dados de maneira eficaz, permitindo conexões persistentes e não-persistentes.<br />
|-<br />
|SSH || || <br />
|-<br />
|??? || || <br />
|-<br />
|??? || || <br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Funciona apenas em redes locais e em ambientes de redes com e sem fio. || Dados e frames de informação. || || Quando um equipamento entra na rede as trocas de mensagens para a obtenção do endereço acionam o protocolo que já sincroniza o novo equipamento com a rede, e quando não há manda dados periodicamente.<br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=PTC-2017-2&diff=132716PTC-2017-22017-07-27T13:20:19Z<p>Kristhine.sf: /* Protocolos reais */</p>
<hr />
<div>= Projeto de Protocolos: Diário de Aula 2017-2 = <br />
<br />
'''Professor:''' [[Marcelo_Maia_Sobral|Marcelo Maia Sobral]]<br />
<br>'''Encontros:''' 5a feira/9:40, 6a feira/9:40 (Semana A)<br />
<br>'''Atendimento paralelo:''' 6a de 8:30 às 9:30 h / 6a de 13:30 às 14:30 h <br />
<br />
[[PTC-EngTel_(Plano_de_Ensino)| Plano de Ensino]]<br />
<br />
== Referências complementares ==<br />
<br />
* [http://www.itu.int/en/ITU-T/asn1/Pages/asn1_project.aspx ASN.1]<br />
* [http://www.rfc-editor.org/std/std68.txt Internet Standard 68 (ABNF)]<br />
* [http://www.sdl-forum.org/ SDL Forum]<br />
* [https://www.rfc-editor.org/rfc/rfc3117.txt RFC-1317: On the Design of Application Protocols]<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/hotnets.pdf Protocol Design Beyond Graph-Based Models]<br />
* [https://www.infoq.com/news/2014/07/protocol-design-sbe-thompson Protocol Design (entrevista)]<br />
* [[Introdução_C%2B%2B|Inrodução a C++ (com referências bibliográficas)]]<br />
<br />
== Avaliações ==<br />
<br />
As avaliações são de dois tipos:<br />
# '''Projetos:''' feitos em equipes de até dois alunos, são desenvolvidos ao longo da disciplina. Os resultados parciais devem ser entregues por meio de relatórios parciais, e o resultado final deve ser demonstrado na prática e descrito em um relatório conclusivo.<br />
# '''Tarefas:''' feitas individualmente, e servem para ajustar os conceitos dos projetos (podem aumentá-los ou reduzi-los).<br />
<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Aluno<br />
!Projeto 1<br />
!Projeto 2<br />
!Projeto 3<br />
!FINAL<br />
|}<br />
<br />
''Obs:'' D* = não fez a avaliação.<br />
<br />
== Softwares ==<br />
<br />
* [http://www.lionet.info/asn1c/ Compilador ASN.1]<br />
* [http://www.antlr.org/ ANTLR (Another Tool for Language Recognition)]<br />
* [http://www.coasttocoastresearch.com/ APG (ABNF Parser Generator)]<br />
* [http://spinroot.com/spin/whatispin.html SPIN Model Checker]<br />
<br />
= 27/07: Introdução =<br />
<br />
* ''Caracterização de protocolos por meio de um exemplo: sintaxe, comportamento, temporização, semântica. Princípios de projeto e propriedades desejáveis de protocolos. Análise de um protocolo real.''<br />
<br />
<br />
* '''Projeto 1:''' um protocolo de comunicação <br />
* '''Projeto 2:''' um protocolo de aplicação<br />
* '''Projeto 3:''' implementação de um protocolo padrão segundo uma especificação<br />
<br />
Um '''protocolo''' é uma parte muito importante de um sistema de comunicação. A comunicação de dados pode ser entendida como '''troca de informação entre dois dispositivos através de algum meio de comunicação'''. A comunicação ocorre no âmbito de um sistema de telecomunicações, composto por equipamentos (hardware) e programas (softwares). Um sistema básico de comunicação de dados se constitui de cinco componentes:<br />
<br />
<br />
[[imagem:Rede-intro-1.png]]<br />
<br />
<br />
# '''A mensagem''': a informação a ser transmitida. O conteúdo da mensagem, seja um texto, música, video, ou qualquer outro tipo de informação, é representada por conjuntos de '''bits''' (dígitos binários).<br />
# '''Transmissor:''' dispositivo que transmite a mensagem.<br />
# '''Receptor:''' dispositivo que recebe a mensagem.<br />
# '''Meio de comunicação:''' caminho físico por onde viaja a mensagem do transmissor até o receptor.<br />
# '''Protocolo:''' conjunto de regras que governa a comunicação de dados.<br />
<br />
<br />
Os sistemas de comunicação reais, incluídas as redes de computadores, são bem mais complexos do que esse modelo simplificado. No entanto, todos podem ser entendidos, em alguma medida, a partir desse modelo. Nesta disciplina estudam-se princípios e técnicas para projeto de protocolos, incluindo formas de verificar a consistência e correção de seu funcionamento.<br />
<br />
<br />
== Serviço e Protocolo ==<br />
<br />
Um sistema de comunicação provê '''serviços''' para as aplicações ou usuários realizarem ações que envolvam a comunicação entre sistemas através de uma rede. Por exemplo, existem serviços para transferência de arquivos, reprodução remota de videos e músicas, execução remota de programas, pesquisa por informação, e muitos outros. O conceito de ''serviço'' está relacionado ao de ''protocolo''. Um serviço é provido por entidades que interagem de acordo com um protocolo. Assim, um serviço é um dos elementos envolvidos na especificação de um protocolo. As figuras a seguir mostram a relação entre esses conceitos, primeiro apresentando somente a visão de um serviço para um usuário, e, em seguida, a relação entre serviço e protocolo.<br />
<br />
[[imagem:PTC-Servico1.png|400px]]<br />
<br>''Um serviço visto por um usuário''<br />
<br />
<br />
[[imagem:PTC-Protocolo1.png|400px]]<br />
<br>''O serviço provido pelo protocolo''<br />
<br />
== Protocolos reais ==<br />
<br />
Que protocolos existentes despertam suas curiosidades sobre os detalhes de seus projetos ? Identifiquem alguns protocolos, e anotem suas finalidades e características. <br />
<br />
{| border=1<br />
!Protocolo<br />
!Finalidade<br />
!Características<br />
|-<br />
|NTP || Sincronizar os relógios dos computadores ligados a rede.||Utiliza uma versão do algoritmo de Marzullo para determinar o tempo dos servidores corrigindo os efeitos da variação da latência da rede. Utiliza uma hierarquia mestre-escravo onde o servidor envia o horário UTC aos equipamentos da rede, enviando as informações por UDP.<br />
|-<br />
|FTP || Transferência de arquivos entre máquinas em uma rede TCP/IP || <br />
|-<br />
|??? || || <br />
|-<br />
|??? || || <br />
|-<br />
|??? || || <br />
|}<br />
<br />
=== Análise dos protocolos ===<br />
<br />
De acordo com Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo é composto por cinco elementos:<br />
# O '''serviço''' oferecido pelo protocolo<br />
# As '''considerações''' sobre o ambiente em que o protocolo é executado<br />
# O '''vocabulário''' de mensagens usadas para implementar o protocolo<br />
# A '''codificação''' (ou formato) de cada mensagem do vocabulário<br />
# O '''comportamento''', definido por ''regras de intercâmbio'' responsáveis pela consistência das trocas de mensagens<br />
<br />
<br />
Com base nesses elementos, deve-se complementar ou adequar a análise dos protocolos selecionados:<br />
<br />
{| border=1<br />
!Protocolo<br />
!Serviço<br />
!Ambiente de execução<br />
!Vocabulário<br />
!Codificação<br />
!Comportamento<br />
|-<br />
|NTP || Sincronização dos relógios dos computadores ligados a rede. || Funciona apenas em redes locais e em ambientes de redes com e sem fio. || Dados e frames de informação. || || Quando um equipamento entra na rede as trocas de mensagens para a obtenção do endereço acionam o protocolo que já sincroniza o novo equipamento com a rede, e quando não há manda dados periodicamente.<br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|-<br />
|??? || || || || || <br />
|}<br />
<br />
== Propriedades desejáveis de um protocolo ==<br />
<br />
Ainda segundo Gerard Holzmann, no [http://tele.sj.ifsc.edu.br/~msobral/ptc/docs/holzmann/cap-2.pdf capítulo 2] de seu livro ''Design and Validation of Computer Protocols'', um protocolo possui algumas propriedades desejáveis:<br />
<br />
* '''Simplicidade:''' um protocolo bem estruturado pode ser construído com um pequeno número de partes bem projetadas e bem entendidas.<br />
* '''Modularidade:''' um protocolo que realiza uma função complexa pode ser construído com partes menores que interagem de maneira simples e bem definida. Cada parte menor é um protocolo leve que pode ser desenvolvido separadamente, verificado, implementado e mantido.<br />
* '''Adequação:''' um protocolo bem formado não é incompleto, nem possui funções que nunca são de fato utilizadas. Um protocolo bem formado se limita aos recursos existentes, além de ser estável e adaptável.<br />
* '''Robustez:''' um protocolo robusto deve funcionar bem em condições normais, e também em situações imprevistas. Ele deve conseguir lidar com cada possível sequência de ações, em todas as possíveis condições. Ele deve ter um projeto mínimo, de forma a remover considerações não essenciais que poderiam impedir sua adaptação a condições não antecipadas.<br />
* '''Consistência:''' protocolos não devem apresentar interações que os levem a falhar, tais como ''deadlocks'', ''livelocks'' e terminações inesperadas.<br />
<br />
<br />
A figura a seguir mostra a arquitetura do protocolo de enlace [https://tools.ietf.org/html/rfc1661 PPP] como exemplo de simplicidade e modularidade:<br />
<br />
[[imagem:PTC-Ppp-estrutura.png|400px]]<br />
<br />
<br />
Robustez e consistência são aspectos comportamentais do protocolo, que envolvem portanto a dinâmica de seu funcionamento. O comportamento de um protocolo pode ser descrito de algumas formas, sendo usual utilizar diagramas. A figura a seguir apresenta o comportamento em alto-nível do protocolo PPP (mas não significa que dela se possa concluir que ele seja robusto ou consistente):<br />
<br />
[[imagem:PTC-Ppp-comportamento.png|600px]]<br />
<br />
== Diretrizes de projeto ==<br />
<br />
No mesmo capÍtulo 2 de seu livro, Gerard Holzmann enumera dez regras de projeto de um protocolo:<br />
# '''Definição do problema:''' certifique-se de que o problema esteja bem definido, com a identificação de todos os critérios de projeto, requisitos e restrições antes de iniciar um projeto.<br />
# '''Definição do serviço:''' deve-se definir o serviço a ser realizado em cada nível de abstração antes de decidir que estruturas devem ser usadas para implementá-los (''o que'' vem antes de ''como'').<br />
# '''Funcionalidades externas primeiro:''' projete a funcionalidade ''externa'' antes da ''interna''. Primeiro considere a solução como uma caixa-preta e decida como ela interage com seu ambiente. Depois decida como a caixa-preta pode ser organizada internamente. Provavelmente isso consiste de caixas-pretas menores que podem ser refinadas de forma similar.<br />
# '''Mantenha a simplicidade:''' protocolos extravagantes são mais propensos a ter ''bugs'' que protocolos simples. Eles são mais difíceis de implementar, verificar e comumente menos eficientes. Existem poucos problemas realmente complexos em projetos de protocolos. Problemas que aparentam serem complexos costumam ser problemas misturados. A tarefa dos projetistas é identificar os problemas mais simples, separá-los, e então resolvê-los individualmente.<br />
# '''Preservar independência:''' não conectar o que for independente, o que significa separar questões ortogonais.<br />
# '''Mantenha o projeto extensível:''' não introduza o que for imaterial. Não restrinja o que for irrelevante. Um bom projeto é facilmente extensível, e resolve uma classe de problemas ao invés de uma única instância.<br />
# '''Crie um protótipo:''' antes de implementar um projeto, crie um protótipo de alto-nível, e verifique se os critérios do projeto são atingidos.<br />
# '''Torne-o eficiente:''' implemente o projeto, meça seu desempenho e, se necessário, otimize-o.<br />
# '''Verifique a implementação:''' confira se a implementação final otimizada é equivalente ao protótipo de alto-nível que foi verificado.<br />
# '''Não pule as regras 1 a 7'''<br />
<br />
== TAREFA: um protocolo imaginário ==<br />
<br />
Imagine um protocolo para transferência incremental de arquivo. Esse protocolo deve prover a transferência de um arquivo entre dois computadores, de forma que o conteúdo E os atributos de um arquivo sejam devidamente copiados. Se o arquivo já existir no computador de destino, ele deve ser atualizado. Sendo assim:<br />
# Especifique o serviço provido pelo protocolo<br />
# Faça considerações sobre o ambiente de execução do protocolo (ex: o tipo de canal de comunicação usado e suas características)<br />
# Defina seu vocabulário, e também a codificação de mensagens a ser adotada<br />
# Descreva seu comportamento<br />
<br />
Ao final, implemente esse protocolo usando seus conhecimentos sobre redes de computadores e sistemas distribuídos. OBS:<br />
* o canal de comunicação deve ser baseado em um protocolo de transporte. Isso elimina a possibilidade de usar protocolos de aplicação, tais como HTTP (e, por consequência, implementar algo na fa forma de web service ou coisa parecida)<br />
* o arquivo deve ser copiado sem erros, e a cópia deve apresentar o mesmo nome e atributos que o original<br />
<br />
<br />
A entrega da especificação e do protocolo implementado deve ser feita '''até dia 04/08'''.<br />
<br />
= 28/07: Projeto 1: um protocolo de comunicação =<br />
<br />
Um protocolo de comunicação está relacionado aos mecanismos necessários para a entrega de mensagens entre duas aplicações quaisquer. Considerando uma arquitetura de redes em camadas como TCP/IP, protocolos de comunicação correspondem às camadas de enlace até transporte. Questões como garantia de entrega, controle de sequência, tratamento de erros, sincronização, estabelecimento e término de sessão, multiplexação e delimitação de mensagens, entre possivelmente outras, fazem parte do projeto de tais protocolos. Para introduzir o projeto de um protocolo de comunicação, o primeiro projeto da disciplina envolve um protocolo para estabelecimento de enlace sem-fio ponto-a-ponto.<br />
<br />
<br />
Considere o caso de uma nova interface de rede sem-fio composta por um transceiver RF capaz de transmitir a distâncias de até 1 km. No caso de distâncias como essa, a taxa de transmissão possível de ser obtida é de 2400 bps, porém distâncias menores possibilitam taxas maiores, até um máximo de 19200 bps. Esse transceiver pode ser usado como uma interface serial do tipo [https://en.wikipedia.org/wiki/Universal_asynchronous_receiver/transmitter UART]. Portanto, com ele podem-se criar enlaces de média distância e baixas taxas de transmissão.<br />
<br />
<br />
O transceiver RF usado como UART proporciona uma camada física, cuja interface de acesso a serviço oferece operações de envio e recepção de bytes. Nenhuma facilidade para delimitação de mensagens, endereçamento, sincronização e tratamento de erros é fornecida. De fato, tais serviços devem ser implementados em um protocolo de enlace que use esse transceiver como camada física.<br />
<br />
<br />
O projeto 1 envolve o desenvolvimento de um protocolo de comunicação usando esse transceiver RF, de forma a oferecer um serviço de comunicação com essas características.<br />
<br />
== O transceiver RF APC 220 ==<br />
<br />
O transceiver RF a ser utilizado se chama [http://www.appcon.com.cn/en/productshow.php?cid=6&id=28 APC 220]. Alguns documentos podem ser úteis:<br />
* [http://www.dfrobot.com/image/data/TEL0005/APC220_Datasheet.pdf Data sheet]<br />
* [http://www.robotshop.com/media/files/PDF/dfrobot-apc220-manual.pdf Manual]<br />
* [http://blog.filipeflop.com/wireless/modulo-rf-apc220-arduino.html Um tutorial]<br />
* [http://www.dfrobot.com/wiki/index.php?title=APC220_Radio_Data_Module%28SKU:TEL0005%29 Outro tutorial]<br />
<br />
== Um primeiro experimento ==<br />
<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz A classe Serial]<br />
<br />
<br />
O primeiro contato com o transceiver RF envolve escrever um programa que transmita a mensagem ''Hello world!'' de um computador a outro usando um enlace sem-fio. Para isso, deve-se:<br />
# Configurar dois transceivers RF<br />
# Conectá-los a dois computadores diferentes usando adaptadores USB<br />
# Testar a comunicação usando programa para comunicação serial (ex: [http://freecode.com/projects/gtkterm gtkterm], [http://linux.die.net/man/8/picocom picocom], [http://linux.die.net/man/1/minicom minicom]). '''OBS:''' ver [http://forum.arduino.cc/index.php?topic=58591.0 esta observação sobre um detalhe quanto ao uso do transceiver via USB].<br />
# Escrever um programa que se comunique por meio dos transceivers. Para isso podem ser úteis:<br />
#* [http://www.tldp.org/HOWTO/Serial-Programming-HOWTO/ Serial Programming HOWTO]<br />
#* [https://en.wikibooks.org/wiki/Serial_Programming/Serial_Linux Serial Programming/Serial Linux]<br />
#* [http://pubs.opengroup.org/onlinepubs/7908799/xbd/termios.html Documentação sobre termios]<br />
<br />
<br />
{{collapse top|A serial modelada como uma classe C++}}<br />
* [http://tele.sj.ifsc.edu.br/~msobral/ptc/proj1/serial.tgz Uma implementação da classe Serial]<br />
<br />
<syntaxhighlight lang=c><br />
#ifndef SERIAL_H<br />
#define SERIAL_H<br />
<br />
#include <termios.h><br />
<br />
class Serial {<br />
public:<br />
Serial();<br />
Serial(const char * path, int rate);<br />
Serial(const Serial& orig);<br />
virtual ~Serial();<br />
int get() { return tty_fd;}<br />
bool cca();<br />
int write(const char * buffer, int len);<br />
int read(char * buffer, int len);<br />
int read(char * buffer, int len, bool block); <br />
char read_byte();<br />
private:<br />
int tty_fd;<br />
};<br />
<br />
#endif /* SERIAL_H */<br />
</syntaxhighlight>''serial.h''<br />
<br />
<br />
<syntaxhighlight lang=c><br />
#include <iostream><br />
#include "Serial.h"<br />
<br />
using namespace std;<br />
<br />
int main() {<br />
Serial rf("/dev/ttyUSB0", B9600);<br />
string msg = "um teste ...\r\n";<br />
char buffer[32];<br />
<br />
int n = rf.write(msg.c_str(), msg.size());<br />
<br />
cout << "Enviou " << n << " bytes" << endl;<br />
<br />
n = rf.read(buffer, 32);<br />
<br />
cout << "Recebeu " << n << " bytes: ";<br />
<br />
cout.write(buffer, n);<br />
<br />
cout << endl;<br />
}<br />
</syntaxhighlight>''main.cpp: exemplo de uso da classe serial''<br />
{{collapse bottom}}<br />
<br />
=== Configuração no VirtualBox ===<br />
<br />
O transceiver deve ser conectado a porta USB do computador. O Linux o reconhece e cria o arquivo de dispositivo ''/dev/ttyUSB0'' a ele associado. Com isso a máquina virtual VirtualBox deve ser configurada da seguinte forma:<br />
# Habilitar a primeira porta serial (COM1)<br />
# O modo dessa serial deve ser ''Dispositivo no hospedeiro''<br />
# O caminho do dispositivo deve ser ''/dev/ttyUSB0''<br />
<br />
[[imagem:PTC-Vbox-serial.png|600px]]<br />
<br />
== TAREFA: início do protocolo de enlace ==<br />
<br />
Implemente a delimitação de mensagens do seu protocolo de enlace, de forma que mensagens de tamanho variável possam ser transmitidas e corretamente recebidas. Essas mensagens pode ter entre 8 e 1024 bytes. Em seguida, use-as para transmitir um arquivo através do enlace sem-fio.<br />
<br />
'''DICA:''' Ver capítulo 11 do livro "Comunicação de Dados e Redes de Computadores", de Behrouz Forouzan, ou capítulo 5 do livro "Redes de Computadores" de Andrew Tanenbaum.</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=RED2-EngTel_(p%C3%A1gina)&diff=99109RED2-EngTel (página)2015-12-02T18:01:08Z<p>Kristhine.sf: /* 07/11 - Ensaios finais sobre MPLS e Desempenho de protocolos de Redes Ponto à Ponto e Frame Relay */</p>
<hr />
<div>'''Professores da Unidade Curricular'''<br />
<br />
{{Professor|2015-2|[[Jorge Henrique B. Casagrande]] }}<br />
{{Professor|2015-1|[[Jorge Henrique B. Casagrande]] [[RED29005 2015-1|(Diario de aulas)]]}}<br />
{{Professor|2014-2|[[Jorge Henrique B. Casagrande]] [[RED29005 2014-2|(Diario de aulas)]]}}<br />
{{Professor|2014-1|[[Jorge Henrique B. Casagrande]] [[RED29005 2014-1|(Diario de aulas)]]}}<br />
<br />
<br />
= [[RED2-EngTel|Carga horária, Ementas, Bibliografia]]=<br />
<br />
<br />
=[[RED2-EngTel (Plano de Ensino) | Plano de Ensino]]=<br />
<br />
=Dados Importantes=<br />
''Professor'': [[Jorge Henrique B. Casagrande]]<br />
<br>''Email'': casagrande@ifsc.edu.br<br />
<br>''Atendimento paralelo'': 2as e 6as das 17:35 às 18:35h (Sala dos professores de TELE - ao lado da reprografia)<br />
<br> ''Endereço do grupo'': https://www.facebook.com/groups/667983626639907/<br />
<br> ''Link alternativo para Material de Apoio da disciplina'': http://www.sj.ifsc.edu.br/~casagrande/RED<br />
<br> Muitos conteúdos da disciplina estão sendo extraídos do material do professor '''Marcelo Sobral''' o qual já registro aqui meus agradecimentos pela autorização e apoio. Alguns deles foram inseridos ou adaptados para se ajustar ao planejamento ou perfil da turma.<br />
<br><br> Toda vez que voce encontrar a marcação <math>\blacklozenge</math> ao lado de alguma atividade, significa que essa atividade estará sendo computada na avaliação como AE ou AI. O prazo estabelecido para entrega estará destacado ao lado da atividade. Portanto, não perca o prazo limite para entrega. '''Atividades entregues fora do prazo não serão aceitas!'''<br />
<br />
=Avaliações=<br />
<br />
=Resultados das Avaliações=<br />
<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" <br />
!Matrícula<br />
!Aluno<br />
!AE1<br />
!AE2<br />
!AI<br />
!A1<br />
!A2<br />
!A3<br />
!A4<br />
!A5<br />
!REC A1<br />
!REC A2<br />
!REC A3<br />
!REC A4<br />
!REC A5<br />
!MÉDIA<br />
!CONCEITO<br />
|-<br />
|122001993-3||Anderson || || ||np || || || || || || || || || || || ||<br />
|-<br />
|122001504-0||Carlos || || ||np || || || || || || || || || || || ||<br />
|-<br />
|132002623-0||Gabriel Cantu || || ||np || || || || || || || || || || || ||<br />
|-<br />
|122002394-9||Gabriel de Souza || || ||np || || || || || || || || || || || ||<br />
|-<br />
|121003282-1||Gustavo Constante || || ||np || || || || || || || || || || || ||<br />
|-<br />
|131001065-0||Gustavo Zacchi || || ||np || || || || || || || || || || || ||<br />
|-<br />
|132002999-0||Helenluciany|| || ||np || || || || || || || || || || || ||<br />
|-<br />
|131004419-8||Iago || || ||np || || || || || || || || || || || ||<br />
|-<br />
|131005150-0||Jessica || || ||np || || || || || || || || || || || ||<br />
|-<br />
|121000492-5||Katharine || || ||np || || || || || || || || || || || ||<br />
|-<br />
|121000484-4||Kristhine || || ||np || || || || || || || || || || || ||<br />
|-<br />
|132004514-6||Letícia || || ||np || || || || || || || || || || || ||<br />
|-<br />
|132002264-2||Lucas || || ||np || || || || || || || || || || || ||<br />
|-<br />
|131005334-0||Marcos || || ||np || || || || || || || || || || || ||<br />
|-<br />
|132004278-3||Maria Luiza|| || ||np || || || || || || || || || || || ||<br />
|}<br />
<br />
<br />
<br />
'''LEGENDA E DETALHES'''<br />
<br />
;'''AE''' = Atividades Extras: 10% da Avaliação - abrange uma ou mais tarefas a serem divulgadas ao longo do semestre;<br />
;'''AI''' = Avaliação Individual: 10% da Avaliação final - abrange desempenho, assiduidade, cumprimento de tarefas em sala ou de listas de exercícios;<br />
;'''An''' = Avaliação ''n'': 20% da Avaliação (n=5) - Programadas para cada parte do programa;<br />
;'''REC An''' = Recuperação da Avaliação An: A recuperação de todas An serão em data única e o aluno só tem a obrigação de recuperar An<60;<br />
;'''np''' = não publicado aqui.<br />
;'''NF''' = Nota Final com critério de arredondamento de +/-5 pontos considerando a fórmula abaixo: '''NF''' = 0,16(soma{MaiorNota{An,REC An}}) + 0,1(médiaAE) + 0,1(AI)<br />
<br />
Se '''NF''' < 60 = '''D''' --> '''Reprovado''' <br><br />
Se 60 =< '''NF''' < 75 = '''C''' --> '''Aprovado''' <br><br />
Se 75 =< '''NF''' < 90 = '''B''' --> '''Aprovado'''<br><br />
Se '''NF''' >= 90 = '''A''' --> '''Aprovado'''<br><br />
<br />
=Recados Importantes=<br />
<br />
<br> '''Uso da Wiki:''' Todo o repositório de material de apoio e referências de nossas aulas passam a usar a Wiki de tele. Para interação fora da sala de aula, acessem nosso [https://www.facebook.com/groups/667983626639907/ grupo] do facebook. <br />
<br />
<br> '''ATENÇÃO:''' Uma avaliação só pode ser recuperada somente se existir justificativa reconhecida pela coordenação. Desse modo, deve-se protocolar a justificativa no prazo de 48 horas, contando da data e horário da avaliação, e aguardar o parecer da coordenação. O não cumprimento desse procedimento implica a impossibilidade de fazer a recuperação, e assim a reprovação na disciplina.<br />
<br />
=Material de Apoio=<br />
<br />
;Atividades extra sala de aula<br />
<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/lista1_2014_2.pdf LISTA1] de exercícios para a avaliação A1<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/lista2_2014_2.pdf LISTA2] de exercícios para a avaliação A2<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/lista3_2015_2.pdf LISTA3] de exercícios para a avaliação A3<br />
:*[http://tele.sj.ifsc.edu.br/~casagrande/RED/lista4_2014_2.pdf LISTA4] de exercícios para a avaliação A4<br />
<br />
;Slides utilizados durante algumas aulas<br />
<br />
:* [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/redes_circuitos_virtuais_FR.pdf Redes Frame Relay] <br />
<br />
:* [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/protocolos_pp.pdf Protocolos Ponto à Ponto] <br />
<br />
:* [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/InterfacesDigitais.pdf Interfaces Digitais] <br />
<br />
:* [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/modens.pdf Modens e enlaces de teste] <br />
<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/slides/lan.pdf REDES LOCAIS]<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/slides/vlan.pdf IEEE802.3q VLAN]<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/slides/stp.pdf IEEE802.3d]<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/slides/ieee.pdf Arquitetura IEEE802.3]<br />
:* [http://tele.sj.ifsc.edu.br/~casagrande/RED/slides/wlan.pdf Conceitos básicos da arquitetura IEEE802.11]<br />
<br />
<br />
;Manuais e outros<br />
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/manuais/Guia_DT2048_SHDSL_T_E_S_VG_210.5088.00-1.pdf Guia Rápido de Configuração Modem DT2048SHDSL;]<br />
* [http://tele.sj.ifsc.edu.br/~casagrande/RED/apoio/Manual_NR-2G_3200_e_4200.pdf manual Router NR2G] da Digitel;<br />
* [http://www.sj.ifsc.edu.br/~casagrande/RED/apoio/Globalink3420guia.pdf guia rápido de configuração Globalink UP3420;] <br />
* [http://www.sj.ifsc.edu.br/~casagrande/RED/apoio/Globalink3420.pdf Manual de configuração Gloalink3420;] <br />
* [http://www.sj.ifsc.edu.br/~casagrande/RED/apoio/DT34.pdf Manual de configuração DT34.] <br />
* [http://www.sj.ifsc.edu.br/~casagrande/RED/apoio/DAS-3324.pdf Manual DSLAM DLINK DAS3324.] <br />
* [http://www.sj.ifsc.edu.br/~casagrande/RED/apoio/DAS-3324guia.pdf Guia rápido DSLAM DLINK DAS3324.]<br />
* [http://www.cisco.com/warp/cpropub/45/tutorial.htm Tutorial sobre a interface CLI de roteadores Cisco]<br />
* [http://www.cisco.com/en/US/tech/tk713/tk507/technologies_tech_note09186a008019cfa7.shtml#ppp01 Resolução de problemas com PPP em roteadores Cisco]<br />
* [http://www.cisco.com/en/US/products/hw/routers/ps221/products_password_recovery09186a0080094773.shtml Recuperação de senha em roteadores Cisco 1700 e 1800]<br />
<br />
<br />
== Bibliografia ==<br />
<br />
* ''Redes de Computadores e a Internet, 5a edição'', de James Kurose.<br />
* ''Redes de Computadores, 4a edição'', de Andrew Tanenbaum.<br />
* ''Comunicação de Dados e Redes de Computadores, 4a edição'', de Behrouz Forouzan.<br />
<br />
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs.html Links para outros materiais, normas, artigos, e apostilas do prof. Jorge Casagrande]<br />
* [http://books.google.com/books?id=C9ZN-jYKHpMC&printsec=frontcover&dq=forouzan&hl=pt-BR&ei=fvt2TP3eCMH58Aa77cS1Bw&sa=X&oi=book_result&ct=result&resnum=3&ved=0CDMQ6AEwAg#v=onepage&q&f=false Comunicação de dados e Redes de Computadores, de Berhouz Forouzan (alguns capítulos no Google Books)]<br />
<br />
Para pesquisar o acervo das bibliotecas do IFSC:<br />
* [http://biblioteca.ifsc.edu.br/sophia/ Acesso ao acervo da Biblioteca do IFSC]<br />
<br />
== Softwares ==<br />
<br />
* [[Netkit]]: possibilita criar experimentos com redes compostas por máquinas virtuais Linux<br />
* [http://tele.sj.ifsc.edu.br/~msobral/IER/ipkit/ IPKit]: um simulador de encaminhamento IP (roda direto dentro do navegador)<br />
<br />
=Diário de aulas RED29005 - 2015-2 - Prof. Jorge H. B. Casagrande=<br />
<br />
{{Collapse top |29/07 - Redes de Acesso}}<br />
<br />
==29/07 - Redes de Acesso ==<br />
<br />
* Apresentação da disciplina e plano de ensino;<br />
* Visão geral de uma WAN e uma rede de acesso; <br />
* Componentes de uma infra-estrutura de telecomunicações;<br />
* '''Tarefa pra casa''': Fazer uma leitura das '''seções 1.1 à 1.3 (inclusive)''' do livro do Kurose, 5a edição e além das explicações básicas sobre as redes de acesso colocadas em sala faça um quadro resumo que compare as principais tecnologias de '''redes de acesso''' (Dial-up, xDSL, HFC, FTTH e Wireless) em termos de: Alcance, custo, disponibilidade e banda passante (Mbps) sempre no ponto de vista do PROVEDOR DE SERVIÇOS (ISP). Para completar algumas informações de seu resumo use as outras bibliografias indicadas de nossa disciplina, a revista RTI (www.rtionline.com.br - edição julho/15) ou mesmo a googlelândia... ;)<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |05/10 - Redes Privadas }}<br />
<br />
==05/10 - Redes Privadas ==<br />
<br />
* Discussão sobre as redes de acesso tabuladas da aula anterior<br />
* A rede de acesso ADSL a partir rede externa de telefonia pública;<br />
* A Linha Privativa de Comunicação de Dados (LPCD);<br />
* A banda passante e os meios metálicos de transmissão;<br />
* O modelo básico de comunicação de dados;<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |07/10 - Redes Privadas e Redes de Longa Distância - WAN }}<br />
<br />
==07/10 - Redes Privadas e Redes de Longa Distância - WAN==<br />
<br />
* Recuperação de conteúdos por conta de alunos que se integraram na turma.<br />
* O Serviço de Linha Dedicada Digital (SLDD) como base na formação de Redes Privativas;<br />
* Experimento: Comunicação entre Computadores via porta serial;<br />
<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |14/10 - Redes Privadas e Redes de Longa Distância - WAN }}<br />
<br />
* Evolução das Redes Locais baseadas em hospedeiros para as Redes Privativas de longa distância;<br />
* Da Unidade de Derivação Digital (UDD) para os ServerSwitches ou switches KVM;<br />
* A Multiplexação como solução no compartilhamento e otimização do uso de enlaces de transmissão.<br />
* Início dos trabalhos para a construção de 3 nós de uma rede Frame Relay<br />
<br />
'''ATENÇÃO: Leitura dos itens 6.1, 8.3 e 18.1 do Forouzan'''<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |19/10 - Redes Virtuais - Frame Relay }}<br />
<br />
==19/10 - Redes Virtuais - Frame Relay ==<br />
<br />
* Construção da rede Frame Relay no laboratório.<br />
<br />
<br />
Para esta atividade já está implementada uma rede composta por três roteadores da Digitel, que estarão interligados como mostrado abaixo:<br />
<br />
[[imagem:Rede-modems.png|600px]]<br />
<br />
A rede contém dois enlaces dedicados ponto-à-ponto (simulando duas SLDDs formadas por LPCDs à 2 fios) com modems digitais operando a 2 Mbps. Os Modens da DIGITEL modelo DT2048SHDSL estão configurados da seguinte forma: (chaves em ON) <br />
* Modens do rack central: DIP1-todas; DIP2-7,8; DIP3-todas OFF; DIP4-5 - Modo NTU (terminação de rede), relógio interno, 2048Kbps, e interface V.35 padrão ISO2110;<br />
* Modens do rack direito e esquerdo: DIP1-todas; DIP2-7,8; DIP3-todas OFF; DIP4-5 - Modo LTU (terminação de linha), relógio regenerado, 2048Kbps, e interface V.35 padrão ISO2110;<br />
<br />
Todos os roteadores estão configurados com protocolo FRAME RELAY em suas interfaces serias WAN e rodando o algoritmo de roteamento RIP em sua forma mais básica para evitar a configuração de rotas estáticas na interligação das LANs do switches direito e esquerdo.<br />
<br />
;Iniciando o experimento<br />
<br />
# Acesse a interface de gerência (console) do roteador R1 ou R2. O roteador R1 está no rack direito (no ponto de vista da sala), o roteador R3 está no rack central, e R2 está no rack esquerdo. Para acessar a console, faça o seguinte:<br />
## Conecte o cabo serial específico na interface serial RS232 do seu computador. Conecte esse cabo também na interface ''console'' do roteador, que fica no painel traseiro. Como os roteadores estão distantes das bancadas, será necessário usar as tomadas azuis, que conectam as bancadas aos racks.<br />
## Execute o programa ''minicom'', que abre um terminal de texto via porta serial. Ele deve ser configurado para se comunicar pela porta serial ''/dev/ttyS0'', com 57600 bps, 8 bits de dados e 1 stop-bit (isso aparece descrito assim: 57600 8N1) e sem controles de fluxo. <syntaxhighlight lang=bash><br />
sudo minicom -s<br />
</syntaxhighlight><br />
## Se o ''minicom'' estiver correto, você deverá ver a interface CLI do roteador (''Command Line Interface''). Caso contrário, confira se o cabo serial está bem encaixado, e se os parâmetros do ''minicom'' estão certos.<br />
# O login e senha para acessar a configuração dos routers é "nr2g" e "digitel" respectivamente. Ao entrar na CLI avalie a configuração geral dos routers com o comando DUMP ALL;<br />
# Estando os links ativos nas WANs, voce pode acessar qualquer router usando a facilidade do protocolo TELNET. Para tanto, dentro da CLI do router aplique o comando EXEC TELNET [IP da WAN ou LAN]. Voce também podem acessa-los por qualquer computador das redes direita ou esquerda, desde que esses estejam na mesma subrede das interfaces LAN dos routers. Uma vez estando na CLI de um dos routers, voce pode acessar os demais com EXEC TELNET;<br />
# Observe se a configuração dos routers está como o previsto na janela abaixo. Talvez voce precise ajustar a configuração em algum roteador.<br />
# Faça a configuração Básica dos PCs e Roteadores NR2G com protocolo FRAME RELAY. Esta configuração já permite que a rede se conecte a internet através da porta LAN0 do router CENTRAL, desde que as configurações de rotas nos PCs de cada subrede e do professor sejam aplicadas conforme na sequência.<br />
#* '''R1:''' <syntaxhighlight lang=text><br />
DIREITA > <br />
SET LAN LAN0 IP 192.168.10.254 MASK 255.255.255.0 BROADCAST 192.168.10.255 <br />
SET LAN LAN0 UP <br />
SET LAN LAN1 IP 192.168.20.254 MASK 255.255.255.0 BROADCAST 192.168.20.255 <br />
SET LAN LAN1 UP <br />
<br />
SET WAN WAN0 PROTO FRAMERELAY PROTOCOL ANSI DCE FALSE CLOCK EXTERNAL TXINV FALSE<br />
SET WAN WAN0 TRAFFIC-SHAPE FALSE T391 10 T392 15 N391 6 N392 3 N393 4<br />
SET WAN WAN0-PVC0 DLCI 100 MTU 1500 IP 10.1.1.2 MASK 255.255.255.252 PEER 10.1.1.1<br />
SET WAN WAN0 UP <br />
SET WAN WAN1 PURGE <br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0-PVC0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0-PVC0 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET ROUTES DEFAULT GW1 10.1.1.1 COST1 0 <br />
SET ROUTES UP <br />
CONFIG SAVE<br />
<br />
</syntaxhighlight><br />
#* '''R2:''' <syntaxhighlight lang=text><br />
ESQUERDA > <br />
SET LAN LAN0 IP 192.168.30.254 MASK 255.255.255.0 BROADCAST 192.168.30.255 <br />
SET LAN LAN0 UP <br />
SET LAN LAN1 IP 192.168.40.254 MASK 255.255.255.0 BROADCAST 192.168.40.255 <br />
SET LAN LAN1 UP <br />
<br />
SET WAN WAN0 PROTO FRAMERELAY PROTOCOL ANSI DCE FALSE CLOCK EXTERNAL TXINV FALSE<br />
SET WAN WAN0 TRAFFIC-SHAPE FALSE T391 10 T392 15 N391 6 N392 3 N393 4<br />
SET WAN WAN0-PVC0 DLCI 100 MTU 1500 IP 10.1.1.6 MASK 255.255.255.252 PEER 10.1.1.5<br />
SET WAN WAN0 UP <br />
SET WAN WAN1 PURGE <br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0-PVC0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0-PVC0 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET ROUTES DEFAULT GW1 10.1.1.5 COST1 0 <br />
SET ROUTES UP<br />
CONFIG SAVE<br />
<br />
</syntaxhighlight><br />
#* '''R3:''' <syntaxhighlight lang=text><br />
CENTRAL > <br />
SET LAN LAN0 PURGE <br />
SET LAN LAN1 PURGE <br />
<br />
SET WAN WAN0 PROTO FRAMERELAY PROTOCOL ANSI DCE TRUE CLOCK EXTERNAL TXINV FALSE<br />
SET WAN WAN0 TRAFFIC-SHAPE FALSE T391 10 T392 15 N391 6 N392 3 N393 4<br />
SET WAN WAN0-PVC0 DLCI 100 MTU 1500 IP 10.1.1.1 MASK 255.255.255.252 PEER 10.1.1.2<br />
SET WAN WAN0 UP<br />
<br />
SET WAN WAN1 PROTO FRAMERELAY PROTOCOL ANSI DCE TRUE CLOCK EXTERNAL TXINV FALSE<br />
SET WAN WAN1 TRAFFIC-SHAPE FALSE T391 10 T392 15 N391 6 N392 3 N393 4<br />
SET WAN WAN1-PVC0 DLCI 100 MTU 1500 IP 10.1.1.5 MASK 255.255.255.252 PEER 10.1.1.6<br />
SET WAN WAN1 UP<br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0-PVC0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0-PVC0 AUTH TYPE NONE <br />
SET RIP WAN1-PVC0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN1-PVC0 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET LAN LAN0 IP 192.168.1.231 MASK 255.255.255.0 BROADCAST 192.168.1.255 UP <br />
SET ROUTES DEFAULT GW1 192.168.1.1 COST1 0 <br />
SET ROUTES UP <br />
CONFIG SAVE <br />
<br />
</syntaxhighlight><br />
# Para conferir as configurações das interfaces, use o comando ''show'' seguido da interface. Exemplo: <syntaxhighlight lang=text><br />
# SHOW WAN WAN0 ALL<br />
# Para as rotas construidas dinamicamente pelo protocolo RIP:<br />
# SHOW ROUTES ALL<br />
</syntaxhighlight><br />
# Assim que os enlaces forem estabelecidos, o que pode ser conferido com o comando ''show'' interface aplicado às interfaces, ''conclua'' a configuração da rede (rotas nos pcs e roteadores). Ela deve ser configurada de forma que um computador possa se comunicar com qualquer outro computador da outra rede, e também acessar a Internet. Para isso, use os comandos nos PCs como:<br />
#* sudo ifconfg eth0 x.x.x.x netmask m.m.m.m up - para atribuir outro endereço na placa de rede<br />
#* sudo route add default gw x.x.x.x - para atribuir um novo gateway para a placa de rede<br />
#* sudo route add -net x.x.x.x netmask m.m.m.m eth0 - para associar uma nova rede a interface eth0<br />
#* route -n - para ver a tabela atual de roteamento<br />
# Observe que optamos pelo uso de protocolos de roteamento dinâmico. Procure entender melhor como foi feita essa configuração, a partir do que está no manual, começando pela página 82.<br />
# Para o PC do professor aplique os comandos: <syntaxhighlight lang=bash><br />
$ sudo route add -net 192.168.x.0 netmask 255.255.255.0 eth0 - x={10,20,30,40}<br />
$ sudo route add -net 192.168.x.0 netmask 255.255.255.0 gw 192.168.1.231 - x={10,20,30,40}<br />
</syntaxhighlight><br />
# Para os PCs das subredes direita e esquerda: <syntaxhighlight lang=bash><br />
$ sudo ifconfig eth0 192.168.x.y netmask 255.255.255.0 up - x={10,20,30,40}; y={1,2,3,4}<br />
$ sudo route add default gw 192.168.x.254 - x={10,20,30,40} </syntaxhighlight><br />
# Agora vamos analisar a conectividade de todas as subredes, incluindo o acesso à internet. Após isso vamos fazer uma avaliação sobre o desempenho dessa conectividade comparando os links com PPP e HDLC entre os roteadores.<br />
# Veja se o status das interfaces e protocolos da WAN e LAN de todos os routers estão em UP. Anote e avalie a configuração de todos os routers e os PCs das duas LANs direita e esquerda. <br />
# Verificar e anotar todas as configurações e instalações dos componentes de redes, modens, cabos, adaptadores, manobras dos cabos, etc...<br />
# Verificar e anotar todas as configurações lógicas dos modens, routers e PCs.<br />
# Acessar as redes mutuamente qualquer computador de um subrede deve acessar qualquer outro da outra subrede;<br />
# Acessar a internet em todos os PCs;<br />
# Interprete as configurações dos routers e destaque como está configurada a rede <br />
<br />
<!--<br />
;Mesma rede operando agora com protocolo HDLC<br />
<br />
# Faça a configuração Básica dos PCs e Roteadores NR2G com protocolo HDLC. <br />
<br />
#* '''R1:''' <syntaxhighlight lang=text><br />
DIREITA > <br />
SET LAN LAN0 IP 192.168.10.254 MASK 255.255.255.0 BROADCAST 192.168.10.255 <br />
SET LAN LAN0 UP <br />
SET LAN LAN1 IP 192.168.20.254 MASK 255.255.255.0 BROADCAST 192.168.20.255 <br />
SET LAN LAN1 UP <br />
SET WAN WAN0 PROTO HDLC IP 10.1.1.2 MASK 255.255.255.252 PEER 10.1.1.1 UP <br />
SET WAN WAN1 PURGE <br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET ROUTES DEFAULT GW1 10.1.1.1 COST1 0 <br />
SET ROUTES UP <br />
CONFIG SAVE <br />
<br />
</syntaxhighlight><br />
#* '''R2:''' <syntaxhighlight lang=text><br />
ESQUERDA > <br />
SET LAN LAN0 IP 192.168.30.254 MASK 255.255.255.0 BROADCAST 192.168.30.255 <br />
SET LAN LAN0 UP <br />
SET LAN LAN1 IP 192.168.40.254 MASK 255.255.255.0 BROADCAST 192.168.40.255 <br />
SET LAN LAN1 UP <br />
SET WAN WAN0 PROTO HDLC IP 10.1.1.6 MASK 255.255.255.252 PEER 10.1.1.5 UP <br />
SET WAN WAN1 PURGE <br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET ROUTES DEFAULT GW1 10.1.1.5 COST1 0 <br />
SET ROUTES UP<br />
CONFIG SAVE <br />
<br />
</syntaxhighlight><br />
#* '''R3:''' <syntaxhighlight lang=text><br />
CENTRAL > <br />
SET LAN LAN0 PURGE <br />
SET LAN LAN1 PURGE <br />
SET WAN WAN0 PROTO HDLC IP 10.1.1.1 MASK 255.255.255.252 PEER 10.1.1.2 UP<br />
SET WAN WAN1 PROTO HDLC IP 10.1.1.5 MASK 255.255.255.252 PEER 10.1.1.6 UP<br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0 AUTH TYPE NONE <br />
SET RIP WAN1 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN1 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET LAN LAN0 IP 192.168.1.231 MASK 255.255.255.0 BROADCAST 192.168.1.255 UP <br />
SET ROUTES DEFAULT GW1 192.168.1.1 COST1 0 <br />
SET ROUTES UP <br />
CONFIG SAVE <br />
<br />
--><br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |21/10 - Redes Frame Relay - Finalização }}<br />
<br />
:* [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/redes_circuitos_virtuais_FR.pdf Redes Frame Relay] <br />
<br />
* Finalização das explicações da configuração da rede Frame Relay montada;<br />
* Evolução do backbone da RNP como ilustração das redes Frame Relay em infraestruturas de telecom.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |26/10 - Redes Privadas Virtuais - MPLS }}<br />
<br />
==26/10 - Redes Privadas Virtuais - MPLS ==<br />
<br />
* Redes virtuais com MPLS;<br />
* Experimentos com netkit: Rede MPLS<br />
'''ATENÇÂO: Leitura:'''<br />
** '''Capítulo 5 (seção 5.8)''' do livro ''Redes de Computadores e a Internet, 5a ed.'', de James Kurose.<br />
** '''Capítulo 5 (seção 5.4.5)''' do livro ''Redes de Computadores, 4a ed.'', de Andrew Tanenbaum (ou seção 5.6.5 da 5ª ed.).<br />
<br />
<br />
* '''''Outras referências sobre MPLS:'''''<br />
<br />
** [http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching MPLS na Wikipedia]<br />
** [http://www.ietf.org/rfc/rfc3031.txt RFC 3031: MPLS Architecture]<br />
** [http://www.ietf.org/rfc/rfc3032.txt MPLS Label Stack Encoding]<br />
* [http://www.sj.ifsc.edu.br/~msobral/RCO2/docs/mpls-linux Documentação sobre os experimentos com MPLS (tirados do projeto MPLS-Linux)]<br />
<br />
[http://en.wikipedia.org/wiki/Multiprotocol_Label_Switching MPLS] é um mecanismo para redes de telecomunicações de alto desempenho que encaminha e transporta dados de um nó da rede a outro. Isso se faz por meio de links virtuais entre nós distantes um do outro, semelhante ao conceito de ''circuitos virtuais''. Diversos protocolos podem ser transportados por MPLS, tais como IP e Ethernet (note que o primeiro é um protocolo de rede, mas o segundo é um ''"protocolo"'' de enlace). Assim, MPLS se apresenta como uma tecnologia de transporte de dados em redes de longa distância, como ilustrado na figura abaixo.<br />
<br />
[[imagem:Mpls-network.jpg]]<br />
<br />
Simplificadamente, um cabeçalho (''shim header'') é adicionado a cada PDU a ser transportada pela rede MPLS. O rótulo contém um número identificador chamado de rótulo (''label'', e similar ao ''VCI'' visto em circuitos virtuais), junto com alguns bits de controle. Os roteadores dentro da rede MPLS encaminham essas PDUs com base somente no conteúdo desse cabeçalho, comutando-os de acordo com os valores de rótulo (''label switching''). Note que MPLS não faz roteamento, e sim comutação de circuitos virtuais: os circuitos devem ser previamente estabelecidos para que o encaminhamento de PDUs entre origem e destino possa ser realizada. Desta forma, MPLS parece ser um protocolo que fica entre as camadas de rede e de enlace, como mostrado na figura a seguir.<br />
<br />
[[imagem:Mpls_protocolstack.jpg]] ----> [[imagem:MPLS_D2.gif]]<br />
<br />
<br />
O cabeçalho MPLS possui apenas 32 bits, como mostrado abaixo. O valor de rótulo ocupa 20 bits, o que possibilita pouco mais de 1 milhão de diferentes rótulos (<math>2^{20}</math>). Há um campo ''Time To Live'' (ou simplesmente ''TTL'') com 8 bits, com mesma finalidade que o campo homônimo existente em PDUS IPv4: evitar que um erro de configuração em um roteador faça com que PDUs fiquem circulando eternamente em um ''loop'' na rede. O valor desse campo ''TTL'' é decrementado por cada roteador que encaminhe a PDU e, se o valor chegar a 0, a PDU é descartada. O campo ''Exp'' com 3 bits foi pensado para codificar a classe de serviço da PDU, a qual pode ser usada por mecanismos de qualidade de serviço (''QoS'') existentes na rede. Por exemplo, o valor de ''Exp'' pode ser usado como prioridade da PDU em um determinado roteador dentro da rede MPLS. Por fim, o bit ''S'' (''bottom of stack'') informa se esse é o último cabeçalho MPLS na PDU, uma vez que podem-se empilhar dois ou mais desses cabeçalhos.<br />
<br />
<br />
[[imagem:Mpls-label.png]]<br />
<br />
<br />
A terminologia MPLS possui nomes próprios para diversos componentes da arquitetura. Como ocorre em outras tecnologias, existem conceitos conhecidos apresentados porém com nomes diferentes. A tabela abaixo descreve alguns termos importantes existentes no MPLS:<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Termo<br />
!Descrição<br />
|-<br />
|''LSP'' || Label Switching Path, o análogo a circuito virtual.<br />
|-<br />
|''LSR'' || Label Switching Router, ou roteador capaz de comutar PDUs MPLS.<br />
|-<br />
|''LER'' || Label Edge Router, ou roteador que faz a interface entre a rede MPLS (onde se encaminham PDUs exclusivamente com base nos rótulos), e a rede externa (onde não se usa MPLS). A rede externa pode ser qualquer outra rede, como IPv4, IPv6 ou mesmo LAN Ethernet. Note que LER é um tipo especial de LSR, e podem ser denominados também como ''LSR ingress'' (''LSR'' de entrada na rede MPLS) e ''LSR egress'' (''LSR'' de saída da rede MPLS).<br />
|-<br />
|''LFIB'' || Label Forwarding Information Base, ou o conjunto de informações existentes nos LSR usadas para fazer o encaminhamento das PDUS MPLS. Pode ser entendida como uma estrutura análoga à tabela de comutação de circuitos virtuais.<br />
|-<br />
|}<br />
<br />
<br />
Usando os termos acima, podem-se descrever redes MPLS demonstrativas como mostrado a seguir. Na primeira rede há dois LSP: um vai do ''Host X'' ao ''Host Z'' e está identificado com PDUS em amarelo, e outro vai de ''Host X'' ao ''Host Y'' e tem PDUs em azul. O número dentro de cada PDU informa os valores de rótulo usados ao longo dos LSP. Assim como em circuitos virtuais em geral (e como em Frame Relay e ATM), os valores de rótulo podem ser modificados por cada roteador que os comute.<br />
<br />
[[imagem:Mplsrouters.gif]]<br />
<br />
=== Conceitos básicos sobre comutação de rótulos ===<br />
<br />
A comutação de rótulos feita nos LSR é muito parecida com comutação de circuitos virtuais. Ao receber uma PDU MPLS, um LSR decide o que fazer com ela com base no número do rótulo e na interface de rede de onde ela foi recebida. Porém há um detalhe específico do MPLS: uma ou mais interfaces podem ser associadas em um ''labelspace MPLS'', sendo esse ''labelspace'' usado para identificar de onde foi recebida uma PDU. Desta forma, um LSR na verdade decide o que fazer com uma PDU com base em seu rótulo e no seu ''labelspace''. Dentro do LSR essa operação se chama ''ILM'' (''Input Label Mapping'').<br />
<br />
'''''ILM''' é a função que identifica uma PDU recebida e mapeia seu rótulo para um '''labelspace'''''<br />
<br />
Um caso especial trata de PDUs que entram na rede MPLS. Por exemplo, uma PDU IPv4, originada de uma rede externa, deve ser transportada pela rede MPLS. Nesse caso, o ''LER'' (roteador de borda) deve associar essa PDU a um rótulo MPLS e encaminhá-lo pela rede MPLS. A identificação de uma PDU externa à rede MPLS, com base nas informações dessa PDU, se chama ''FEC'' (''Forwarding Equivalence Class'').<br />
<br />
Uma vez identificada uma PDU recebida, o LSR deve encaminhá-la de acordo com instruções predefinidas em sua ''LFIB''. Dentro de sua LFIB essas instruções são chamadas de ''NHLFE'' (''Next-Hop Label Forwarding Entry''), e contêm a '''operação MPLS''' a ser realizada e a interface de saída por onde encaminhar a PDU. As operações MPLS possíveis estão descritas na tabela abaixo:<br />
<br />
<br />
{| border="1" cellpadding="2"<br />
!Operação<br />
!Descrição<br />
|-<br />
|''SWAP'' || Troca o valor de rótulo. Essa operação deve ser usada para comutação dentro da rede MPLS. Mesmo quando o novo valor de rótulo for idêntico ao anterior essa operação deve ser realizada.<br />
|-<br />
|''PUSH'' || Adiciona um cabeçalho MPLS com um determinado valor de rótulo. Essa operação deve ser usada principalmente nos ''LER'', quando uma PDU entra na rede MPLS.<br />
|-<br />
|''POP'' || Remove o cabeçalho MPLS. Essa operação deve ser usada principalmente nos ''LER'', quando uma PDU sai da rede MPLS.<br />
|-<br />
|}<br />
<br />
<br />
A comutação fica completa ao se juntarem o mapeamento de entrada (''ILM'') com as ''NHLFE'', no caso de comutação dentro da rede MPLS. No caso de entrada de PDUs na rede MPLS, a operação se chama ''FTN'' (''Fec-To-Nhlfe''), que nada mais é que regras para associar os rótulos MPLS a essas PDUS. No exemplo da PDU IPv4, pode-se usar o endereço IPv4 de destino dessa PDU para escolher que rótulo MPLS deve ser usado. Isso está sumarizado na figura abaixo.<br />
<br />
[[imagem:Mpls-lfib.png]]<br />
<br />
=== Atividade com MPLS ===<br />
<br />
* [http://www.sj.ifsc.edu.br/~casagrande/RED/lab_mpls1.pdf 1o Experimento com MPLS]<br />
** Os experimentos usarão o [[Netkit#Switches_MPLS|Netkit e MPLS]]<br />
** Lab do netkit com o experimento:<br />
<br />
<code><br />
e2[type]=mpls <br />
e3[type]=mpls<br />
e4[type]=mpls<br />
e5[type]=mpls<br />
a1[type]=generic<br />
a2[type]=generic<br />
<br />
# FEC: mapeia subrede destino para nhlfe<br />
e2[fec]=172.16.20.0/24:nhlfe=1<br />
e4[fec]=172.16.10.0/24:nhlfe=1<br />
<br />
# NHLFE: como encaminhar PDUs MPLS<br />
e2[nhlfe]=1:interface=eth0:label=1000:ip=10.0.2.3<br />
e3[nhlfe]=1:interface=eth0:label=2001:ip=10.0.2.2<br />
e3[nhlfe]=2:interface=eth1:label=1001:ip=10.0.6.4<br />
e4[nhlfe]=1:interface=eth1:label=2000:ip=10.0.6.3<br />
<br />
# ILM: como identificar PDUs MPLS recebidas<br />
e2[ilm]=2001:labelspace=0<br />
e3[ilm]=2000:labelspace=0:nhlfe=1<br />
e3[ilm]=1000:labelspace=0:nhlfe=2<br />
e4[ilm]=1001:labelspace=0<br />
<br />
# Labelspace: os mapeamentos de labelspaces a interfaces<br />
e2[labelspace]=0:interfaces=eth0<br />
e3[labelspace]=0:interfaces=eth0,eth1<br />
e4[labelspace]=0:interfaces=eth1<br />
<br />
e2[eth0]=link2:ip=10.0.2.2/24<br />
e2[eth1]=link8:ip=172.16.10.2/24<br />
e2[eth3]=link1:ip=10.0.1.2/24<br />
e3[eth0]=link2:ip=10.0.2.3/24<br />
e3[eth1]=link6:ip=10.0.6.3/24<br />
e4[eth0]=link4:ip=10.0.4.4/24<br />
e4[eth1]=link6:ip=10.0.6.4/24<br />
e4[eth2]=link7:ip=172.16.20.4/24<br />
e5[eth0]=link4:ip=10.0.4.5/24<br />
e5[eth1]=link1:ip=10.0.1.5/24<br />
<br />
a1[eth2]=link8:ip=172.16.10.10/24<br />
a2[eth2]=link7:ip=172.16.20.20/24<br />
<br />
a1[default_gateway]=172.16.10.2<br />
a2[default_gateway]=172.16.20.4<br />
<br />
</syntaxhighlight><br />
<br />
* '''Exercício''': Considere o roteiro realizado em sala e faça o LSP entre A2 e A1 passar por E5 ao invés de E3 - Ou seja, isso implica modificar a configuração dos roteadores E2, E3, E4 e E5:<br />
<br />
[[imagem:Exercicio-mpls-1.png|600px]]<br />
<br />
'''Solução:'''<br />
<br />
* '''E4:''' mudar a ''NHLFE'' para que o LSP A2->A1 vá para E5.<br />
* '''E5:''' fazer a comutação A2->A1 que antes ficava em E3.<br />
* '''E2:''' modificar o ''labelspace 0'' para que contenha a interface ''eth3''.<br />
* '''E3:''' removida a configuração da comutação A2->A1<br />
<br />
<code><br />
e2[type]=mpls <br />
e3[type]=mpls<br />
e4[type]=mpls<br />
e5[type]=mpls<br />
a1[type]=generic<br />
a2[type]=generic<br />
<br />
# FEC: mapeia subrede destino para nhlfe<br />
e2[fec]=172.16.20.0/24:nhlfe=1<br />
e4[fec]=172.16.10.0/24:nhlfe=1<br />
<br />
# NHLFE: como encaminhar PDUs MPLS<br />
e2[nhlfe]=1:interface=eth0:label=1000:ip=10.0.2.3<br />
e3[nhlfe]=1:interface=eth1:label=1001:ip=10.0.6.4<br />
e4[nhlfe]=1:interface=eth0:label=2000:ip=10.0.4.5<br />
e5[nhlfe]=1:interface=eth1:label=2001:ip=10.0.1.2<br />
<br />
# ILM: como identificar PDUs MPLS recebidas<br />
e2[ilm]=2001:labelspace=0<br />
e3[ilm]=1000:labelspace=0:nhlfe=1<br />
e4[ilm]=1001:labelspace=0<br />
e5[ilm]=2000:labelspace=0:nhlfe=1<br />
<br />
<br />
# Labelspace: os mapeamentos de labelspaces a interfaces<br />
e2[labelspace]=0:interfaces=eth0,eth3<br />
e3[labelspace]=0:interfaces=eth0,eth1<br />
e4[labelspace]=0:interfaces=eth0,eth1<br />
e5[labelspace]=0:interfaces=eth0,eth1<br />
<br />
<br />
e2[eth0]=link2:ip=10.0.2.2/24<br />
e2[eth1]=link8:ip=172.16.10.2/24<br />
e2[eth3]=link1:ip=10.0.1.2/24<br />
e3[eth0]=link2:ip=10.0.2.3/24<br />
e3[eth1]=link6:ip=10.0.6.3/24<br />
e4[eth0]=link4:ip=10.0.4.4/24<br />
e4[eth1]=link6:ip=10.0.6.4/24<br />
e4[eth2]=link7:ip=172.16.20.4/24<br />
e5[eth0]=link4:ip=10.0.4.5/24<br />
e5[eth1]=link1:ip=10.0.1.5/24<br />
<br />
a1[eth2]=link8:ip=172.16.10.10/24<br />
a2[eth2]=link7:ip=172.16.20.20/24<br />
<br />
a1[default_gateway]=172.16.10.2<br />
a2[default_gateway]=172.16.20.4<br />
<br />
</syntaxhighlight><br />
<br />
=== MPLS - Labelspaces e Tunels ===<br />
<br />
'''Atividade'''<br />
<br />
* [http://tele.sj.ifsc.edu.br/~casagrande/RED/mpls_labelspaces.pdf Roteiro sobre labelspaces e túneis MPLS]<br />
<br />
'''Laboratório do netkit sobre labelspaces:'''<br />
<br />
<code><br />
<br />
e1[type]=mpls <br />
e2[type]=mpls <br />
e3[type]=mpls<br />
e4[type]=mpls<br />
e5[type]=mpls<br />
a1[type]=generic<br />
a2[type]=generic<br />
a3[type]=generic<br />
<br />
# FEC: mapeia subrede destino para nhlfe<br />
e2[fec]=172.16.20.0/24:nhlfe=1<br />
e4[fec]=172.16.10.0/24:nhlfe=1<br />
<br />
# NHLFE: como encaminhar PDUs MPLS<br />
e2[nhlfe]=1:interface=eth0:label=1000:ip=10.0.2.3<br />
e3[nhlfe]=1:interface=eth0:label=1000:ip=10.0.2.2<br />
e3[nhlfe]=2:interface=eth1:label=1000:ip=10.0.6.4<br />
e4[nhlfe]=1:interface=eth1:label=1000:ip=10.0.6.3<br />
<br />
# ILM: como identificar PDUs MPLS recebidas<br />
e2[ilm]=1000:labelspace=0<br />
e3[ilm]=1000:labelspace=0:nhlfe=2<br />
e3[ilm]=1000:labelspace=1:nhlfe=1<br />
e4[ilm]=1000:labelspace=0<br />
<br />
#Labelspace: os mapeamentos de labelspaces a interfaces<br />
<br />
e2[labelspace]=0:interfaces=eth0<br />
e3[labelspace]=0:interfaces=eth0<br />
e3[labelspace]=1:interfaces=eth1<br />
e4[labelspace]=0:interfaces=eth1<br />
<br />
e1[eth1]=link9:ip=172.16.30.1/24<br />
e1[eth2]=link3:ip=10.0.3.1/24<br />
e1[eth3]=link5:ip=10.0.5.1/24<br />
e2[eth0]=link2:ip=10.0.2.2/24<br />
e2[eth1]=link8:ip=172.16.10.2/24<br />
e2[eth2]=link3:ip=10.0.3.2/24<br />
e2[eth3]=link1:ip=10.0.1.2/24<br />
e3[eth0]=link2:ip=10.0.2.3/24<br />
e3[eth1]=link6:ip=10.0.6.3/24<br />
e3[eth2]=link5:ip=10.0.5.3/24<br />
e4[eth0]=link4:ip=10.0.4.4/24<br />
e4[eth1]=link6:ip=10.0.6.4/24<br />
e4[eth2]=link7:ip=172.16.20.4/24<br />
e5[eth0]=link4:ip=10.0.4.5/24<br />
e5[eth1]=link1:ip=10.0.1.5/24<br />
<br />
a1[eth2]=link8:ip=172.16.10.10/24<br />
a2[eth2]=link7:ip=172.16.20.20/24<br />
a3[eth0]=link9:ip=172.16.30.30/24<br />
<br />
a1[default_gateway]=172.16.10.2<br />
a2[default_gateway]=172.16.20.4<br />
a3[default_gateway]=172.16.30.1<br />
<br />
</syntaxhighlight><br />
<br />
'''Laboratório do netkit sobre túneis:'''<br />
<br />
<code><br />
e1[type]=mpls <br />
e2[type]=mpls <br />
e3[type]=mpls<br />
e4[type]=mpls<br />
e5[type]=mpls<br />
a1[type]=generic<br />
a3[type]=generic<br />
a4[type]=generic<br />
<br />
# FEC: mapeia subrede destino para nhlfe<br />
e1[fec]=172.16.10.0/24:nhlfe=1<br />
e2[fec]=172.16.30.0/24:nhlfe=1<br />
<br />
# NHLFE: como encaminhar PDUs MPLS<br />
e1[nhlfe]=1:interface=eth2:label=500:ip=10.0.3.2<br />
e2[nhlfe]=1:interface=eth3:label=100:ip=10.0.1.5<br />
e3[nhlfe]=1:interface=eth2:label=300:ip=10.0.5.1<br />
e4[nhlfe]=1:interface=eth1:label=3000:ip=10.0.6.3<br />
e5[nhlfe]=1:label=200:nhlfe=2<br />
e5[nhlfe]=2:interface=eth0:label=2000:ip=10.0.4.4<br />
<br />
# ILM: como identificar PDUs MPLS recebidas<br />
e1[ilm]=300:labelspace=0<br />
e2[ilm]=500:labelspace=0<br />
e3[ilm]=3000:labelspace=0<br />
e3[ilm]=200:labelspace=0:nhlfe=1<br />
e4[ilm]=2000:labelspace=0:nhlfe=1<br />
e5[ilm]=100:labelspace=0:nhlfe=1<br />
<br />
# Labelspace: os mapeamentos de labelspaces a interfaces<br />
e1[labelspace]=0:interfaces=eth3<br />
e2[labelspace]=0:interfaces=eth2<br />
e3[labelspace]=0:interfaces=eth1<br />
e4[labelspace]=0:interfaces=eth0<br />
e5[labelspace]=0:interfaces=eth1<br />
<br />
e1[eth1]=link9:ip=172.16.30.1/24<br />
e1[eth2]=link3:ip=10.0.3.1/24<br />
e1[eth3]=link5:ip=10.0.5.1/24<br />
e2[eth0]=link2:ip=10.0.2.2/24<br />
e2[eth1]=link8:ip=172.16.10.2/24<br />
e2[eth2]=link3:ip=10.0.3.2/24<br />
e2[eth3]=link1:ip=10.0.1.2/24<br />
e3[eth0]=link2:ip=10.0.2.3/24<br />
e3[eth1]=link6:ip=10.0.6.3/24<br />
e3[eth2]=link5:ip=10.0.5.3/24<br />
e3[eth3]=link10:ip=172.16.40.3/24 <br />
e4[eth0]=link4:ip=10.0.4.4/24<br />
e4[eth1]=link6:ip=10.0.6.4/24<br />
e4[eth2]=link7:ip=172.16.20.4/24<br />
e5[eth0]=link4:ip=10.0.4.5/24<br />
e5[eth1]=link1:ip=10.0.1.5/24<br />
<br />
a1[eth2]=link8:ip=172.16.10.10/24<br />
a3[eth0]=link9:ip=172.16.30.30/24<br />
a4[eth0]=link10:ip=172.16.40.40/24<br />
<br />
a1[default_gateway]=172.16.10.2<br />
a3[default_gateway]=172.16.30.1<br />
a4[default_gateway]=172.16.40.3<br />
<br />
</syntaxhighlight><br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |28/10 - Protocolos Ponto a Ponto para WANs }}<br />
<br />
==28/10 - Protocolos Ponto a Ponto para WANs==<br />
<br />
* Testes de desempenho com protocolo Frame-Relay na rede WAN real com routers NR2G.<br />
* Mesmos testes com protocolos PPP e HDLC.<br />
<br />
'''Roteiro dos testes'''<br />
<br />
# Verifique se a operação da rede nos routers do laboratório estão operantes com protocolo frame relay e que as quatro subredes tem conexão entre elas, o PC do professor (192.168.1.1) e a Internet;<br />
# Teste a vazão pelos enlaces ponto-a-ponto SOMENTE COM UM ÚNICO PC associado a cada Router (DIREITO e ESQUERDO). Em algum computador da subrede esquerda ou direita execute:<syntaxhighlight lang=bash> netperf -f k -H 192.168.1.1</syntaxhighlight><br />
# Teste o delay médio da comunicação usando PING com pacote de 65508 bytes aplicado de TODOS OS PCs da subrede para o PC do professor. Anote a média entre todos os PCs: <syntaxhighlight lang=bash> ping -s 65500 192.168.1.1</syntaxhighlight><br />
# Realize pelo menos três medidas para cada teste e use a média desses valores como resultado final;<br />
# Excute o ''netperf'' entre computadores da ''mesma subrede'', anote os valores e compare com as medidas anteriores;<br />
# Execute os mesmos testes agora com protocolo HDLC. Veja configuração abaixo:<br />
<br />
;Mesma rede operando agora com protocolo HDLC<br />
<br />
# Faça a configuração Básica dos PCs e Roteadores NR2G com protocolo HDLC. <br />
<br />
#* '''R1:''' <syntaxhighlight lang=text><br />
DIREITA > <br />
SET LAN LAN0 IP 192.168.10.254 MASK 255.255.255.0 BROADCAST 192.168.10.255 <br />
SET LAN LAN0 UP <br />
SET LAN LAN1 IP 192.168.20.254 MASK 255.255.255.0 BROADCAST 192.168.20.255 <br />
SET LAN LAN1 UP <br />
SET WAN WAN0 PROTO HDLC IP 10.1.1.2 MASK 255.255.255.252 PEER 10.1.1.1 UP <br />
SET WAN WAN1 PURGE <br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET ROUTES DEFAULT GW1 10.1.1.1 COST1 0 <br />
SET ROUTES UP <br />
CONFIG SAVE <br />
<br />
</syntaxhighlight><br />
#* '''R2:''' <syntaxhighlight lang=text><br />
ESQUERDA > <br />
SET LAN LAN0 IP 192.168.30.254 MASK 255.255.255.0 BROADCAST 192.168.30.255 <br />
SET LAN LAN0 UP <br />
SET LAN LAN1 IP 192.168.40.254 MASK 255.255.255.0 BROADCAST 192.168.40.255 <br />
SET LAN LAN1 UP <br />
SET WAN WAN0 PROTO HDLC IP 10.1.1.6 MASK 255.255.255.252 PEER 10.1.1.5 UP <br />
SET WAN WAN1 PURGE <br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET ROUTES DEFAULT GW1 10.1.1.5 COST1 0 <br />
SET ROUTES UP<br />
CONFIG SAVE <br />
<br />
</syntaxhighlight><br />
#* '''R3:''' <syntaxhighlight lang=text><br />
CENTRAL > <br />
SET LAN LAN0 PURGE <br />
SET LAN LAN1 PURGE <br />
SET WAN WAN0 PROTO HDLC IP 10.1.1.1 MASK 255.255.255.252 PEER 10.1.1.2 UP<br />
SET WAN WAN1 PROTO HDLC IP 10.1.1.5 MASK 255.255.255.252 PEER 10.1.1.6 UP<br />
<br />
SET RIP REDIST-STATIC TRUE REDIST-CONNECTED TRUE REDIST-OSPF FALSE DEFAULTMETRIC 2<br />
SET RIP WAN0 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN0 AUTH TYPE NONE <br />
SET RIP WAN1 ENABLED TRUE TYPE ACTIVE <br />
SET RIP WAN1 AUTH TYPE NONE <br />
SET RIP UP <br />
<br />
SET LAN LAN0 IP 192.168.1.231 MASK 255.255.255.0 BROADCAST 192.168.1.255 UP <br />
SET ROUTES DEFAULT GW1 192.168.1.1 COST1 0 <br />
SET ROUTES UP <br />
CONFIG SAVE </syntaxhighlight><br />
# Agora troque o protocolo HDLC dos enlaces por PPPS (protocolo PPP Síncrono - veja pg. 76 do manual). Faça isso primeiramente no router R3 (central) pois será perdido enlace com ele quando mudar o protocolo. Como exemplo, para trocar a configuração na interface WAN0 execute o comando:<syntaxhighlight lang=text> SET WAN WAN0 PROTO PPPS IP 10.1.1.5 MASK 255.255.255.252 PEER 10.1.1.6 UP </syntaxhighlight><br />
Faça o mesmo para a WAN1 do router central e WAN0s dos routers esquerdo e direito. Não esqueça de aplicar o comando CONFIG SAVE para salvar a configuração atual. Observe o estado dos leds que indicam a presença de dados protocolados entre routers, tanto no frontal dos modens quanto no frontal dos routers. Eles ficaram apagados por um tempo mas devem retornar a acender depois de uns dois ou tres minutos. O led ST no frontal dos routers deve ficar na cor laranja indicando a queda dos links e depois de um tempo devem retornar a cor verde quando tudo estiver ok.<br />
<br />
# Repita e anote as mesmas medições de vazão conforme feito anteriormente com protocolo HDLC;<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 04/11 - Protocolos de Enlace Ponto à Ponto }}<br />
<br />
== 04/11 - Protocolos de Enlace Ponto à Ponto ==<br />
<br />
'''Atenção:''' liberada a [http://tele.sj.ifsc.edu.br/~casagrande/RED/lista1_2014_2.pdf LISTA1] de exercícios para a avaliação A1<br />
<br />
'''Resumo da aula:'''<br />
* Slides sobre [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/protocolos_pp.pdf Protocolos Ponto à Ponto];<br />
* Serviços da Camada de enlace.<br />
<br />
'''Bibliografia relacionada:'''<br />
'''ATENÇÃO:'''<br />
* Ler Seção 5.7 do livro "Redes de Computadores" do Kurose 5a ed.'''<br />
* Parte III e capítulos 10 e 11 do livro "Comunicação de Dados e Redes de Computadores, 4a ed.", de Behrouz Forouzan<br />
* Capítulo 3 do livro "Redes de Computadores" de Andrew Tanenbaum.<br />
<br />
'''Fundamentos Teóricos'''<br />
<br />
=== Enlaces lógicos ===<br />
<br />
Equipamentos de rede se comunicam por meio de enlaces (''links''). Um enlace é composto por uma '''parte física''', composta pelo meio de transmissão e o hardware necessário para transmitir e receber um sinal que transporta a informação, e uma '''parte lógica''', responsável por empacotar os dados a serem transmitidos. O diagrama abaixo ilustra um enlace entre dois equipamentos, realçando as formas com que a informação é representada durante a transmissão e recepção. Nesse diagrama, a ''parte lógica'' está representada no bloco ''Enlace'', e a ''parte física'' está no bloco ''Física''; a informação transmitida, representada por ''Dados'', pode ser, por exemplo, um datagrama IP.<br />
<br />
[[imagem:Datalink-phy.png|600px]]<br />
<br />
O enlace lógico tem uma dependência total em relação à parte física. Isso quer dizer que o tipo de tecnologia de transmissão existente na parte física traz requisitos para o projeto da parte lógica.<br />
<br />
Deste ponto em diante, a ''parte lógica'' será chamada simplesmente de '''Camada de Enlace''', e a parte física de '''Camada Física'''.<br />
<br />
Em nosso estudo vamos investigar '''enlaces ponto-a-ponto''', os quais necessitam de protocolos específicos. Para ficar mais claro o que deve fazer um protocolo de enlace ponto-a-ponto, vamos listar os serviços típicos existentes na camada de enlace. <br />
<br />
===== Serviços da camada de enlace =====<br />
<br />
[[Image:Data-link.png]]<br />
<br />
Os serviços identificados na figura acima estão descritos a seguir. A eles foram acrescentados outros dois:<br />
<br />
* '''Encapsulamento (ou ''enquadramento'')''': identificação das PDUs (quadros) de enlace dentro de sequências de bits enviadas e recebidas da camada física<br />
* '''Controle de erros''': garantir que quadros sejam entregues no destino<br />
** '''''Detecção de erros''''': verificação da integridade do conteúdo de quadros (se foram recebidos sem erros de bits)<br />
* '''Controle de fluxo''': ajuste da quantidade de quadros transmitidos, de acordo com a capacidade do meio de transmissão (incluindo o atraso de transmissão) e do receptor<br />
* '''Endereçamento''': necessário quando o enlace for do tipo '''multi-ponto''', em que vários equipamentos compartilham o meio de transmissão (ex: redes locais e redes sem-fio)<br />
* '''Controle de acesso ao meio (MAC)''': também necessário para '''meios compartilhados''', para disciplinar as transmissões dos diversos equipamentos de forma a evitar ou reduzir a chance de haver colisões (transmissões sobrepostas)<br />
* '''Gerenciamento de enlace''': funções para ativar, desativar e manter enlaces<br />
<br />
==== Protocolos de enlace ponto-a-ponto ====<br />
<br />
Dois protocolos de enlace ponto-a-ponto muito utilizados são:<br />
* '''PPP (''Point-to-Point Protocol''):''' proposto no início dos anos 90 pelo IETF (ver [http://www.ietf.org/rfc/rfc1661.txt RFC 1661]), e amplamente utilizado desde então. Este protocolo não faz controle de erros nem de fluxo, portanto se quadros sofrerem erros de transmissão serão sumariamente descartados no receptor. Originalmente muito usado em acesso discado, recentemente sua aplicação se concentra em enlaces por linhas dedicadas, enlaces sem-fio 3G, e uma versão modificada para acesso doméstico ADSL (''PPPoE''). Ver mais detalhes na seção 5.7 do livro do Kurose e na seção 11.7 do livro ''Comunicação de Dados e Redes de Computadores'', de Behrouz Forouzan. <br />
* '''HDLC (''High-level Data Link Control''):''' criado nos anos 70, foi largamente utilizado em enlaces ponto-a-ponto, porém atualmente foi substituído pelo PPP na maioria dos cenários em que era usado. Este protocolo faz controle de erros e de fluxo usando um [[Desempenho_ARQ|mecanismo ARQ do tipo Go-Back-N]] (com janela de tamanho 7 ou 127). Ainda se aplica a enlaces ponto-a-ponto em linhas dedicadas, enlaces por satélite e aplicações específicas onde a presença de ruídos no meio de transmissão é relevante ou se deseja confiabilidade na entrega de pacotes na camada 2. Ver mais detalhes na seção 11.6 do livro ''Comunicação de Dados e Redes de Computadores'', de Behrouz Forouzan.<br />
<br />
Ambos protocolos possuem o mesmo formato de quadro. Na verdade, o PPP copiou o formato de quadro do HDLC, apesar de não utilizar os campos ''Address'' e ''Control''. O campo ''Flag'', que tem o valor predefinido <math>7E_H</math>, serve para delimitar quadros, assim o receptor sabe quando inicia e termina cada quadro.<br />
<br />
[[imagem:Ppp-frame.png|400px]]<br />
<br>''Quadro PPP ou HDLC (tamanho de campos dados em bytes)''<br><br />
<br />
Esses protocolos foram criados para uso com comunicação serial síncrona (ver capítulo 4, seção 4.3 do livro ''Comunicação de Dados e Redes de Computadores'', de Behrouz Forouzan). O PPP funciona também com [http://pt.wikipedia.org/wiki/Comunica%C3%A7%C3%A3o_serial_ass%C3%ADncrona comunicação serial assíncrona].<br />
<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 07/11 - <math>\blacklozenge</math> Ensaios finais sobre MPLS e Desempenho de protocolos de Redes Ponto à Ponto e Frame Relay}}<br />
<br />
== 07/11 - Ensaios finais sobre MPLS e Desempenho de protocolos de Redes Ponto à Ponto e Frame Relay ==<br />
<br />
#Ilustração do gnome-netkit para os labs MPLS com auxílio do WireShark;<br />
#<math>\blacklozenge</math> Tarefa para hoje ('''ATENÇÃO: faz parte da avaliação AE'''):<br />
#Preenchimento da planilha de desempenho dos protocolos FR, PPP e HDLC abaixo, conforme roteiro do dia 28/10.<br />
'''Resultados de testes aplicados ao PC do Professor (o Gateway da rede - GW):'''<br />
{| border="1" cellpadding="5" cellspacing="0" <br />
!PROTOCOLO<br />
!Netperf-->GW vazão<br />
!Netperf-->GW tempo<br />
!Ping-->GW <br />
|-<br />
|FRAME RELAY ||E: 1961,32|| E: 13,7|| E: 2,4<br />
|-<br />
|HDLC ||E: 1961,53 ||E: 13,34 ||E: 2,51 <br />
|-<br />
|PPPS ||E: 1923,14 ||E: 10,64 ||E: 2,58 <br />
|-<br />
|}<br />
<br />
<br> <br />
<br><br />
'''Testes de vazão e ping na mesma subrede:'''<br />
<br><br />
{| border="1" cellpadding="5" cellspacing="0" <br />
!Netperf-->LAN vazão<br />
!Netperf-->LAN tempo<br />
!Ping-->LAN <br />
|-<br />
|0 ||0 || 0<br />
|-<br />
|}<br><br />
'''Perguntas para as equipes:'''<br> <br />
*'''Atenção''': os componentes das equipes A à D são os mesmos da formação realizada em sala no dia da avaliação 1 (Equipe A é a que fica do lado das janelas da sala com o rack direito, as demais na sequência...)<br />
<br />
'''EQUIPE A''': Anderson, André Felipe Weber, Gabriel , Carlos e Gustavo. <br><br />
'''Link das Respostas'''<br />
'''--> ''' [https://drive.google.com/file/d/0B5uxU74qlINVcHlBZ3FEQnRQYzQ/view?usp=sharing] <br />
#Entenda como funciona basicamente o teste de vazão do netperf e explique porque o troughtput do ensaio com Frame Relay não alcançou a taxa de transmissão nominal do link. <br />
<syntaxhighlight lang=bash> R. </syntaxhighlight><br />
<syntaxhighlight lang=bash> 'Revisão do professor:' </syntaxhighlight><br />
#Compare as estruturas de frame dos protocolos Frame Relay e MPLS e discuta sobre o overhead causado nesses protocolos<br />
<syntaxhighlight lang=bash> R. </syntaxhighlight><br />
<syntaxhighlight lang=bash> 'Revisão do professor:' </syntaxhighlight><br> <br />
<br />
'''EQUIPE B''':Katharine Schaeffer Fertig, Kristhine Schaeffer Fertig, Gabriel Cantu, Lucas Lucindo, Iago Soares <br><br />
#Explique brevemente a diferença encontrada nos resultados de teste de ping na mesma rede e rede remota.<br />
<br />
[[Arquivo:TabelaPing_EquipeB.png|600px|thumb|center|Tabela de Teste Ping e Netperf]]<br />
<br />
<syntaxhighlight lang=bash> R. Tendo realizado o tete de ping normal (tamanho de pacote normal padrão) para mesma rede e rede remota notou-se que as médias de<br />
tempo de transmissão de dados entre computadores na rede da equipe B e do professor (rede externa) foram:<br />
<br />
Frame relay: 2,44 segundos<br />
HDLC: 2,57 segundos<br />
<br />
Tendo-se ainda realizado o Netperf para a mesma rede (sub-rede) e rede remota (sub-redes diferentes e computador do professor) <br />
obteve-se os seguintes dados de teste:<br />
<br />
Tempo de transmissão com protocolo Frame Relay<br />
Mesma sub-rede: 10,13 segundos<br />
Rede Remota/Sub-rede diferente: 10,057 segundos<br />
<br />
Assim vemos que para um mesmo protocolo – neste caso o Frame Relay – não há diferença significativa de tempo de transmissão entre mesma rede e rede<br />
remota. Também em comparação com resultados de testes entre os dois protocolos (HDLC e FR) não houve uma grande diferença no tempo de transmissão. <br />
Mas a diferença existente (em cerca de 100 milisegundos) deve-se ao fato de o protocolo HDLC implementar mecanismos de controle (como fluxo e erros)<br />
nos frames transmitidos, gerando maior overhead no frame e necessitando de maior tempo para tranmissão de dados (propriamente ditos) relevantes à camada superior.<br />
<br />
</syntaxhighlight><br />
<syntaxhighlight lang=bash> 'Revisão do professor:' </syntaxhighlight><br />
#Compare as estruturas de frame dos protocolos Frame Relay e HDLC e discuta sobre o overhead causado nesses protocolos<br />
[[Arquivo:Frames.png|600px|thumb|center|Frames de Protocolos HDLC Padrão, HDLC Cisco e Frame Relay]]<br />
<syntaxhighlight lang=bash> R. <br />
<br />
De acordo com as estruturas de frame acima podemos concluir que há maior overhead no protocolo HDLC pois apesar de efetuar bit-stuffing, que gera <br />
menor overhead em relação a protocolos orientados a byte, possui um campo de controle em seu frame que envia apenas bits de controle para comunicação,<br />
sendo que o protocolo Frame Relay (FR) não necessita destas informações de controle, apenas as informações de endereço para repasse de dados e não <br />
realizando controle de erros e fluxo para estes frames. Vemos ainda que para um protocolo HDLC para modens/roteadores cisco, além de campos de <br />
controle de fluxo e de erros (extra ao FR), existe um sub-campo no campo de dados que se chama E-type ou campo de proprietário que informa o tipo de <br />
protocolo/proprietário da camada superior, causando ainda mais overhead ao frame! Nota-se que a estrutura simplificada dos frames em protocolo Frame <br />
Relay apenas necessita de informações do campo de endereço como o DLCI de enlaces da rede CV.<br />
</syntaxhighlight><br />
<syntaxhighlight lang=bash> 'Revisão do professor:' </syntaxhighlight><br><br />
<br />
'''EQUIPE C''':colocar aqui os componentes <br><br />
#Entenda como funciona basicamente o teste de vazão do netperf e explique brevemente a diferença encontrada nos resultados de tempo de teste ocorridos entre os três protocolos avaliados.<br />
<syntaxhighlight lang=bash> R. </syntaxhighlight><br />
<syntaxhighlight lang=bash> 'Revisão do professor:' </syntaxhighlight><br />
#Compare as estruturas de frame dos protocolos HDLC e PPP e discuta sobre o overhead causado nesses protocolos<br />
<syntaxhighlight lang=bash> R. </syntaxhighlight><br />
<syntaxhighlight lang=bash> 'Revisão do professor:' </syntaxhighlight><br><br />
<br />
'''EQUIPE D''': HelenLuciany Cechinel, Leticia Coelho, Jessica Hahn, Maria Luiza Theisges,Vinicius Kachniacz e Marcus Vinícius <br><br />
#Entenda como funciona basicamente o teste de vazão do netperf e explique porque o troughtput do ensaio com PPP não alcançou a taxa de transmissão nominal do link.<br />
<syntaxhighlight lang=bash> R. O netperf é um comando que testa a vazão da rede mandando um pacote com um número determinado de bits e verificando o tempo de resposta <br />
do pacote na rede. O PPP não alcançou a taxa de transmissão nominal do link devido a multiplexação dos dados, em que o canal foi dividido<br />
em outros sub canais. A somatória da banda de transmissão é o valor total da taxa de transmissão nominal do link;</syntaxhighlight><br />
<syntaxhighlight lang=bash> ''Revisão do professor:'' </syntaxhighlight><br />
#Compare as estruturas de frame dos protocolos PPP e Frame Relay e discuta sobre o overhead causado nesses protocolos<br />
R. <br />
{| border="1" cellpadding="5" cellspacing="0" <br />
!PPP<br />
|FLAG ||Endereço|| Controle || Protocolo || Payload || FCS || FLAG<br />
|}<br />
<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" <br />
!Frame Relay<br />
|FLAG || Endereço || Dados || FCS || FLAG<br />
|}<br />
<br />
{| border="1" cellpadding="5" cellspacing="0" <br />
!Endereço Frame Relay<br />
|DLCI||C/R|| EA || DLCI || FECN || BECN || DE || EA<br />
|}<br />
<br />
<br />
<syntaxhighlight lang=bash><br />
O PPP faz ByteStuffing e devido a este mecanismo um byte especial pode ser substituido por dois bytes ou mais,<br />
causando mais overhead do que o Frame Relay. Se o byte Stuffing for aplicado ao Frame. </syntaxhighlight><br />
<br> <br />
<br />
<syntaxhighlight lang=bash> 'Revisão do professor:' </syntaxhighlight><br><br />
<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 09/11 - Enquadramento (Framing) e delimitação de quadros}}<br />
<br />
== 09/11 - Enquadramento (Framing) e delimitação de quadros ==<br />
<br />
'''Resumo da aula:'''<br />
<br />
* bit e byte stuffing;<br />
* Explicações adicionais e exemplos de enquadramento e delimitação em HDLC e PPP; Identificação de pacotes.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 11/11 - Detecção e Correção de Erros }}<br />
<br />
== 11/11 - Detecção e Correção de Erros==<br />
<br />
'''Resumo da aula:'''<br />
* Explicações adicionais sobre PPP;<br />
* Abordagem sobre erros em sistemas de telecomunicações: Erro de bit, erro de rajada;<br />
* Uso do campo FCS (Frame Check Sequence) nos protocolos da camada 2 para fins de de detecção de erro;<br />
* Check de paridade simples em sistemas assíncronos de comunicação de dados;<br />
* Paridade bidimensional ou longitudinal;<br />
* Revisão sobre a técnica de CheckSum;<br />
* Técnica CRC: Técnicas polinomiais na detecção e correção de erros na formação do FCS com códigos cíclicos CRC;<br />
* Exercícios da LISTA 1.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 16/11 - Exercícios }}<br />
<br />
* Mais alguns exercícios da Lista 1;<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 18/11 - Interfaces Digitais}}<br />
<br />
'''Resumo da aula:'''<br />
<br />
* Slides sobre [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/InterfacesDigitais.pdf Interfaces Digitais]. <br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 23/11 - Interfaces Digitais e exercícios}}<br />
<br />
== 23/11 - Interfaces Digitais e exercícios==<br />
<br />
'''Resumo da aula:'''<br />
<br />
* Finalização dos slides sobre [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/InterfacesDigitais.pdf Interfaces Digitais];<br />
* Proponha e desenhe um esquema de ligações MÍNIMO de um cabo lógico que interliga um DTE a um DCE que estão configurados para uma comunicação de dados síncrona, que usa o clock do DTE como base de sincronismo. O controle de fluxo via hardware ́e requerido na comunicação e ela não se inicia se o circuito CT109 não estiver ativo. O DTE e DCE usam interface RS232 com conectores DB25 Fêmea.<br />
* Verificar e anotar todos os componentes nas conexões físicas entre modens, routers e PCs do laboratório realizado na aula de FR.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 25/11 - Implementação de caso de Interfaces Digitais e Avaliação 1}}<br />
<br />
== 25/11 - Implementação de caso de Interfaces Digitais e Avaliação 1==<br />
<br />
'''Implementação de Caso'''<br />
<br />
#Dinâmica:<br />
<br />
Com o objetivo de conhecer, identificar, especificar e instalar os componentes de redes associados a parte física de uma rede de telecomunicações, lançou-se a tarefa de realizar a troca dos roteadores central e esquerdo da rede para outros CISCO 2514 e 1750 respectivamente. Visando assimilar o significado e importância de todas as reconexões, não se priorizou refazer configurações em nível de enlace nos roteadores.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 30/11 - Correção da Avaliação 1 - Revisão do conteúdo correspondente}}<br />
<br />
== 30/11 - Correção da Avaliação 1 - Revisão do conteúdo correspondente==<br />
<br />
* Correção da Avaliação 1 - Revisão do conteúdo correspondente e esclarecimento de dúvidas e alternativas polêmicas da prova.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 02/12 - Modens Analógicos e Digitais}}<br />
<br />
== 02/12 - Modens Analógicos e Digitais==<br />
<br />
* Término da correção da Avaliação 1.<br />
* [http://www.sj.ifsc.edu.br/~casagrande/RED/slides/modens.pdf Modens e enlaces de teste] <br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 07/12 - Modens e Enlaces de Teste}}<br />
<br />
== 07/12 - Modens e Enlaces de Teste==<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 09/12 - Redes Locais e o Padrão Ethernet }}<br />
<br />
== 09/12 - O Padrão Ethernet ==<br />
<br />
* Modens, Interfaces e Exercícios;<br />
* Redes Locais e o padrão Ethernet - <br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 14/12 - Arquitetura IEEE 802}}<br />
<br />
== 14/12 - Arquitetura IEEE 802 ==<br />
<br />
* Padrões da Arquitetura IEEE;<br />
* Atividades com laboratório.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 16/12 - Padrões IEEE 802 }}<br />
<br />
== 16/12 - Padrões IEEE 802.3 ==<br />
<br />
* Padrões da Arquitetura IEEE 802;<br />
* Exercícios de revisão para a Avaliação A2.<br />
<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | 21/12 - Recuperação Avaliação A1 e Avaliação A2}}<br />
<br />
== 21/12 - Recuperação Avaliação A1 e Avaliação A2 ==<br />
<br />
{{Collapse bottom}}<br />
<br />
{{ENGTELECO}}</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Arquivo:TabelaPing_EquipeB.png&diff=99108Arquivo:TabelaPing EquipeB.png2015-12-02T18:01:03Z<p>Kristhine.sf: </p>
<hr />
<div></div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=97316Mapas de Karnaugh 2D e 3D2015-11-19T11:51:38Z<p>Kristhine.sf: /* Referências Bibliográficas */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos ([[CIL-EngTel_(página) |CIL 29003]]) da [[Curso_de_Engenharia_de_Telecomunicações |Engenharia de Telecomunicações]] é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, [http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html ''Karnaugh Map Explorer 2.0''].<br />
<br />
Para cinco ou seis variáveis de entrada, sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de Karnaugh de até seis variáveis para facilitar a compreensão e execução por parte dos alunos. Esse site deve permitir a apresentação tridimensional de mapas de Karnaugh, com visualização remota seja por computador ou por smartfone.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
== Metodologia do Projeto ==<br />
<br />
#Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
#Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
#Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de rotação através de alguma interação do usuário. A validação ocorre pela simples conferência visual e interativa dessa página. Etapa parcialmente desenvolvida onde a manipulação da forma geométrica pode ser testada no [http://www.sj.ifsc.edu.br/~odilson/3DKM/ site provisório do projeto], ou [http://www.sj.ifsc.edu.br/~odilson/cubo/ na versão antiga] e [http://www.sj.ifsc.edu.br/~odilson/CuboV2/ na nova versão do cubo].<br />
#“Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
#Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
{| class="wikitable" style="text-align: center; margin: 1em auto 1em auto;"<br />
|+ '''Cronograma'''<br />
! Metas || Maio || Junho || Julho || Agosto || Setembro || Outubro || Novembro<br />
|-<br />
| 1 || X || X || X || || || || <br />
|-<br />
| 2 || || X || X || X || || || <br />
|-<br />
| 3 || || || || X || X || X || <br />
|-<br />
| 4 || || || || || X || X || X <br />
|-<br />
| 5 || || || || || || || X <br />
|}<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL. Editora Campus, 2010<br />
#TOCCI, Ronald J. WIDMER. Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark. Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce. Introdução ao HTML 5. Editora Alta Books, 2011<br />
#DIRKSEN, Jos. Learning Three.js – the JavaScript 3D Library for WebGL. Second Edition. Birmingham: Packt Publishing, 2015<br />
#Karnaugh-Veitch Map. Disponível em: http://www.mathematik.uni-marburg.de/~thormae/lectures/ti1/code/karnaughmap/<br />
#Quine–McCluskey algorithm. Disponível em: http://www.mathematik.uni-marburg.de/~thormae/lectures/ti1/code/qmc/</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92815Mapas de Karnaugh 2D e 3D2015-09-04T17:39:07Z<p>Kristhine.sf: /* Principais Contribuições do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
== Metodologia do Projeto ==<br />
<br />
'''1.''' Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
'''2.''' Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
'''3.''' Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de rotação através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
'''4.''' “Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
'''5.''' Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
{| class="wikitable" style="text-align: center; margin: 1em auto 1em auto;"<br />
|+ '''Cronograma'''<br />
! Metas || Maio || Junho || Julho || Agosto || Setembro || Outubro || Novembro<br />
|-<br />
| 1 || X || X || X || || || || <br />
|-<br />
| 2 || || X || X || X || || || <br />
|-<br />
| 3 || || || || X || X || X || <br />
|-<br />
| 4 || || || || || X || X || X <br />
|-<br />
| 5 || || || || || || || X <br />
|}<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92814Mapas de Karnaugh 2D e 3D2015-09-04T17:38:40Z<p>Kristhine.sf: /* Principais Contribuições do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<iframe src="http://www.ifsc.edu.br" width="800" height="600"></iframe><br />
<br />
== Metodologia do Projeto ==<br />
<br />
'''1.''' Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
'''2.''' Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
'''3.''' Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de rotação através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
'''4.''' “Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
'''5.''' Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
{| class="wikitable" style="text-align: center; margin: 1em auto 1em auto;"<br />
|+ '''Cronograma'''<br />
! Metas || Maio || Junho || Julho || Agosto || Setembro || Outubro || Novembro<br />
|-<br />
| 1 || X || X || X || || || || <br />
|-<br />
| 2 || || X || X || X || || || <br />
|-<br />
| 3 || || || || X || X || X || <br />
|-<br />
| 4 || || || || || X || X || X <br />
|-<br />
| 5 || || || || || || || X <br />
|}<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92810Mapas de Karnaugh 2D e 3D2015-09-04T17:26:22Z<p>Kristhine.sf: /* Proposta */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
'''1.''' Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
'''2.''' Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
'''3.''' Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de rotação através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
'''4.''' “Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
'''5.''' Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
{| class="wikitable" style="text-align: center; margin: 1em auto 1em auto;"<br />
|+ '''Cronograma'''<br />
! Metas || Maio || Junho || Julho || Agosto || Setembro || Outubro || Novembro<br />
|-<br />
| 1 || X || X || X || || || || <br />
|-<br />
| 2 || || X || X || X || || || <br />
|-<br />
| 3 || || || || X || X || X || <br />
|-<br />
| 4 || || || || || X || X || X <br />
|-<br />
| 5 || || || || || || || X <br />
|}<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92808Mapas de Karnaugh 2D e 3D2015-09-04T17:03:59Z<p>Kristhine.sf: /* Metodologia do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
'''1.''' Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
'''2.''' Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
'''3.''' Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de rotação através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
'''4.''' “Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
'''5.''' Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
{| class="wikitable" style="text-align: center; margin: 1em auto 1em auto;"<br />
|+ '''Cronograma'''<br />
! Metas || Maio || Junho || Julho || Agosto || Setembro || Outubro || Novembro<br />
|-<br />
| 1 || X || X || X || || || || <br />
|-<br />
| 2 || || X || X || X || || || <br />
|-<br />
| 3 || || || || X || X || X || <br />
|-<br />
| 4 || || || || || X || X || X <br />
|-<br />
| 5 || || || || || || || X <br />
|}<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92801Mapas de Karnaugh 2D e 3D2015-09-04T16:35:43Z<p>Kristhine.sf: /* Metodologia do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
'''1.''' Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
'''2.''' Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
'''3.''' Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de rotação através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
'''4.''' “Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
'''5.''' Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
<br />
<br />
{| align=center border=1<br />
|+'''Cronograma'''<br />
<br />
! Meta<br />
! Maio<br />
! Junho<br />
! Julho<br />
! Agosto<br />
! Setembro<br />
! Outubro<br />
! Novembro<br />
|-<br />
| Implementação do algoritmo de Quine McCluskey / Método de Petrick’s<br />
| X<br />
| X<br />
| X<br />
| <br />
| <br />
| <br />
| <br />
|-<br />
| Desenvolvimento de uma página web interativa <br />
| <br />
| X<br />
| X<br />
| X<br />
| <br />
| <br />
| <br />
|-<br />
| Cubo interativo numa página Web <br />
| <br />
| <br />
| <br />
| X<br />
| X<br />
| X<br />
| <br />
|-<br />
| “Colagem” dos mapas de Karnaugh no cubo<br />
| <br />
| <br />
| <br />
| <br />
| X<br />
| X<br />
| X<br />
|-<br />
| Finalização do leiaute da página<br />
| <br />
| <br />
| <br />
| <br />
| <br />
| <br />
| X<br />
|}<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92799Mapas de Karnaugh 2D e 3D2015-09-04T16:27:03Z<p>Kristhine.sf: /* Metodologia do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
'''1.''' Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
'''2.''' Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
'''3.''' Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de rotação através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
'''4.''' “Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
'''5.''' Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92798Mapas de Karnaugh 2D e 3D2015-09-04T16:26:20Z<p>Kristhine.sf: /* Metodologia do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
'''1.''' Estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
'''2.''' Desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
'''3.''' Construção da figura geométrica, mais especificamente em formato de cubo, com a possibilidade de seu giro através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
'''4.''' “Colagem” dos mapas de Karnaugh nas faces internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
'''5.''' Finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92797Mapas de Karnaugh 2D e 3D2015-09-04T16:18:35Z<p>Kristhine.sf: /* Proposta */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
A primeira etapa no desenvolvimento do projeto será o estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
A segunda etapa será o desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
A terceira etapa será uma etapa transitória, onde deverá ser construído uma figura geométrica em formato de cubo com a possibilidade de seu giro através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
A quarta etapa será a “colagem” dos mapas de Karnaugh nas fatias internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
A quinta e última etapa é a finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92795Mapas de Karnaugh 2D e 3D2015-09-04T16:11:09Z<p>Kristhine.sf: /* Metodologia do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
A primeira etapa no desenvolvimento do projeto será o estudo e implementação do algoritmo de Quine McCluskey e Método de Petrick’s. A implementação será validada com testes de simplificação de funções booleanas com até seis variáveis de entrada.<br />
<br />
A segunda etapa será o desenvolvimento de uma página web interativa que permita a escolha de número de variáveis de entrada e o estado de saída (0, 1 ou X) para tabelas-verdade que serão a base para gerar os respectivos Mapas de Karnaugh. Nesses mapas serão representados os agrupamentos realizados (simplificação da função) para o aprendizado do aluno. Nessa página, finalmente, será exibida a função com os implicantes primos mínimos. Também será necessário nessa etapa a instalação do servidor Apache. A validação ocorre com a conferência da página web e a veracidade dos resultados apresentados.<br />
<br />
A terceira etapa será uma etapa transitória, onde deverá ser construído uma figura geométrica em formato de cubo com a possibilidade de seu giro através de alguma interação do usuário visualizador da respectiva página web. A validação ocorre pela simples conferência visual e interativa dessa página.<br />
<br />
A quarta etapa será a “colagem” dos mapas de Karnaugh nas fatias internas do cubo obtido na etapa anterior para a visualização dos agrupamentos, permitindo que o usuário interaja e visualize nas três dimensões todos os agrupamentos criados, auxiliando assim sua compreensão na simplificação de expressões booleanas. Nessa página também será exibida a função com os implicantes primos mínimos. A validação ocorre com a conferência visual da página web, da visualização didática dos agrupamentos e da veracidade dos resultados apresentados.<br />
<br />
A quinta e última etapa é a finalização do leiaute da página, permitindo ao usuário selecionar o número de variáveis de entrada, completar a tabela-verdade e visualizar o respectivo mapa de Karnaugh, seja qual for a dimensão solicitada, bem como a função com os implicantes primos. Essa será a validação final.<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92761Mapas de Karnaugh 2D e 3D2015-09-03T20:45:42Z<p>Kristhine.sf: /* Referências Bibliográficas */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
<br />
<br />
== Referências Bibliográficas ==<br />
<br />
#Pedroni, Volnei A. Eletrônica Digital Moderna e VHDL, Editora Campus. 2010<br />
#TOCCI, Ronald J.; WIDMER, Sistemas digitais: Princípios e Aplicações, 2011<br />
#Richard, Clark, Introdução ao HTML5 e CSS3 - A Evolução da Web, 2014<br />
#Lawson, Bruce, Introdução ao HTML 5, Editora Alta Books. 2011</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92760Mapas de Karnaugh 2D e 3D2015-09-03T20:43:55Z<p>Kristhine.sf: /* Objetivos do Projeto */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
Esse projeto tem fundamental importância no aprendizado de álgebra Booleana, já que permitirá uma visualização gráfica dos mapas de Karnaugh com mais variáveis de entrada do que os sites já disponíveis, bem como obter, seja para conferência seja para resolução de projetos, a função mínima com implicantes primos.<br />
<br />
Essa solução servirá de base para todos os alunos da área de Telecomunicações do Campus São José do IFSC, que cursam disciplinas do tipo Eletrônica Digital e/ou Circuitos Lógicos. Ela estará disponível também universalmente a todos interessados, já que será disponibilizada gratuitamente através de um site web de acesso livre e, se possível, também através de apps para smartphones.<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
<br />
<br />
== Referências Bibliográficas ==</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92759Mapas de Karnaugh 2D e 3D2015-09-03T20:42:47Z<p>Kristhine.sf: /* Introdução e Justificativa da Proposição */</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
Na disciplina de Circuitos lógicos (CIL 29003) da Engenharia de Telecomunicações é abordado exaustivamente o conceito de Mapas de Karnaugh para simplificação de circuitos lógicos, objetivando a minimização de custos, consumo energético e maximização da velocidade de resposta dos circuitos projetados. Os Mapas de Karnaugh com até quatro variáveis são amplamente abordados na literatura e de fácil entendimento, existindo inclusive alguns sites que já os apresentam de forma visual e rápida, por exemplo, http://www.ee.calpoly.edu/media/uploads/resources/KarnaughExplorer_1.html.<br />
<br />
Para cinco ou seis variáveis de entrada sua apresentação, visualização e uso se tornam mais complexos, entretanto, são utilizados em alguns projetos executados no curso de Engenharia. Assim sendo, esse projeto tem por intuito criar um site onde possam ser criados, manipulados e visualizados mapas de até seis variáveis. Esse tipo de mapa requer uma apresentação tridimensional e, se realizado automaticamente com visualização remota, seja por computador, seja por smartfone, auxiliaria deveras a compreensão e execução por parte dos alunos.<br />
<br />
== Objetivos do Projeto ==<br />
<br />
<br />
<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
<br />
<br />
== Referências Bibliográficas ==</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Mapas_de_Karnaugh_2D_e_3D&diff=92756Mapas de Karnaugh 2D e 3D2015-09-03T20:35:24Z<p>Kristhine.sf: Criou página com 'Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José Aluno bolsista: Kristhine Schaeffer Fertig (Eng. Telecomunicações) Professor orientador: [[Odil...'</p>
<hr />
<div>Projeto financiado pela Chamada Interna 13/PRPPGI/2015 - Campus São José<br />
<br />
Aluno bolsista: [[Kristhine Schaeffer Fertig]] (Eng. Telecomunicações)<br />
<br />
Professor orientador: [[Odilson Tadeu Valle]]<br />
<br />
Período de execução: maio a novembro de 2015.<br />
<br />
= Proposta =<br />
<br />
== Introdução e Justificativa da Proposição ==<br />
<br />
<br />
<br />
<br />
== Objetivos do Projeto ==<br />
<br />
<br />
<br />
<br />
== Principais Contribuições do Projeto ==<br />
<br />
<br />
<br />
<br />
== Metodologia do Projeto ==<br />
<br />
<br />
<br />
== Referências Bibliográficas ==</div>Kristhine.sfhttps://wiki.sj.ifsc.edu.br/index.php?title=Rela%C3%A7%C3%A3o_dos_projetos_e_TCCs_desenvolvidos_no_campus_S%C3%A3o_Jos%C3%A9_do_IFSC&diff=92754Relação dos projetos e TCCs desenvolvidos no campus São José do IFSC2015-09-03T20:16:25Z<p>Kristhine.sf: </p>
<hr />
<div>Se você é professor do campus São José do IFSC, e está realizando/coordenando/orientando um projetos de Monitoria, Ensino, Pesquisa, Extensão, Gestão, ou TCC os dados na relação abaixo devem estar corretos, pois serão utilizados como critério na distribuição das disciplinas no próximo semestre. <br />
*Se os dados do seu projeto ou TCC estão desatualizados, ou não constam da relação, '''utilize o formulário de [https://docs.google.com/forms/d/1Iuf7lXj-H0MkV0gzsiFDXIgH69CSIXuZGAx5mQ6HB7E/viewform?usp=send_form Cadastro de projetos e TCCs] para cadastra-lo'''.<br />
*Note que cada título de projeto/TCC dispõe de um link automático para uma página wiki. Se o link estiver em vermelho indica duas possibilidades: 1) Nada consta na wiki com este título; 2) Tem alguma diferença entre o nome do projeto e nome da página wiki onde o projeto/TCC está sendo documentado. No primeiro caso o recomendável é criar uma página mínima contendo pelo menos o resumo do projeto. No segundo caso pode ser usado o comando <nowiki> #REDIRECT [[Titulo_da_pagina_wiki]] </nowiki><br />
*'''ATENÇÃO PESSOAL!!! Nunca insira dados diretamente na Wikitable abaixo, pois os dados digitados serão perdidos na próxima atualização.''' <br />
<br />
{{Collapse top |expand = 1|Semestre 2015-2}}<br />
{{InicioTabCadastroProj}}<br />
<!--NÃO MEXA AQUI USE O FORM, DEPOIS SE QUISER COPIE A COLUNA WIKICODE DO FORM PARA CÁ--><br />
{{TabCadastroProj | |Projeto de Ensino |INCENTIVANDO O USO DO SIMULINK NOS CURSOS DE TELECOMUNICAÇÕES | Rogério Pereira Junior | Marcos Moecke | | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC2 |Estudo de circuitos aritméticos e implementação em Dispositivo Lógico Programável | Kamila Rose da Silva | Marcos Moecke | | 8/7/2015 | 31/12/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC2 |Implantação de alta disponibilidade em PABX IP | Maicky Charles Müller | Ederson Torresini | | 15/4/2015 | 15/8/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Elaboração de experimentos práticos e roteiros didáticos para a disciplina de Circuitos de Rádio Frequência utilizando a plataforma de Rádio Definido por Software | LEONAN DA SILVA SARAIVA | Rubem Toledo Bergamo | | 4/5/2015 | 4/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Reconhecimento de comando via impulsos cerebrais usando redes neurais artificiais para auxiliar portadores de tetraplegia | Thiago Werner | Elen Macedo Lobato | Eraldo Silveira e Silva | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Mapas de Karnaugh 2D e 3D | Kristhine Schaeffer Fertig | Odilson Tadeu Valle | | 1/5/2015 | 1/12/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC1 |Sistema de controle de acesso patrimonial autônomo utilizando o RFID | Renan Gonçalves | Arliones Stevert Hoeller Junior | | 1/9/2014 | 1/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Concepção de Experimentos de Sistemas Embarcados para Disciplinas do Curso de Engenharia de Telecomunicações | Katharine Schaeffer Fertig | Arliones Stevert Hoeller Junior | | 1/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Implementação de experimentos para o ensino de propagação de sinais em meios guiados e espaço livre | Paula Cristina Grando | Saul Silva Caetano | Ramon Mayor | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Sistema Automatizado de Inspeção de Dutos de Sistemas de Condicionamento de Ar | Bruno Antônio de Pinho | Tiago Semprebom | Eraldo Silveira e Silva | 1/5/2015 | 4/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Material de Apoio ao Aprendizado de Circuitos ElétricosI | Anderson Gaspar de Medeiros | Volney Duarte Gomes | | 1/5/2015 | 31/10/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Projeto integrador do curso tecnico integrado ao médio em telecomunicações | Jéssica Caetano Rodrigues | Ederson Torresini | | 1/5/2015 | 29/11/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC1 |Sistema Ubíquo para Apoio à Vacinação de Crianças de 0 a 10 anos | Bruna Amante | Francisco de Assis Souza dos Santos | | 23/4/2015 | 21/12/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC1 |Melhorias no Sistema de Supervisão de Energia do IFSC-SJ | Felipe Artur Mariano | Eraldo Silveira e Silva | | 5/2/2015 | 3/7/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Oficina de Robótica | Vitor Hugo de Oliveira Vargas | Diego da Silva de Medeiros | Fernando Bruinjé Cosentino | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Reconhecimento de voz através de redes neurais artificiais utilizando a transformada Wavelet | Mathias Silva da Rosa | Deise Monquelate Arndt | Elen Macedo Lobato/ Ramon Mayor | 15/5/2015 | 15/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Oficina de construção de robôs | Vitor Hugo de Oliveira Vargas | Fernando Bruinjé Cosentino | Diego da Silva de Medeiros | 1/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de monitoria |Monitoria Química | Nathan Roberto Lohn Pereira | Éder da Silva e Sá | | 1/5/2015 | 20/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de monitoria |Aluna Monitora para os cursos de Licenciatura | Layssa Alves Pacheco | Madeline Odete Correa | | 1/5/2015 | 31/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Um MAC Flexível para Redes Sem-Fio IEEE 802.11 | Ronaldo João Borges | Marcelo Maia Sobral | | 1/8/2015 | 31/7/2016 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Um MAC Flexível para Redes Sem-Fio IEEE 802.11 | Mathias Hillesheim | Marcelo Maia Sobral | | 1/8/2015 | 31/7/2016 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC2 |Estabelecimento de um enlace IEEE 802.11 ponto-a-ponto de alta vazão | Nadir Bernardo Bianchini | Marcelo Maia Sobral | | 1/8/2015 | 15/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Dispositivo discriminador de moedas e objetos | Não há aluno bolsista | Diego da Silva de Medeiros | Marcos Moecke | 1/1/2014 | 31/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Implementação de sistemas de telecomunicações digitais utilizando simulink e HDL coder | Lucas Lucindo Vieira | Marcos Moecke | | 1/8/2015 | 31/7/2016 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |IFSC Ideias Inovadoras | Jessica da Silva Hahn | Marcos Moecke | | 15/9/2015 | 15/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |IFSC Ideias inovadoras | Katharine Schaeffer Fertig | Marcos Moecke | | 1/9/2015 | 19/12/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC2 |CRIAÇAO DE UMA INFRAESTRUTURA PARA VOIP FEDERADO | FABIANO ESCHER GONÇALVES | EDERSON TORRESINI | | 1/8/2015 | 10/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |IFSC Ideias Inovadoras | Leticia Aparecida Coelho | Marcos Moecke | | 1/9/2015 | 31/12/2015 | }}<br />
{{FimTabTCC}}<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top | Semestre 2015-1}}<br />
{{InicioTabCadastroProj}}<br />
<!--NÃO MEXA AQUI USE O FORM, DEPOIS SE QUISER COPIE A COLUNA WIKICODE DO FORM PARA CÁ--><br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC2 |Implantação de alta disponibilidade em PABX IP | Maicky Charles Müller | Ederson Torresini | | 15/4/2015 | 15/8/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Elaboração de experimentos práticos e roteiros didáticos para a disciplina de Circuitos de Rádio Frequência utilizando a plataforma de Rádio Definido por Software | LEONAN DA SILVA SARAIVA | Rubem Toledo Bergamo | | 4/5/2015 | 4/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Reconhecimento de comando via impulsos cerebrais usando redes neurais artificiais para auxiliar portadores de tetraplegia | Thiago Werner | Elen Macedo Lobato | Eraldo Silveira e Silva | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Mapas de Karnaugh 2D e 3D | Kristhine Schaeffer Fertig | Odilson Tadeu Valle | | 1/5/2015 | 1/12/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC1 |Sistema de controle de acesso patrimonial autônomo utilizando o RFID | Renan Gonçalves | Arliones Stevert Hoeller Junior | | 1/9/2014 | 1/12/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC2 |Redes IEEE 802.15.4 para aplicações seguras | Leonardo Pereira | Arliones Stevert Hoeller Junior | | 1/9/2014 | 1/7/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Concepção de Experimentos de Sistemas Embarcados para Disciplinas do Curso de Engenharia de Telecomunicações | Katharine Schaeffer Fertig | Arliones Stevert Hoeller Junior | | 1/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Implementação de experimentos para o ensino de propagação de sinais em meios guiados e espaço livre | Paula Cristina Grando | Saul Silva Caetano | Ramon Mayor | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |INCENTIVANDO O USO DO SIMULINK NOS CURSOS DE TELECOMUNICAÇÕES | Rogério Pereira Junior | Marcos Moecke | | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Sistema Automatizado de Inspeção de Dutos de Sistemas de Condicionamento de Ar | Bruno Antônio de Pinho | Tiago Semprebom | Eraldo Silveira e Silva | 1/5/2015 | 4/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Material de Apoio ao Aprendizado de Circuitos ElétricosI | Anderson Gaspar de Medeiros | Volney Duarte Gomes | | 1/5/2015 | 31/10/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Projeto integrador do curso tecnico integrado ao médio em telecomunicações | Jéssica Caetano Rodrigues | Ederson Torresini | | 1/5/2015 | 29/11/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC1 |Sistema Ubíquo para Apoio à Vacinação de Crianças de 0 a 10 anos | Bruna Amante | Francisco de Assis Souza dos Santos | | 23/4/2015 | 21/12/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC1 |Estudo de circuitos aritméticos e implementação em Dispositivo Lógico Programável | Kamila Rose da Silva | Marcos Moecke | | 8/5/2015 | 7/7/2015 | }}<br />
{{TabCadastroProj | |Trabalho de Conclusão de Curso - TCC1 |Melhorias no Sistema de Supervisão de Energia do IFSC-SJ | Felipe Artur Mariano | Eraldo Silveira e Silva | | 5/2/2015 | 3/7/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Oficina de Robótica | Vitor Hugo de Oliveira Vargas | Diego da Silva de Medeiros | Fernando Bruinjé Cosentino | 4/5/2015 | 30/11/2015 | }}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Reconhecimento de voz através de redes neurais artificiais utilizando a transformada Wavelet | Mathias Silva da Rosa | Deise Monquelate Arndt | Elen Macedo Lobato/ Ramon Mayor | 15/5/2015 | 15/12/2015 | }}<br />
{{TabCadastroProj | |Projeto de Ensino |Oficina de construção de robôs | Vitor Hugo de Oliveira Vargas | Fernando Bruinjé Cosentino | Diego da Silva de Medeiros | 1/5/2015 | 30/11/2015 | }}<br />
{{FimTabTCC}}<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |Semestre 2014-2}}<br />
;Semestre 2014-2:<br />
{{InicioTabCadastroProj}}<br />
<!--NÃO MEXA AQUI USE O FORM, DEPOIS SE QUISER COPIE A COLUNA WIKICODE DO FORM PARA CÁ--><br />
{{TabCadastroProj | 207|Projeto de Pesquisa |Modernização das aulas de Laboratório de Circuitos Lógicos: Implementação | Kamila Rose da Silva | Marcos Moecke | | 01/04/2014 | 31/12/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de monitoria |Monitoria de Geometria Analítica e Álgebra Linear & Monitoria de Matemática Básica | Karoline da Rocha | Sergio Florentino da Silva | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | 290|Projeto de monitoria |Monitoria de Cálculo | Walter Cardoso de Freitas | Madeline Odete Silva Correa | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | 290|Projeto de monitoria |Monitoria de Circuitos e Eletrônica | Leonan da Silva Saraiva | Pedro Armando da Silva Jr. | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | 290|Projeto de monitoria |Monitoria de Física | Thiago Henrique Bonotto da Silva | Marcelo Girardi Schappo | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | 290|Projeto de monitoria |Monitoria de Programação | Jean Michel de Souza Sant'Ana | Marcelo Maia Sobral | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC2 |Projeto de Interface de Telefonia Analógica USB para sistemas VOIP | Maycon Rodrigo Moreira | Roberto de Matos | Marcelo Maia Sobral | 14/07/2014 | 19/12/2014 | 2}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC1 |Explorando as Interfaces Ethernet da placa DE2-115 | Felipe Artur Mariano | Roberto de Matos | | 28/07/2014 | 18/12/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de Pesquisa |Desenvolvimento de um gateway WIFI –Bluetooth 4.0 usando a placa nrf51 |Thiago Werner | Eraldo Silveira e Silva | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | |Projeto de Pesquisa |Programar para não ser programado | | Maria Claudia Castro | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | 290|Projeto de Pesquisa |Simplificação de projetos para a disciplina de Projeto Integrador I | Fernando Muller da Silva | Saul Silva Caetano | Roberto de Matos | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | |Projeto de Pesquisa | Revitalização do laboratório de Meios de Transmissão | sem aluno | Saul Silva Caetano | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj | 608|Projeto de Pesquisa |Desenvolvimento de robôs para OBR | Davi Goulart | Diego da Silva de Medeiros | Roberto Wanderley da Nobrega | 01/05/2014 | 31/09/2014 | 1}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC2 |Implementação e avaliação de cenário de convergência telefonia-rede integrando serviços de VoIP e video-chamada com o uso de WebRTC | Rafael Ossamu Togo | Arliones Stevert Hoeller Junior | | 10/02/2014 | 15/12/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de Pesquisa |Avaliação em Campo de Rendimento de Motores de Indução Trifásicos | Guilherme Evangelista de Albuquerque | Pedro Armando da Silva Júnior | | 05/05/2014 | 22/11/2015 | 6}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC2 | Rede de telefonia colaborativa com VoIP | Nicole da Rosa Feijó | Marcelo Maia Sobral | | 01/08/2014 | 20/12/2014 | 2}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC2 |Tarifador de chamadas para FreeSwitch | Renato Muller Rosa | Marcelo Maia Sobral | | 01/08/2014 | 20/12/2014 | 2}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC2 |Sistema de Identificação Veicular | Thiago José Silveira | Eraldo Silveira e Silva | | 01/07/2014 | 13/12/2014 | 1}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC2 |Testes de Conformidade em Smart Switches | Ismael Matiola | Eraldo Silveira e Silva | Odilson Tadeu Valle | 01/07/2014 | 12/12/2014 | 1}}<br />
{{TabCadastroProj | 290|Projeto de Extensão |Intérprete Automático da Linguagem Brasileira de Sinais (LIBRAS) | Elton Ferreira Broering | Arliones Stevert Hoeller Junior | | 01/07/2014 | 09/11/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de Extensão |Intérprete Automático da Linguagem Brasileira de Sinais (LIBRAS) | Thiago Henrique Bonotto da Silva | Arliones Stevert Hoeller Junior | | 01/07/2014 | 09/11/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de Extensão |Intérprete Automático da Linguagem Brasileira de Sinais (LIBRAS) | Guilherme Evangelista de Albuquerque | Arliones Stevert Hoeller Junior | | 01/07/2014 | 09/11/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de Pesquisa |Smart Node – Plataforma SDR para segurança de frotas | Thiago Henrique Bonotto da Silva | Roberto de Matos | | 01/04/2014 | 01/04/2015 | 3}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC1 |Controle de acesso seguro com RFID e rede sem fios | Leonardo Pereira | Arliones Stevert Hoeller Junior | | 04/08/2014 | 11/12/2014 | 1}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC1 |Controle de acesso seguro com RFID e rede sem fios | Renan Gonçalves | Arliones Stevert Hoeller Junior | | 04/08/2014 | 12/12/2014 | 1}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC2 |Ambiente Virtual de Aprendizagem de Sinais e Sistemas - Módulos Estendidos | Rafael da Silva Pereira | Roberto Wanderley da Nóbrega | | 12/08/2014 | 12/12/2014 | 2}}<br />
{{TabCadastroProj | Externo|Projeto de Pesquisa |Dispositivo discriminador de moedas e objetos | Edgard Ubaldo Guillen Salas | Diego da Silva de Medeiros | Marcos Moecke | 01/01/2014 | 31/12/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de Pesquisa |Um protocolo de transporte eficiente para redes IEEE 802.11 | Ângelo Damasio Machado | Marcelo Maia Sobral | | 01/08/2014 | 31/07/2015 | 3}}<br />
{{TabCadastroProj | 290|Projeto de Pesquisa |Micro vídeo aulas como ferramentas de ensino:aplicação na área de circuitos lógicos | Layssa Alves Pacheco | Marcos Moecke | | 01/09/2014 | 31/12/2014 | 2}}<br />
{{TabCadastroProj | 290|Projeto de Pesquisa |Identificação automática de símbolos da linguagem de sinais por vídeo | Thiago Henrique Bonotto da Silva | Arliones Stevert Hoeller Junior | | 01/09/2014 | 30/11/2014 | 1}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC1 |Automação residencial inteligente | Mariana Mohr Silveira | Arliones Stevert Hoeller Junior | | 01/08/2014 | 15/12/2014 | 1}}<br />
{{TabCadastroProj | 207|Trabalho de Conclusão de Curso - TCC1 |Mobilidade de terminal e de sessão usando o protocolo SIP sobre o Android: análise e proposta de soluções | Diogo Avallone Mariano | Ederson Torresini | | 08/09/2014 | 02/12/2014 | 4}}<br />
{{FimTabTCC}}<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |Semestre 2014-1}}<br />
{{InicioTabCadastroProj}}<br />
<!--SE HOUVER CORREÇÕES NESTES DADOS MEXA DIRETAMENTE AQUI POIS AINDA NÃO HAVIA FORM--><br />
{{TabCadastroProj |207 | Projeto de Pesquisa | Criação de uma rede telefônica colaborativa com VoIP| Nicole da Rosa Feijó | Marcelo Maia Sobral | | 01/04/2014 | 30/06/2014 | 1}}<br />
{{TabCadastroProj |207| Projeto de Pesquisa | Desenvolvimento e implementação de tags de RFID ativo |Bruno Antônio Pinho | Eraldo Silveira e Silva | | 01/04/2014 | 30/06/2014 | 1}}<br />
{{TabCadastroProj |290| Projeto de Pesquisa | Levantamento de perfil energético de um módulo de redes de sensores sem fios | Marcus Vinicius Bunn | Arliones S. Hoeller Jr. | | 01/04/2014 | 30/06/2014 | 1}}<br />
{{TabCadastroProj |290| Projeto de Pesquisa | Despertando para a área técnica através de atividades lúdicas | Lucas Lucindo | Alexandre Moreira e Saul Caetano | |01/04/2014 | 30/06/2014 | 1}}<br />
{{TabCadastroProj |207| Projeto de Pesquisa | Restauração de filmes antigos através do processamento de imagens | Patricia Alves Machado | Diego da Silva de Medeiros | | 01/04/2014 | 30/06/2014 | 1}}<br />
{{TabCadastroProj || Projeto de Pesquisa | Projetos para a disciplina de Projeto Integrador I | | Roberto de Matos e Saul Caetano | | Maio/2014 | Setembro/2014 | 1}}<br />
{{TabCadastroProj |608| Projeto de Pesquisa | Desenvolvimento de robôs para OBR | Davi Goulart | Diego da Silva de Medeiros e Roberto Wanderley da Nobrega | | Maio/2014 | Setembro/2014 | 1}}<br />
{{TabCadastroProj |207| Projeto de Pesquisa |Modernização das aulas de Laboratório de Circuitos Lógicos: Implementação | Kamila Rose da Silva | Marcos Moecke | | 01/04/2014 | 31/12/2014 | 2}}<br />
{{TabCadastroProj |290| Projeto de Pesquisa |Vídeo-tutoriais de ensino como ferramentas de auxílio - aplicação na área de circuítos lógicos | Tamara Ramos Arrigoni | Marcos Moecke | | 01/04/2014 | 30/06/2014 | 2}}<br />
{{TabCadastroProj |290| Projeto de monitoria |Monitoria de Geometria Analítica e Álgebra Linear & Monitoria de Matemática Básica | Karoline da Rocha | Sergio Florentino da Silva | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj |290| Projeto de monitoria |Monitoria de Cálculo | Walter Cardoso de Freitas | Madeline Odete Silva Correa | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj |290| Projeto de monitoria |Monitoria de Circuitos e Eletrônica | Leonan da Silva Saraiva | Pedro Armando da Silva Jr. | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj |290| Projeto de monitoria |Monitoria de Física | Thiago Henrique Bonotto da Silva | Marcelo Girardi Schappo | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{TabCadastroProj |290| Projeto de monitoria |Monitoria de Programação | Jean Michel de Souza Sant'Ana | Marcelo Maia Sobral | | 01/04/2014 | 31/12/2014 | 1}}<br />
{{FimTabTCC}}<br />
{{Collapse bottom}}<br />
<br />
{{Collapse top |Semestre 2013-2}}<br />
{{InicioTabCadastroProj}}<br />
<!--SE HOUVER CORREÇÕES NESTES DADOS MEXA DIRETAMENTE AQUI POIS AINDA NÃO HAVIA FORM--><br />
{{TabCadastroProj|290|Projeto de pesquisa| Sensoriamento remoto de dados metereológicos via crowdsourcing | Flávia de Oliveira Barbosa| Marcelo Maia Sobral | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de ensino| Uso do Scratch e da plataforma Arduino para ensino de programação e conceitos básicos de telecomunicações | Fabio Mafra| Saul Silva Caetano | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|402|Projeto de monitoria| Monitoria em Química | Priscila Cani Vieira Assunção| Éder da Silva e Sá | |7/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de pesquisa| Revitalização dos Laboratórios de Microcontroladores | Bruno Carminatti da Silva| Eraldo Silveira e Silva | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de pesquisa| Desenvolvimento e Implantação de um Sistema Supervisório de Energia Elétrica no IFSC. | Giulio Cruz de Oliveira| Prof. Pedro Armando da Silva Júnior | |9/2013 |9/2014| }} <br />
{{TabCadastroProj|290|Projeto de pesquisa| Sistema Supervisório de Energia Elétrica do IFSC | Jessica da Silva Hahn| Pedro Armando da Silva Júnior | |9/2013 |9/2014| }} <br />
{{TabCadastroProj|290|Projeto de monitoria| Monitoria de Cálculo | Marcus Vinicius Bunn| Elenira Vilela | |7/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de monitoria| Monitoria De Circuitos e Eletrônica | Leonan Da Silva Saraiva| Jaci Destri | |7/2013 |7/2013| }} <br />
{{TabCadastroProj|207|Projeto de monitoria| Monitoria de Programação | Beatriz da Silveira| Eraldo Silveira e Silva | |7/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de ensino| Revitalização do laboratório de Telefonia IP | Amanda Coelho Borges| Fabio Alexandre de Souza | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de monitoria| Monitoria de Física | Thiago Henrique Bonotto da Silva| Marcelo Girardi Schappo | |6/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC2| Restauração de filmes antigos via processamento de imagem | Patricia Alves Machado| Diego da Silva de Medeiros | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de pesquisa| Microprocessadores - Pesquisa e Execução | Thiago Werner| Roberto Matos | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC2| Tolerância a Falhas e Balanceamento de Carga em Redes Multi-Homing | Helton Luiz Porto| Eraldo Silveira | |9/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de Pesquisa| Elaboração de programas scratch para o ensino interativo de conceitos em redes de telecomunicações. | Roicenir Girardi Rostirolla| Eraldo Silveira e Silva |Saul Silva Caetano |9/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Projeto de Pesquisa| Modernização das aulas de Laboratório de Circuitos Lógicos | Kamila Rose da Silva| Marcos Moecke | |5/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC1| Rede de telefonia colaborativa com VoIP | Nicole da Rosa Feijó| Marcelo Maia Sobral | |9/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC2| Detecção de Crises Epilépticas Baseado em Sinais de Eletroencefalograma Utilizando Reconhecimento de Padrões | Ana Paula Rosa Negri| Diego da Silva de Medeiros |Elen Macedo Lobato Merlim |9/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Projeto de Pesquisa| Identificação de Crises Epilépticas Baseado em Sinais de Eletroencefalograma Utilizando Reconhecimento de Padrões | Ana Paula Rosa Negri| Diego da Silva de Medeiros | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC2| VisualTCNG - Uma interface gráfica amigável para construção de regras de QoS no Linux | Luiz Gustavo Ender| Emerson Ribeira de Mello | |3/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de monitoria| Monitoria de algebra linear e Geometria analitica | karoline da rocha| Sérgio Florentino da Silva | |7/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC1| Aumento da capacidade de uma rede mesh IEEE 802.11 com uso de múltiplos canais | Anderson Rosa| Marcelo Maia Sobral | |9/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de Extensão| Elaboração de plataforma para o desenvolvimento do projeto da disciplina de programação I | André Felippe Weber| Eraldo Silveira e Silva | |4/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC2| Identificação de moedas via processamento de imagem: abordagem via reconhecimento de texturas | Kelly Hilleshein| Diego da Silva de Medeiros | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC1| Software para Avaliação de Atividades de natação com RFID | Adriano dos Santos| Márcio Doniak | |8/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC1| Implantação de uma Comunidade Acadêmica Federada para Experimentação usando Framework Shibboleth | Maykon Chagas de Souza| Michelle Silva Wangham |Emerson Ribeiro de Mello |8/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC1| Criação de interface web para o Netkit | Ricardo Martins| Marcelo Maia Sobral | |9/2013 |12/2013| }} <br />
{{TabCadastroProj|290|Projeto de Pesquisa| Projeto Forma-Engenharia | Jean Michel de Souza Sant' Ana| Marcos Moecke |Eraldo Silveira e Silva / Saul Silva Caetano |3/2013 |2/2014| }} <br />
{{TabCadastroProj|290|Projeto de Ensino| Ensino e Aprendizagem de Matemática com Vídeos | Guilherme Evangelista de Albuquerque| Sérgio Florentino da Silva |Jaci Destri |4/2013 |12/2014| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC2| OpenStack com Open vSwitch e SDN | Rafael Turnes Silveira| Ederson Torresini | |9/2013 |12/2013| }} <br />
{{TabCadastroProj|207|Trabalho de Conclusão de Curso - TCC2| Sistema de Medição e Treinamento para Esportes Equestres baseado em RFID ativo | Bruno Antonio de Pinho| Eraldo Silveira e Silva | |10/2013 |12/2013| }} <br />
{{FimTabTCC}}<br />
{{Collapse bottom}}<br />
<br />
Link curto para esta página: http://bit.ly/Projeto_TCC_TELE_IFSC</div>Kristhine.sf