Debian Bug report logs - #595408
backlog replay broken for unexpected disconnections

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Fabien Tassin <fta@sofaraway.org>

To: submit@bugs.debian.org

Subject: backlog replay broken for unexpected disconnections

Date: Fri, 03 Sep 2010 20:05:41 +0200

Package: bip
Version: 0.8.2-1

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.

Message #10 received at 595408@bugs.debian.org (full text, mbox, reply):

From: Arnaud Cornet <arnaud.cornet@gmail.com>

To: Fabien Tassin <fta@sofaraway.org>, 595408@bugs.debian.org

Subject: Re: Bug#595408: backlog replay broken for unexpected disconnections

Date: Sun, 5 Sep 2010 18:03:04 +0100

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.
-- 
Arnaud Cornet

Message #15 received at 595408@bugs.debian.org (full text, mbox, reply):

From: Fabien Tassin <fta@sofaraway.org>

To: Arnaud Cornet <arnaud.cornet@gmail.com>

Cc: 595408@bugs.debian.org

Subject: Re: Bug#595408: backlog replay broken for unexpected disconnections

Date: Sun, 05 Sep 2010 20:49:05 +0200

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.

Message #20 received at 595408@bugs.debian.org (full text, mbox, reply):

From: Fabien Tassin <fta@sofaraway.org>

To: Arnaud Cornet <arnaud.cornet@gmail.com>

Cc: 595408@bugs.debian.org

Subject: Re: Bug#595408: backlog replay broken for unexpected disconnections

Date: Wed, 15 Sep 2010 20:20:17 +0200

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

Message #25 received at 595408@bugs.debian.org (full text, mbox, reply):

From: Arnaud Cornet <arnaud.cornet@gmail.com>

To: Fabien Tassin <fta@sofaraway.org>

Cc: 595408@bugs.debian.org

Subject: Re: Bug#595408: backlog replay broken for unexpected disconnections

Date: Thu, 16 Sep 2010 12:34:48 +0100

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



-- 
Arnaud Cornet

Send a report that this bug log contains spam.