I think it would be interesting if the module clearbufferonmsg would also clear the buffer when it receive a PING or a PONG command from the client since it's a proof the client is alive and received all the previous messages.
Then the name of the module would be a bit misleading since they're not really messages. But maybe the module could be renamed and could be added two meta-options "message" and "activity" to set whether the user want the buffers cleared on a message or on any activity from the client.
I think it would be interesting if the module clearbufferonmsg would also clear the buffer when it receive a PING or a PONG command from the client since it's a proof the client is alive and received all the previous messages.
Then the name of the module would be a bit misleading since they're not really messages. But maybe the module could be renamed and could be added two meta-options "message" and "activity" to set whether the user want the buffers cleared on a message or on any activity from the client.
## <bountysource-plugin>
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/20767323-clearbufferonmsg-clear-on-ping-or-pong?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).
</bountysource-plugin>
<!-- github-sync-id:85818379 -->
I disagree as ping/pong is not activity by the user, but the client and what if there is bad connection between the client and ZNC and ZNC is receiving PINGs or PONGs from the client with long latency?
I disagree as ping/pong is not activity by the user, but the client and what if there is bad connection between the client and ZNC and ZNC is receiving PINGs or PONGs from the client with long latency?
<!-- github-comment-id:109715386 -->
It is not activity by the user, it is activity by the client, which is what I am interested in. If the messages reach the client, they will be logged, so there is no need to keep them in ZNC.
Not sure if I understood your point. It is true that on high latency network, ZNC may receive a PING from the client and clear the buffers while some messages were still in-flight from ZNC to the client they might never get to destination. But this can also occur with all the commands currently implemented in this module.
If a client send a PRIVMSG and the network goes down immediately after, ZNC will clear the buffer and forget about the messages that were sent before it receives the PRIVMSG, including those that should have arrived after the network outage.
However, if ZNC receives a PONG from the client, it can be sure that all the messages sent before the corresponding PING have actually been received by the client. But does ZNC ever PING the client?
Maybe this should be another module despite the goal is very close?
It is not activity by the user, it is activity by the client, which is what I am interested in. If the messages reach the client, they will be logged, so there is no need to keep them in ZNC.
Not sure if I understood your point. It is true that on high latency network, ZNC may receive a PING from the client and clear the buffers while some messages were still in-flight from ZNC to the client they might never get to destination. But this can also occur with all the commands currently implemented in this module.
If a client send a PRIVMSG and the network goes down immediately after, ZNC will clear the buffer and forget about the messages that were sent before it receives the PRIVMSG, including those that should have arrived after the network outage.
However, if ZNC receives a PONG from the client, it can be sure that all the messages sent before the corresponding PING have actually been received by the client. But does ZNC ever PING the client?
Maybe this should be another module despite the goal is very close?
<!-- github-comment-id:109763519 -->
Yes, ZNC pings client. It sends PING when there was no data from the connection for a while. If client sends something (e.g. PONG), the timer is reset. There's no matching done between "corresponding" PINGs and PONGs.
Clearbufferonmsg doesn't clear buffer on PONG by design. Here's why:
ZNC sends PING
Client receives PING
Client sends PONG
ZNC sends some private message
ZNC receives PONG and clears buffers
Client times out without receiving any message
Yes, ZNC pings client. It sends PING when there was no data from the connection for a while. If client sends something (e.g. PONG), the timer is reset. There's no matching done between "corresponding" PINGs and PONGs.
Clearbufferonmsg doesn't clear buffer on PONG by design. Here's why:
1. ZNC sends PING
2. Client receives PING
3. Client sends PONG
4. ZNC sends some private message
5. ZNC receives PONG and clears buffers
6. Client times out without receiving any message
<!-- github-comment-id:109881358 -->
Is there even a way to match corresponding PINGs and PONGs? To me it looks like WeeChat pings with the configured server address as argument, so everything is PING ::1.
Is there even a way to match corresponding PINGs and PONGs? To me it looks like WeeChat pings with the configured server address as argument, so everything is `PING ::1`.
<!-- github-comment-id:109881487 -->
@DarthGandalf the very same scenario can happen with all the commands clearbufferonmsg reacts on.
Client sends a PRIVMSG to ZNC
ZNC sends a PRIVMSG to the client
ZNC receives the PRIVMSG and clears the buffers
Client disconnects unexpectedly without receiver the last PRIVMSG sent in 2.
I think the only way to avoid this would be to effectively match a PONG with a PING and selectively (partially) clear the buffers.
Note that the RFCs say that arguments of PING and PONG should be server names. But it doesn't say those should be FQDN, and in practice, the common implementation of PONG in clients is to just copy the argument of the received PING. (This is actually required by many servers for the first ping on connection.)
@DarthGandalf the very same scenario can happen with all the commands `clearbufferonmsg` reacts on.
1. Client sends a PRIVMSG to ZNC
2. ZNC sends a PRIVMSG to the client
3. ZNC receives the PRIVMSG and clears the buffers
4. Client disconnects unexpectedly without receiver the last PRIVMSG sent in 2.
I think the only way to avoid this would be to effectively match a PONG with a PING and selectively (partially) clear the buffers.
Note that the RFCs say that arguments of PING and PONG should be server names. But it doesn't say those should be FQDN, and in practice, the common implementation of PONG in clients is to just copy the argument of the received PING. (This is actually required by many servers for the first ping on connection.)
<!-- github-comment-id:110051786 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I think it would be interesting if the module clearbufferonmsg would also clear the buffer when it receive a PING or a PONG command from the client since it's a proof the client is alive and received all the previous messages.
Then the name of the module would be a bit misleading since they're not really messages. But maybe the module could be renamed and could be added two meta-options "message" and "activity" to set whether the user want the buffers cleared on a message or on any activity from the client.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
I disagree as ping/pong is not activity by the user, but the client and what if there is bad connection between the client and ZNC and ZNC is receiving PINGs or PONGs from the client with long latency?
It is not activity by the user, it is activity by the client, which is what I am interested in. If the messages reach the client, they will be logged, so there is no need to keep them in ZNC.
Not sure if I understood your point. It is true that on high latency network, ZNC may receive a PING from the client and clear the buffers while some messages were still in-flight from ZNC to the client they might never get to destination. But this can also occur with all the commands currently implemented in this module.
If a client send a PRIVMSG and the network goes down immediately after, ZNC will clear the buffer and forget about the messages that were sent before it receives the PRIVMSG, including those that should have arrived after the network outage.
However, if ZNC receives a PONG from the client, it can be sure that all the messages sent before the corresponding PING have actually been received by the client. But does ZNC ever PING the client?
Maybe this should be another module despite the goal is very close?
Yes, ZNC pings client. It sends PING when there was no data from the connection for a while. If client sends something (e.g. PONG), the timer is reset. There's no matching done between "corresponding" PINGs and PONGs.
Clearbufferonmsg doesn't clear buffer on PONG by design. Here's why:
Is there even a way to match corresponding PINGs and PONGs? To me it looks like WeeChat pings with the configured server address as argument, so everything is
PING ::1.@Mikaela But what does it send as PONG?
Usually, the argument of PONG matches the argument of PING.
@DarthGandalf the very same scenario can happen with all the commands
clearbufferonmsgreacts on.I think the only way to avoid this would be to effectively match a PONG with a PING and selectively (partially) clear the buffers.
Note that the RFCs say that arguments of PING and PONG should be server names. But it doesn't say those should be FQDN, and in practice, the common implementation of PONG in clients is to just copy the argument of the received PING. (This is actually required by many servers for the first ping on connection.)
Another option is to use something like ircv3/ircv3-specifications#16