1 / 86

Protocolos de comunicação em tempo real

Protocolos de comunicação em tempo real. Daniel Brito Igor Morais Onildo Ferraz Thiago Menezes. Introdução. RTC vêm sendo implementados cada vez mais em plataformas distribuídas Baratas Tolerantes a falhas Todos os sistemas distribuídos de tempo real Têm como base uma rede de comunicação

carys
Télécharger la présentation

Protocolos de comunicação em tempo real

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Protocolos de comunicação em tempo real Daniel Brito Igor Morais Onildo Ferraz Thiago Menezes

  2. Introdução • RTC vêm sendo implementados cada vez mais em plataformas distribuídas • Baratas • Tolerantes a falhas • Todos os sistemas distribuídos de tempo real • Têm como base uma rede de comunicação • Entrega as mensagens no tempo certo

  3. Definição • Em Comunicação de Tempo Real, as aplicações que a utilizam têm requisitos de qualidade de serviço (Quality of Service – QoS) • Latência máxima (maximum delay) • Mínima largura de banda • Delay jitter • Máxima taxa de perda de pacotes

  4. Latência(Delay) • Tempo contado desde que o pacote sai do adaptador de rede do nó remetente até quando chega no adaptador de rede do nó destinatário. • O sucesso da transmissão depende não só da integridade, mas de o pacote chegar no tempo certo. • Em caso de fracasso, pode acontecer uma catástrofe (hard), ou degradação (soft)

  5. Jitter • Máxima variação do delay • Um jitter suficientemente alto causa degradação em uma aplicação de streaming de vídeo (soft real time). • Para combater o jitter se usa um buffer no nó de recepção • Para um vídeo com um bitrate de 60MBps, e uma transmissão streaming com Jitter de 1s, usaria-se um buffer de 60MB.

  6. Largura de banda • A banda obviamente deve ser larga o suficiente para garantir a vazão de dados do sistema.

  7. Taxa de perda de pacotes • Percentagem de pacotes que são perdidos ou descartados em sua chegada (seja por atraso, corrompimento, ou buffer overflow) • Aplicações de controle (hard real time) não admitem perda de pacotes • Aplicações multimídia (soft real time) admitem perdas

  8. Os requisitos QoS variam • Cada aplicação é um caso • Um sistema fly-by-wire é muito sensível a delay (não admite delay maior que 1ms), e perdas de pacote são inaceitáveis • Sistema de streaming de voz é pouco sensível a delay, e mantem uma performance razoável mesmo com certa perda de pacotes • Um jogo online de tiro em primeira pessoa é bastante sensível a delay e a perda de pacotes

  9. Protocolos de Enlace Tradicionais • São de máximo esforço (ex.: Ethernet) • Não dão garantias • São utilizadas em situações onde alta latência e alta perda de pacotes (resolvida com retransmissões) são aceitáveis. • Portanto, não servem para Aplicações de Tempo Real

  10. Aplicações non Real Time • Preocupam-se bastante com perda de pacotes (integridade da informação) • Não preocupam-se muito com delay, jitter, largura de banda.

  11. Aplicações de RTC • Robôs de uma linha de produção • Trocam informações com o controlador • Hard Real Time: controle, dados de sensores • Soft Real Time: logs

  12. Aplicações de RTC • Planta Química

  13. Aplicações de RTC • Jogos Online Multiplayer

  14. Tipos de Redes • Três tipos de redes são relevantes • Controller Area Network (CAN) • Local Area Network (LAN) • Internet

  15. Controller Area Network • Surgiu nos automóveis • Comunicação entre sistemas embarcados • Antes de CAN, se usava ligações ponto-a-ponto • Robusta, funciona sob forte ruído • Expandida para outras aplicações • Aviões, navios, controle industrial, etc.

  16. Local Area Network • Rede privada que conecta computadores e compartilha recursos como impressoras e scanners • Operam tipicamente a 10 ou 100Mbps. • Broadcast

  17. Internet

  18. Categorização de Tráfego • O tipo de tráfego deve ser conhecido em tempo de projeto para a rede poder garantir a QoS • Há três categorias importantes • Constant Bit Rate traffic • Variable Bit Rate traffic • Sporadic traffic

  19. Constant Bit Rate traffic • Fonte gera dados a uma taxa constante • Em aplicações de Tempo Real, o tráfego costuma ser constante • Ex.: Informações periódicas de sensores

  20. Variable Bit Rate traffic • Fonte gera dados a diferentes taxas em diferentes momentos. Há dois tipos de VBR: • Fonte alterna entre CBRs diferentes • Fonte não gera dados a taxas constantes • Exemplos: • Áudio MP3 (codificado em VBR): em trechos de silêncio no áudio, nenhuma informação é enviada • Vídeo: ocorre muita redundância de informação entre um frame e outro

  21. Sporadic traffic • Rajadas de pacotes entre intervalos mínimos de silêncio • Exemplo: despertador

  22. Comunicação de Tempo Real em LAN • LAN Broadcast • Canal compartilhado por todos • Apenas um nó pode transmitir por vez • Protocolo de Controle de Acesso ao Meio • As duas arquiteturas LAN mais usadas: • Barramento • Anel

  23. Arquitetura de Barramento • Todos os computadores conectados ao mesmo barramento • Protocolo MAC mais comum é o CSMA/CD • Nós devem estar próximos por causa do atraso de propagação • Ethernet é o padrão mais usado no mundo • Por isso, houve tentativas de se criar protocolos RTC baseados em Ethernet

  24. Arquitetura de Barramento • Ponto positivo: Fail silent • Ponto negativo: política de acesso baseada em colisão (não serve para Tempo Real Hard)

  25. Arquitetura de Anel • Nesta arquitetura, cada nó transmite na sua vez durante um intervalo de tempo pré-determinado.

  26. Arquitetura de Anel • Ponto positivo: Mais vantajosa do que Barramento, devido à sua política de acesso determinista e arbitrária (serve para Tempo Real Hard) • Ponto negativo: Se um nó falhar, a rede toda falha • Ponto negativo: Difícil de instalar em uma indústria, por ex.

  27. Token Bus • Os pesquisadores encontraram uma arquitetura que reúne benefícios de ambas • Usa barramento, mas implementa anél lógico • Não existe a dificuldade de instalação (não importa a ordem física com que os computadores se ligam ao barramento). • O protocolo de acesso pode adicionar ou remover nós

  28. LAN Local Area Network

  29. Comunicações Real Time Soft em LAN • Não garante nenhum limite em QoS • Dá apenas “garantias estatísticas” • Tratamento prioritário a mensagens RT para manter a taxa de deadlines ultrapassados dentro do “garantido”

  30. Comunicações Real Time Soft em LAN • Mensagens RT e non-RT trafegam no mesmo meio • Mensagens RT são CBR ou VBR • Mensagens non-RT são aperiódicas e chegam em rajadas • As rajadas são o problema. • É preciso amenizá-las • Fixed-rate Traffic Smoothing • Adaptive-rate Traffic Smoothing

  31. Fixed-rate Traffic Smoothing • Kweon e Shin • Algoritmo que suaviza as rajadas • Credit Bucket Depth (CBD) • Baseia-se no limite de transmissão da rede • Impõe um limite de transmissão média non-RT para cada fonte

  32. Credit Bucket Depth • Cada fonte tem um balde • Cada balde contém créditos que serão usados para a transmissão de mensagens non-RT • Dois parâmetros (estáticos): • CBD (profundidade do balde) • RP (Refresh Period) • A razão CBD/RP é a vazão média garantida para mensagens non-RT

  33. Credit Bucket Depth • O saldo de créditos em um balde se chama CNS • O CNS determina se a mensagem non-RT que chega será enviada ou não • A cada refresh, o balde é enchido com mais CBD créditos • CNS = min (CBD, CNS + CBD)

  34. Fixed-rate Smoothing • Desvantagem: • A vazão de fontes non-RT considera o pior caso de uso da rede. • O limite de vazão das fontes diminui a cada nó que é adicionado à LAN

  35. Adaptive-rate Smoothing • Kweon e Shin • Os nós podem aumentar sua vazão média se o barramento estiver livre (ou diminuí-los, caso esteja ocupado) • O número de colisões por unidade de tempo é usado como critério • CBD/RP • Resultados experimentais demonstraram que a vazão para non-RT melhorou, sem prejudicar as “garantias estatísticas” para mensagens RT

  36. Adaptive-rate Smoothing • Não serve para Tempo Real Hard • Por que? Se parte da taxa de transmissão é reservada para RT. • Razão simples: colisões ocorrem (com frequência)

  37. Comunicações em Hard-Real Time em LAN • Previsibilidade determinística de atrasos • Prever deterministicamente o tempo necessário para o envio de um mensagem • Geralmente envolve tráfico CBR • São normalmente suportados pelos os seguintes protocolos: • Escalonamento baseado em agenda(CalendarBasedScheduling) • Protocolos de prioridade global(Global PriorityProtocols) • Escalonamento de acesso limitado(BoundedAcessScheduling)

  38. Escalonamento Baseado em Agenda • Mantém uma Agenda • Tempo e o intervalo de tempo que cada nó tem para transmissão • Cada nó mantem uma copia da Agenda • Pode haver alocações dinâmica via broadcasting • AlgoritimamenteSimples • Eficiente quando todas as mensagens são periódicas

  39. Protocolos baseado em prioridade global • Cada mensagem tem um valor que representa sua prioridade • Tentar garantir que o canal esteja sempre com a tarefa de maior prioridade • Exemplos: • CountDown Protocol • IEEE 802.5

  40. CountDownProtocol • A linha do tempo é dividida em intervalos de tempos fixos chamados slots. • No começo de cada intervalo uma arbitragem de prioridade é realizada

  41. CountDownProtocol • A Arbitragem de Prioridades: • Dividida em slots de tamanho fixos. • Cada slots é o tempo necessário para o envio de um bit • Cada nó envia uma mensagem binária com sua prioridade, começando pelo o bit de maior ordem. • No final de cada slot é feita uma verificação onde o nó averigua a sua prioridade diante a dos outros nó, se sua prioridade é menor então ele deixa de enviar • O nó que enviar toda a mensagem por completo, é o nó que tem maior prioridade

  42. CountDownProtocol • Exemplo: • 3 nós na Lan • N1 = 10(01010) , N2 = 16(10000) , N3 = 20(10100) • N3 > N2 > N1

  43. IEEE 802.5 • Protocolo baseado em redes token ring • Evoluiu da rede “IBM token-ring network” • Esquema de prioridade para adquiri o Token • 8 níveis de prioridade • Tipos de Pacote: • Token • Frame

  44. IEEE 802.5 • Token • 1 Byte para determinar começo do pacote • 1 Byte para Controle de Acesso • Campo de prioridade • Token bit identifica se é frame ou token • Monitor ring bit ( Monitorar o token ) • Reservation Bits, campo para determinar prioridade do proximo token • 1 Byte para determinar o fim do pacote

  45. IEEE 802.5 • Frame • 1 Byte para determinar começo do pacote • 1 Byte para Controle de Acesso • 1 Byte controle de frame • Determina se o frame tem informações de controle ou dados • 6 Bytes para endereçamento de destino • 6 Bytes para endereçamento de fonte • 4 Bytes para CheckSum • 1 Byte para determinar o fim do pacote

  46. IEEE 802.5 • Frame • 1 Byte para determinar começo do pacote • 1 Byte para Controle de Acesso • 1 Byte controle de frame • Determina se o frame tem informações de controle ou dados • 6 Bytes para endereçamento de destino • 6 Bytes para endereçamento de fonte • 4 Bytes para CheckSum • 1 Byte para determinar o fim do pacote

  47. IEEE 802.5 • Funcionamento Básico: • Token circula pela rede • O nó que precisa enviar uma mensagem “segura” o token e envia um frame para o destino • O nó destino recebe o frame captura os dados e repassa o frame • Quando o nó de origem recebe o frame, caso não tenha mais pacotes a enviar, libera o token.

  48. IEEE 802.5 • Exemplo: • 4 nós: “A”, “B”, “C”, “D”. • “B” tem um 1 frame de prioridade 3 para enviar para “A” • “C” tem um 1 frame de prioridade 2 para enviar para “A” • “D” tem um 1 frame de prioridade 4 para enviar para “A” • Token começa com “A”

  49. IEEE 802.5

  50. IEEE 802.5

More Related