O que é tempo-real? O que o pessoal anda chamando de tempo-real é realmente tempo-real? Node.js ou websocket realmente me propiciam uma web “real time”? Vou tentar responder a todas estas perguntas neste post com a visão de alguém que trabalha em um sistema de tempo-real de verdade (eu).
Como a computação define tempo-real
Quando falamos em tempo-real no contexto da computação nos referimos a toda uma gama de aplicações que possuí como requisito fundamental restrições temporais. O que é uma restrição temporal? Ela diz que seu software executa corretamente se e somente se duas condições forem satisfeitas:
- O software é lógicamente correto.
- A execução do sistema se dá no momento esperado.
Se já é difícil escrever software com uma lógica válida, ainda mais é garantir que execute no momento esperado. Talvez seus sistemas atuais já possuam características de tempo-real e você nem tenha se dado conta. O exemplo mais claro é a execução de tarefas agendadas que precisam executar no momento em que você as programou.
Dependendo do autor você encontrará duas categorias de sistemas de tempo real. Hard, quando o atraso na execução compromete completamente o seu resultado e Soft (mais comum pra todos nós) quando o atraso é mais aceitável e no máximo ocorrerá uma degradação na execução do sistema.
O agendamento de tarefas com o qual a maior parte dos usuários está acostumado (usando ferramentas como, por exemplo, CRON, Quartz ou Timer do Java) é do tipo Soft. Se você agenda sua execução para as 13:00:00, pode ser que só sejam iniciadas alguns segundos depois sem normalmente ferrar a sua vida.
Há sistemas nos quais você requer uma precisão maior como por exemplo no processamento de sinais. Há diversos protocolos que enviam dados em uma cadência bem estrita, como por exemplo de 50 em 50 milisegundos. Nestes casos qualquer atraso é fatal, pois você irá perder a transmissão de dados caso seu código não esteja estritamente sincronizado com o relógio do sistema.
A dificuldade na implementação de sistemas de tempo-real
Não é a toa que Hard Real Time se chama Hard Real Time. Se um processo do sistema operacional começa a consumir seus recursos computacionais no momento errado, por exemplo, é grande a probabilidade de que você perca seu deadline. Aliás, deadline é O termo. Tudo em tempo-real gira em torno disto: o momento no qual a coisa deve ocorrer.
Tempo-real em Java é difícilimo graças ao garbage collector. Muitas vezes sua execução atrasa a execução do sistema. Na pratica é quase impossível escrever um sistema hard real time em Java em grande parte por esta razão. Por isto há tanta preocupação com a criação de objetos: quanto menor o número de objetos, menor a probabilidade do GC executar e, consequentemente, menos interrupção temporal. Outro grande desafio é a compilação just-in-time: a JVM recompila seu código diversas vezes enquanto este encontra-se em execução. Tunar a sua JVM para evitar sua ocorrência em um momento inoportuno é outro grande desafio. E adivinha qual é a JSR de número 1? Real-time.
(este artigo de 2007 da IBM sobre os desafios de se escrever sistemas real-time em Java é uma boa leitura (claro, depois eles vão te tentar vender a JVM RT deles))
É devido a este tipo de problema que normalmente soluções de tempo-real envolvem além do software, hardware. Há inclusive sistemas operacionais específicos para este tipo de problema, como por exemplo o QNX da BlackBerry, usado a décadas neste nicho. O que estes sistemas operacionais nos dão de tão especial? Basicamente nos permitem controlar melhor a prioridade dos processos.
“Meu sistema é real-time: vejam como é rápido!” – OUCH!
Esta é a maior bobagem que você pode falar sobre tempo-real com base no que disse acima. Lembra que eu havia dito que tempo real envolve deadline? Então: se o seu sistema demora 23 horas para computar o resultado, mas o entrega no tempo exato, temos um sistema real-time do tipo hard. Lembre-se: deadline, não performance é quem manda aqui.
“Ocorreu lá no servidor, imediatamente foi pro cliente. Real-time!” OUCH!
Pode até ser tempo-real, mas não necessáriamente. Se algo é enviado imediatamente após ter sido executado no servidor, que garantia você tem de que foi executado no deadline esperado? Aliás, qual deadline? Nenhum: pode ter demorado, por exemplo. Aliás, isto tem outro nome: chama-se sistema on-line.
Um sistema on-line (ou online, sei lá) é aquele no qual o resultado do processamento está diretamente relacionado à interação do usuário. Você clica no botão submeter do seu browser e imediatamente tem uma resposta com base no seu input. Isto é online. Online pode ser tempo-real, mas não necessáriamente.
Aliás, este é o uso que eu vejo do termo real-time quando aplicado ao Node.js, como por exemplo aqui. Sacou a diferença? Você pode até conseguir um sistema de tempo real com Node.js, mas da forma normal, no máximo irá conseguir algo do tipo Soft. Que controle você tem sobre os outros processos do sistema operacional? Pergunte-se: que “tempo-real” é este que o pessoal usa pra vender o Node.js? Como alguém pode vender material por aí sobre “real-time web” se não fala sobre restrições temporais? Que restrições temporais são estas? Apenas pessoas incrívelmente brilhantes podem vê-las?
Dica: de nada adianta você ter um protocolo de comunicação de baixíssima latência se não conseguir cumprir seu deadline.
Web RTC: cadê o tempo-real?
Quer ver um exemplo muito interessante? Web RTC. É uma especificação da W3C que propicia comunicação em “tempo real” entre browsers. Me faz um favor? Primeiro da uma lida na especificação oficial. Leu? Sentiu falta de algo no texto? Te conto então: não há qualquer sitação aos termos “deadline”, “time restriction” ou similar. Nominho ruin hein? Tenho um nome pra isto: marketing. Por que não se chama “Web OTC”?
Reparem: há alguma restrição de tempo aqui? Sim. Qual é? Se você está se comunicando com outra pessoa e demora muito pra chegar a resposta. Mas aonde ela está definida? O que a diferencia de um sistema meramente interativo? “Ao vivo” pode ser considerado “tempo-real”? Há um questionamento interessante aqui que deixo para vocês.
(eu sei que este ponto vai dar pano pra manga, então podem me atacar ok? :) )
Então como eu evito falar bobagem por aí?
Muito simples: seu sistema tem algum requisito de tempo-real? Há algum do tipo “deve executar em no máximo n milisegundos” ou “deve ser executado na hora x” ou “vai ter de se repetir precisamente de n em n segundos” ou qualquer coisa do gênero? Tem? Ok: você tem um sistema de tempo real. De qual tipo? Hard? Soft? Se for soft, não há vantagem alguma, então por que bradar por aí?
Agora, sair dizendo que desenvolve sistemas de “tempo real” com Node.js sem estes requisitos te caracteriza como ignorante ok? :)
Recursos sobre tempo real
Quer saber mais sobre o assunto? Aqui está uma lista de recursos interessantes pra você.
- “The Concise Handbook of Real-Time Systems”: uma introdução maravilhosa ao assunto. Clique aqui.
- Conceitos relacionados a sistemas operacionais de tempo real (RTOS) você encontra aqui.
- Alguns padrões de projeto podem ser encontrados aqui.
Concluindo
O objetivo deste post foi desmistificar o uso que vejo sendo feito em todo lugar do termo tempo-real. Realmente não consigo entender qual é o tempo-real a que se referem pois não vejo as restrições temporais que tanto falei aqui e encontram-se confirmadas nos recursos que listei.
(se você é leitor antigo deste blog sabe que é uma luta antiga minha esta minha busca pelo melhor termo sempre)
Termino o post com perguntas ao leitor: e aí, é tempo-real mesmo? Que tempo-real é este? Como posso dizer que algo é de tempo-real se não há restrições temporais explícitas?
A raiz do problema está, como quase sempre, no marketing!
Marketing, há mais de 100 anos tornando o mundo pior.
Oi Éderson, realmente marketing ou será o resultado de uma má formação?
Os 2 juntos.
Se vc entende “publicidade”, “propaganda” no sentido de “tornar PÚBLICO”, “propagar”, eu a consideraria uma coisa legítima.
Mas hj o marketing vai além disso, já atravessou a linha da ética há muito tempo com essa coisa de “criar” imagem para as coisas, nem que para isso tenha-se que distorcer o significado dos termos, escolhidos com o objetivo de causar determinado impacto (falando + claro: 171 puro).
Completando… eu não discordo de vc. Onde há falta de informação, o marketing ocupa o espaço.
É um ponto interessante este. Concordo com isto.
Como não é raro o marketeiro ser ignorante no assunto, acaba acidentalmente criando significados diferentes pra mesma coisa.
Sem querer causar discórdia, pois é uma dúvida legítima que apresento. Não seria o caso de você estar sendo influenciado pela realidade a qual tem sido exposto no seu projeto atual, e com base nisso julgando equivocadamente a interpretação dos demais? Não conheço, ainda, as referências que você citou, mas pelo que entendi, você se refere a tempo real como sendo algo ‘just-on-time’, no momento certo, e se questiona se quem fala por ai em tempo real não estaria errado, pois classificam tempo real como ‘just-in-time’, a tempo. Não poderia ser o caso simplesmente de estarem eles usando uma definição diferente da sua para tempo real? Nesse caso, como saber qual definição está correta? Até porque, normalmente a definição usada pela maioria costuma ser considerada a definição de referência.
Oi Rafael, discordia alguma.
È uma duvida bastante legitima a sua inclusive. No caso a influencia seria qualquer bom livro de ciência da computação que lida com o assunto. Em todos eles a definição é exatamente a que passei. Obviamente o projeto no qual estou também influencia: ter contato com profissionais que de fato sabem do que falam baseado em suas experiências e não o mero hype é uma experiência muito rica.
O grande problema a meu ver é a falsa impressão positiva que o termo “tempo real” causa.
Poxa, relendo esta pergunta ela é na realidade mais profunda que aparenta.
Qual maioria? Se for da ciência da computação, a definição que apresentei seria a da maioria. Se for do marketing, vai ser quem tá tentando vender curso de tempo-real ou coisa similar.
Agora, o mais interessante é o seguinte: em nenhum dos cursos que vejo vendendo por aí (incluindo livros) vejo o assunto “tempo-real” sendo tratado diretamente, o que é um indício interessante de que o termo está sendo usado de forma frouxa e em grande parte equivocada.
Em contrapartida, quando você compara com a definição de tempo-real que apresento, se você vai, por exemplo, no site de um revendedor de RTOS, o tempo é tratado de forma direta, precisa.
Tá aí um bom indício pra lidar com a questão da “maioria”.
Excelente post kico.
Real time é exatamente isso que você falou e vejo bastante equívoco por ai também. Especialmente para quem desenvolve aplicações em microcontroladores, com controle de sinais e restrições críticas de tempo de resposta, é um absurdo ver o que alguns frameworks web com 500 camadas alega ser tempo real, sendo que mal-e-mal soft real time o são.
Parabéns.
Oi Rene, valeu!
Alguém tem de alertar o pessoal né? :-)
Sempre houve esse tipo de problema na nossa área. Não há uma padronização de nomes e não sei se um dia haverá. O caminho natural para resolver esse tipo de impasse é a repetição. Quanto mais e mais as pessoas comentarem, mais irá virar verdade ;-)
Ótimo post!
Oi Bruno, que bom que gostou, valeu!