Protocolos de comunicação em tempo real

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