Gabriel Felipe Souza SantosandCursor
22540eaffb
A sala acompanha a interface escolhida, o TCP deixa de travar a janela e a aba de um peer continua fechável quando o IP muda. O guia do colega usa os saltos do traceroute como TTL mínimo. Co-authored-by: Cursor <cursoragent@cursor.com>
3.3 KiB
Heartbeat e presença
Presença ≠ conexão TCP: ver um peer na lista lateral significa que heartbeats UDP recentes foram recebidos; ainda assim o primeiro envio TCP pode abrir um novo socket.
Heartbeat
O mecanismo de heartbeat é utilizado para identificar quais usuários estão ativos na rede.
A aplicação envia periodicamente uma HeartbeatMessage contendo informações do usuário,
um identificador único da instância da aplicação e um timestamp.
Essas mensagens são transmitidas utilizando a comunicação UDP multicast.
Quando outra instância recebe uma mensagem de heartbeat, o SocketUDP identifica
o tipo da mensagem e encaminha o objeto ao HeartbeatManager, juntamente com o endereço
IP de origem.
O HeartbeatManager registra ou atualiza o peer correspondente, utilizando o
identificador da instância para diferenciá-lo das demais.
Um peer é considerado inativo quando permanece mais de 15 segundos sem receber um novo
heartbeat. O HeartbeatManager então remove o peer da lista e notifica todos os
componentes registrados como listeners de mudanças de peers.
Esses listeners podem incluir diferentes partes da aplicação, como componentes
da interface gráfica, mecanismos de comunicação (como o SocketTCP) e também plugins
que desejem reagir à presença ou ausência de usuários na rede.
Dessa forma, o sistema permite que tanto o núcleo da aplicação quanto extensões externas sejam notificados sobre alterações no estado da rede, mantendo a arquitetura flexível e extensível.
O fluxo completo é:
HeartbeatManager
|
| cria HeartbeatMessage
|
v
Message.toByteArray()
|
v
SocketUDP.sendMulticast()
|
v
UDP Multicast
|
v
SocketUDP.receive()
|
v
HeartbeatManager.receiveHeartbeat()
|
v
Lista de peers ativos
|
+----> Interface de usuários online
|
+----> SocketTCP (PeerListener)
|
+----> Plugins (PeerListener)
Parâmetros práticos
| Item | Valor no núcleo | Efeito na sala |
|---|---|---|
| Grupo multicast | 224.0.0.3 |
Todos na mesma porta participam |
| Intervalo de envio | ~5 s | Lista atualiza em alguns segundos |
| Timeout de ausência | ~15 s | Peer some após queda ou fechamento sem goodbye |
| Goodbye | multicast ao sair | Remove peer mais rápido que só timeout |
Em Wi‑Fi de laboratório, heartbeat usa o mesmo multicast que o chat na sala geral — mesma porta, mesma sub-rede, sem isolamento AP→AP. Ver appendix_portas_e_multicast.md e 17_teste_com_colega.md.
Nome e troca de sala
O nome vai dentro do HeartbeatMessage que já existe. Se o nome mudar, o receptor atualiza o peer na lista e avisa a interface; não há outra mensagem só para isso.
Trocar a porta (ou a saída, ou o TTL) envia GoodbyeMessage na sala atual, esvazia a lista local e anuncia de imediato depois do novo socket. Quem ficou na porta antiga deixa de ver esta instância. Quem já está na porta nova aparece no anúncio seguinte. Se o goodbye se perder, o timeout de cerca de 15 s ainda remove o peer.
flowchart LR
HM[HeartbeatManager] -->|HeartbeatMessage| UDP[SocketUDP multicast]
UDP --> LAN[LAN]
LAN --> UDP2[SocketUDP outro peer]
UDP2 --> HM2[HeartbeatManager]
HM2 --> PS[PresenceService]
PS --> UI[NetworkUsersPanel]