#1167 Bug report: Two reliability issues in stable Windows release (5.8.6) — group messaging and sleep/resume reconnect

[Anonymous]

BeeBEEP version: 5.8.6 (stable Windows release), also checked against source r1586 OS: Windows 10/11 Network setup: LAN, ~30 clients (peer-to-peer)

We rely on BeeBEEP daily for office communication and have run into two recurring reliability issues in the current stable Windows release. Both would be very important for us to see fixed, so I'm reporting them together with what I could find by reading the source (r1586).

Issue 1: Client doesn't reconnect automatically after sleep/resume
Summary

When a Windows PC goes to sleep and wakes up again, BeeBEEP does not automatically reconnect to the network. The local user then sees all other users as offline, even though they are online — because the local core connection itself was never restarted.

Root cause (found in source r1586)

1. BeeApplication_win.cpp correctly detects WM_POWERBROADCAST / PBT_APMSUSPEND and calls forceSleep().
2. GuiMain::onSleepRequest() (GuiMain.cpp) correctly calls stopCore() when going to sleep — this disconnects from the network, which is correct behavior.
3. On resume, wakeFromSleep() restarts the tick timer (startTicks()), and GuiMain::onWakeUpRequest() is called — but it only calls initGuiItems(). It never calls startCore(), so the network core is never restarted automatically. The user stays disconnected until they manually reconnect (tray menu → Connect, or changing status), which most users don't know to do — so they assume everyone else is offline.

Issue 2: Some users don't receive "All users" / group chat messages (~30 users)
Summary

In our ~30-user LAN, messages sent to the "All users" chat or to group chats sometimes don't reach every member, with no visible error to the sender.

Suspected cause (from reading source r1586, not fully confirmed)

Looking at Core::sendMessageToChat() / Connection::sendMessage() / ConnectionSocket::sendData() (CoreChat.cpp, Connection.cpp, ConnectionSocket.cpp): delivery relies on a live Connection object per peer, and a successful low-level socket write() is treated as delivery success. There doesn't appear to be an application-level acknowledgment/retry for chat messages if a peer's TCP connection silently breaks while the User list still shows them as online. At ~30 concurrent peers (full mesh, each client holding ~29 direct connections), this seems like a plausible explanation for occasional silent gaps, but I want to flag that I haven't pinned this down to a single exact line the way I could for Issue 1 — it may also involve MessageManager / the RECEIVED_MESSAGE_PROTO_VERSION handling, which I haven't fully traced yet.

What would help

If this matches a known weak point in the delivery/ack logic, a fix based on the source would be extremely valuable to us. If useful, I'm happy to keep digging into MessageManager and report back with more specifics.

Both issues occur in the current stable Windows release (5.8.6) and significantly affect daily use in a ~30-user office deployment. Thank you for maintaining BeeBEEP — it's a great tool for offices without needing a server!