https://bugs.kde.org/show_bug.cgi?id=476747
--- Comment #9 from Bill <[email protected]> --- (In reply to Bill from comment #7) > (In reply to Dylan Hall from comment #5) > > Also having this issue often, because it completely loses the message i've > > just typed, it has a much higher impact than it needs to. > > > > A change could simply be, don't clear the input until the app confirms with > > the phone that it has been recieved - if it's disconnected, show an error, > > and leave the message. > > > > If the issue is the connection we're using to send doesn't provide > > confirmation, a workaround might be: > > > > * attempt send > > * attempt refresh and look for the message in the chat log > > * if it exists, clear the input, otherwise leave it and show an error > > > > this would at least save completely rewriting a message from scratch, or > > seeing the input clear and assuming a message has sent when it hasn't. > > I think this is the best idea to minimize the impact of the connection > detection lag and downstream issues from it. What I like about Dylan's > approach is that (as far as I can tell at this time) it won't impact future > more robust improvements to the ping/pong features of the app, meaning we > shouldn't need to rip this fix out later since it's just saying: > Send the message, do you see it in the chat (did gotNewMessage fire)? Yes? > Cool, clear the input. > No? > Don't clear the input. > I just did a PoC on this and it works like a champ. Right now it's just 4 > small changes to one file. I'm going to do some more cleanup, and more > extensive testing. If this fix passes muster, ima push it. Update - I'm working on a fix that takes care of this bug AND Bug 517659. Here is the upshot: The existing configureSocket enables TCP keepalive (SO_KEEPALIVE) but relies on Linux defaults: 7200s idle before the first probe, 75s between probes, 9 retries. That means a dead connection is not detected for about 7875 seconds (over 2 hours). During this window, isReachable remains true and the SMS app allows sending to a disconnected phone, silently losing messages. The fix tunes the per-socket keepalive parameters: 10s idle before the first probe, 5s between probes, 3 retries. Dead connections are now detected in less than 25 seconds. The cost is 3 kernel-level TCP keepalive probes per 10-second idle period (roughly 360 bytes/minute), which is negligible. The Android app already runs as a foreground service with FOREGROUND_SERVICE_TYPE_CONNECTED_DEVICE and WiFi Power Save Mode efficiently sleeps the radio between small packets. During testing we also discovered that aggressive keepalive causes the daemon to fully disconnect and reconnect (instead of just adding a second link), which triggers a plugin reload. After reload, the SmsPlugin's conversation cache is empty, causing replyToConversation to silently fail. A companion one-line fix, calling requestAllConversations() in SmsPlugin::connected(), repopulates the cache on reconnect and also restores echo delivery (BUG 517659). I've made these changes locally. They are tiny and so far they are rock solid (more testing to come tho). I'd love some feedback on this approach. Are there reasons why we wouldn't just tweak the keepalive for this socket? -- You are receiving this mail because: You are watching all bug changes.
