I have bip running on a stable server, connected to some irc servers
(including freenode).
My irc client at home is xchat.
My xchat and bip are connected through an ssh tunnel (as i don't want to
open another port for bip ssl). So xchat connects itself on localhost:x
and bip sees it as localhost:y (ssh doing the mapping between home:x and
server:y).
It looks like this:
xchat <-------(ssh tunnel)--------> bip <-------> ircd (freenode, ...)
^ ^
| |
localhost:x localhost:y
For the last few weeks, my (ADSL) connection has been unstable, hence, i
depend on bip to keep me in sync with the channels on which i'm active,
especially when the disconnection happens in the middle of a discussion.
My disconnections last from a few seconds to 5min. When I come back, i
have a new IP address (from my ISP), hence a new tunnel, and a new
connection to bip.
But the remote users are not aware that i was offline and expect me to
answer.
With "backlog_always = false", i never see what happened while i was
offline.
If i properly quit xchat, and restart it after the same kind of delays,
i get the expected backlogs from bip.
It seems bip is not able to detect fast enough that the client is gone.
I went through the doc and the code and i was unable to find anything
that would allow me to shorten the timeout (between bip and the client)
or to trigger a faster "irc ping".
I'm not sure if my tunnel really matters here, it seems the key
difference is the *unexpected* disconnection. Even if i lower the ssh
keepalive to the lowest-but-still-sane value, it won't allow bip to
replay what happened when the disconnection happened.
Hi, Tcp will detect such connection breakage only when bip sends data to your ADSL ip and times out waiting for ACKs. So bip indeed approximates when the connection is lost. The blreset_on_talk should be useful to you as bip will replay logs as long as you did not reply anything. I don't see any trivial way to implement a better connection loss detection for backlog reset. It should be feasible to delay backlog resetting to only when we receive any data from client, which would prevent some errors of the type you described (but not all). Another way would be to poll the tcp buffer size and to reset logs only when it's down to 0. It's probably the best solution.
what about a reset on PONG? I assume there's a PING/PONG between bip and the client, so this could be used to reset or shorten the backlogs, i.e., everything logged before a PING could be trashed once the PONG is received. If the PING interval is small enough, that would lead to almost no dupes.
if i understand the code correctly, it seems bip is able to answer to PINGs from the server or from the client, send PINGs to the server but it doesn't emit its own pings toward the client. What about making bip ping the client on a quite fast pace (such as ~2sec), or with a user configurable interval & timeout? something like this: client bip server | ------ PING X -------> | | | <----- PONG X -------- | | | | | | | <------ PING Y ------- | | | ------- PONG Y ------> | | | | | | ------- PING Z ------> | | | <------ PONG Z ------- | | | | | <----- PING T -------- | | ------ PONG T -------> | (X/Y/Z/T are independent, i.e. no ping relay) X, Y and Z are already there. T would allow bip to a/ detect much faster than the client is gone and b/ truncate the backlogs after each PONG (at the time the corresponding PING was sent) to avoid too many duplicates during replays. What do you think? /Fabien
A better solution is to poll the tcp buffer size as I mentioned before. The empty buffer insures us that the client received the data. A ping from bip to client would be useful, and I don't remember if it's missing on top of my head. But every two second is overkill and still incorrect as messages can come in those two seconds. 2010/9/15 Fabien Tassin <fta@sofaraway.org>: