Repository navigation
Some messages not buffered if client disconnects without /quit and then times out #322
Description
If I disconnect from znc due to an issue with my internet connection, some buffer may be lost, leading to confused conversations as someone assumes you saw their reply.
It would be nice to have an option to make znc keep a buffer of what was said between now and the last successful ping, and add that to the buffer if the client disconnects due to missing a ping, or E_CONN_RESET/other similar error.
--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/244531-some-messages-not-buffered-if-client-disconnects-without-quit-and-then-times-out?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F1759&utm_medium=issues&utm_source=github).
Activity
urbels commentedon Apr 17, 2013
This is why i use awaystore plugin for private messages and auto clear buffer is off.
Weyland commentedon Apr 17, 2013
+1 for this idea. Ping timeouts are still a problem on most servers. Having a feature that saves buffer messages if a ping was not successful, is very welcome.
frozencemetery commentedon Apr 2, 2014
I observe this problem in my own setup, and am concerned that it happens. It suggests that there is a code path through which a message can show up and, failing delivery to the user, be dropped on the floor. TCP socket calls will provide sufficient information to detect delivery error, so it concerns me that this is a problem at all.
DvdKhl commentedon Jul 31, 2014
Since I'm using standby to "power off" the PC, I also have the issue of mIRC not telling ZNC it is quitting. What concerns me the most is that I actually missed a query and only learned of it much later. After looking into it a bit, it seems like I was missing chat history of at least 5min after putting the PC into standby.
Mikaela commentedon Aug 1, 2014
There is this pull request #598 which attempts to fix this.
frozencemetery commentedon Aug 1, 2014
@Mkaysi That would not fix channels losing messages since it does not touch the channel logic.
Mikaela commentedon Aug 1, 2014
Oh sorry, I thought that message = private message.
DvdKhl commentedon Aug 1, 2014
Mhh, not sure if this would fix the query side.
ZNC seems to behave like the client is still connected after a silent connection loss (which is of course normal),
but then not noticing it was unable to deliver the messages to the client and therefore being lost.
I'll do some testing later and see if I can consistently reproduce it.
Abazigal commentedon Oct 2, 2014
I regularly observe this problem on an IRC/ZNC server that is oftenly accessed via VPN from countries where internet is not so reliable.
When someone's connection is lost for some reason, messages sent in the following ~20s doesn't appear in his backlog when he reconnects.
winny- commentedon Jan 31, 2015
Has any headway been made in relation to this issue?
jpnurmi commentedon Jan 31, 2015
This is the solution that I've been happily using for a year: http://wiki.znc.in/Playback. Yes, it needs special support from your client, but that's not difficult to implement.
Mikaela commentedon Jan 31, 2015
Is this currently supported by anything else than Communi-*?
jpnurmi commentedon Jan 31, 2015
Textual & Mobile Colloquy
caktux commentedon Apr 24, 2015
The OP's proposed solution would be a very welcomed feature.
PotcFdk commentedon May 21, 2015
Assuming I'm not missing any important technical detail that would lead to issues, I agree with @caktux, as this solution would (hopefully) work with all standard clients and not require special plugins.
Mikaela commentedon Sep 9, 2015
Could this be closed based on *playbck or will this wait for it to be merged to ZNC?
PotcFdk commentedon Sep 9, 2015
I'm not entirely sure if a solution to this issue should require non-standard client implementations and/or (third-party) plugins.
AndrioCelos commentedon Jun 30, 2017
Isn't this what the
clearbufferonmsgmodule is for?glechapelain commentedon Jan 9, 2023
It never checks whether the actual `write(...)' call succeeded :(
I'll see if I can come up w/ sthing!
So This would be my fix for znc#322
glechapelain commentedon Sep 23, 2023
o/ o/
So, I think the issue is fixed by the commit I made in my fork (Idk if it shows here for others.)
However, only when using the
clientbuffermodule. I could carry on looking for fixing w/o, but that wouldn't be solving a problem I have.I'll send a PR for now with that, at least it is something.
Fix for znc#322:
glechapelain commentedon Oct 1, 2023
So I guess yes, it is, after educating myself.
(At first I thought
write()orSSL_write()returning <= 0 meant that the message did not make it, and therefore the other way around meant that it did however as it turns outSSL_write()may still return a # of byte transmitted even though the connection is down, and for good.)I think we could improve ZNC to only clear the buffer upon receiving a pong, and we could emit a ping along with each messages. But, yeah, this is virtually the same as using
clearbufferonmsg(ty @AndrioCelos )Since I am using the
clientbuffermodule I will take my suggestion there.glechapelain commentedon Oct 1, 2023
I was exactly same but as it turns out TCP being reliable merely means that when the connection cuts, you will now eventually about it, however not exactly at the moment it happens.
So the proper fix sounds like being folding the module
clearbufferonmessagein ZNC.Considering the wiki for it says that it addresses this very issue, a point can be made this is simply how the software is designed.
As per my previous comment an issue remains with znc-clientbuffer. I'll open it up there