Pareamento novoLogo após entrar, o Web recebe pendências, mensagens cifradas e confirmações antes do primeiro envio manual.
Reconexão por 5 minCom a sessão já pronta, ainda chegaram notificações offline, perfil, foto, identidade, lista e várias confirmações curtas.
Observação passivaSem enviar mensagem, a sessão registrou 3 minutos de eventos de fundo e pares curtos de iq em frames binários.
Ping?Não vimos ping WebSocket nativo. A melhor leitura atual trata sent iq vazio com xmlns=w:p como ping de aplicação.
1 · Histórico pendente e eventos offline
O servidor sinaliza que há coisas acumuladas para entregar. Na captura fresh, isso aparece como
recv ib / offline na stanza 54 e, logo depois, várias recv message cifradas com
meta, verified_name e enc. Na captura resume, aparecem
notificações com attr offline e uma mensagem pendente com enc.
- Observado: tags, attrs e filhos indicam lote pendente, mensagens cifradas e notificações marcadas como
offline.
- Inferido: chamamos isso de histórico pendente porque o conteúdo é cifrado e a captura publica só a estrutura.
Leia junto com mensagens e dispositivos e histórico pendente.
2 · Sync de conta e app-state
Nem todo evento de fundo é mensagem. Boa parte é manutenção do estado local: sync,
usync, business_profile, picture, identity, list,
devices e unified_session. Em linguagem simples: o Web está montando a mesma visão
de conta que o app do celular já tem.
- Observado: consultas e respostas de perfil, foto, identidade, dispositivos e listas continuam após o
ready, momento em que o cliente oficial declara que a sessão está pronta.
- Inferido: agrupamos esses eventos como app-state, porque são sincronizações do estado do aplicativo, não uma conversa de usuário.
Leia junto com success, perfil e chaves e sync pós-recebimento.
3 · Acks e receipts de fundo
Quando o servidor entrega lote offline ou notificação, o cliente responde com confirmações curtas.
Na janela de reconexão de 5 minutos, foram vistos 25 sent ack no bloco inicial:
24 em sequência e mais 1 logo depois de uma troca curta de iq/add. Isso não é envio
de texto; é o cliente dizendo que processou stanzas.
- Observado:
ack e receipt aparecem mesmo sem ação manual de envio.
- Inferido: eles se correlacionam com as stanzas recebidas, por isso entram como confirmação de processamento.
Leia junto com ack + receipt do envio e ack.
4 · Batimento tratado como ping de aplicação
A captura de observação passiva mostrou pares pequenos e repetidos: sent iq curto e
recv iq curto, carregados em frames binários de opcode 2. A captura resume
com atributos seguros publicados pela captura confirmou que o envio usa xmlns=w:p. O opcode
2 quer dizer frame binário; os opcodes 9 e 10 seriam ping/pong nativos
do WebSocket. Os pares começam cerca de 39 segundos depois da janela passiva e repetem em intervalos
aproximados de 15 a 32 segundos.
Em linguagem comum, xmlns é uma etiqueta de destino dentro da stanza: ela indica para qual
subsistema do WhatsApp aquele iq vai. A etiqueta w:p é a evidência usada aqui para
categorizar esse batimento como ping de aplicação, mesmo sem um filho chamado ping.
- Observado:
sent iq vazio com xmlns=w:p, seguido por recv iq vazio.
- Não observado pelo recorder: opcode WebSocket
9/10 ou stanza chamada keepalive.
- Conclusão: tratamos como ping de aplicação, transportado dentro do canal cifrado, não como ping nativo do WebSocket.
A cadência vem das janelas observadas de 3 e 5 minutos. Janelas mais longas, rede ruim ou inatividade prolongada podem mudar o intervalo.
Para o cliente C#, isso significa reproduzir o iq curto com xmlns=w:p e não depender de ping/pong WebSocket tradicional.