Tema De Dds Para Hoje

Configurando QoS no DDS hoje: o que realmente funciona

O DDS é um padrão velho de meia, mas ainda é uma das formas mais limpas de fazer comunicação em tempo real sem depender de brokers como Kafka ou ZeroMQ. Se você tá entrando agora ou precisando ajustar algo no sistema atual, o tema de dds para hoje gira quase sempre em torno de QoS — Quality of Service. É onde a maioria das pessoas tropeça. QoS no DDS define como os dados trafegam entre publicadores e assinantes. Durabilidade, confiabilidade, prazo de vida, histérico. São configurações que parecem óbvias no papel mas que vão te dar trabalho se você não escolher com cuidado desde o início. Eu vi um sistema inteiro travar porque o participant não tinha um timeout definido no Reliability QoS e, em uma queda de rede, os participantes ficavam tentando se reconectar para sempre. O workaround foi criar um watchdog em nível de aplicação que reiniciava o participant após 30 segundos de idle. Levei dois dias para perceber o problema. Não leve dois dias. O que as pessoas costumam errar:

• Escolher RELIABILITY RELIABLE por padrão sem pensar no custo de rede. Cada mensagem precisa de ACK, retransmissão, estado de sessão. Em setups com dezenas de nós isso soma banda e CPU que você não tem.
• Ignorar o DEADLINE_QOS. Sem deadline configurado, o DDS não sabe que um autor já morreu. Você continua tentando enviar dados para um nó que sumiu há horas.
• Colocar DURABILITY TRANSIENT na mão achando que é só uma variação de persistente. Transient significa que os dados ficam disponíveis para quem chegar depois, mas só se o writer ainda estiver ativo. Se cair, somem.

Como configurar na prática

Vou mostrar com um exemplo em C++, que é o mais comum em sistemas embarcados e industriais. Se você usa Java ou Python, a lógica é a mesma, só muda a sintaxe da API. O participant é a raiz de tudo. Ele controla a política de rede, discovery e default QoS. Você pode usar o padrão ou passar uma propriedade personalizada. Eu prefiro sempre passar explicitamente, mesmo que seja para manter o padrão, porque documenta a intenção. O topic é o nome do que você quer publicar. Publisher e subscriber carregam as políticas de entrega. Novamente, eu vejo muita gente usar DEFAULT e depois se perguntar por que o sistema é lento. Configure Reliability como BEST_EFFORT para telemetria de alta frequência, RELIABLE para comandos críticos.

Aqui é onde a coisa fica séria. Cada writer e reader herdam QoS do publisher/subscriber, mas você pode sobrescrever individualmente. A interoperabilidade entre implementações DDS. Vocês podem usar CycloneDDS, OpenDDS, Connext, RTI. Cada um tem diferenças sutis em como respeita os QoS. Eu precisei migrar de OpenDDS para CycloneDDS em um projeto de satélite porque o deadlock na implementação de discover dos tipos genéricos era impossível de resolver. A migração levou uma semana. O código em si mudou em duas linhas. Outro problema: versionamento de tipos. DDS usa IDL como contrato. Se você mudar o tipo e não atualizar o-DDS-protocolo, os dados são descartados silenciosamente. Não dá erro. Só some. Solução: manter um esquema centralizado e rodar validação IDL em CI antes de cada deploy.

Alternativas quando DDS não serve

Se o seu sistema não precisa de semântica de publish-subscribe com QoS rico, DDS é overkill. Para pipelines de dados simples, ZeroMQ ou até gRPC com streaming resolvem em tempo menor. DDS brilha quando você precisa de tolerância a falhas, descoberta automática e garantias de entrega com prazos. Fora disso, você está pagando complexo por algo que não precisa. Se quiser testar localmente antes de subir em produção, o CycloneDDS vem com um demo server que roda em containers Docker. É rápido de levantar e evita o trabalho de config manual de rede.