Some messages not buffered if client disconnects without /quit and then times out

[LunNova]

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).

[urbels]

This is why i use awaystore plugin for private messages and auto clear buffer is off.

[Weyland]

+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]

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]

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]

There is this pull request https://github.com/znc/znc/pull/598 which attempts to fix this.

[frozencemetery]

@Mkaysi That would not fix channels losing messages since it does not touch the channel logic.

[Mikaela]

Oh sorry, I thought that message = private message.

[DvdKhl]

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]

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-]

Has any headway been made in relation to this issue?

[jpnurmi]

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]

Yes, it needs special support from your client, but that's not difficult to implement.

Is this currently supported by anything else than Communi-*?

[jpnurmi]

Is this currently supported by anything else than Communi-*?

Textual & Mobile Colloquy

[caktux]

The OP's proposed solution would be a very welcomed feature.

[PotcFdk]

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]

Could this be closed based on *playbck or will this wait for it to be merged to ZNC?

[PotcFdk]

I'm not entirely sure if a solution to this issue should require non-standard client implementations and/or (third-party) plugins.

[AndrioCelos]

Isn't this what the clearbufferonmsg module is for?

[glechapelain]

It never checks whether the actual `write(...)' call succeeded :( I'll see if I can come up w/ sthing!

[glechapelain]

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 clientbuffer module. 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.

[glechapelain]

Isn't this what the clearbufferonmsg module is for?

So I guess yes, it is, after educating myself. (At first I thought write() or SSL_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 out SSL_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 clientbuffer module I will take my suggestion there.

[glechapelain]

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.

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 clearbufferonmessage in 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