Opened 8 years ago

Closed 6 years ago

#644 closed defect (fixed)

Frequent IRC disconnects

Reported by: zzz Owned by: zzz
Priority: major Milestone: 0.9.7
Component: streaming Version: 0.9
Keywords: Cc: echelon@…
Parent Tickets: Sensitive: no

Description

Over the last year, disconnects and netsplits have become much more frequent on IRC. Maybe this is just due to client timeout settings (wasn't there an xchat setting in the UI before? can't find it now). Or maybe there's something to fix in the tunnel configuration for streaming parameters.

The whole interactive/bulk settings thing needs to be looked at. Is 'interactive' (which limits window size to 16) even doing anything?
Also, I think the client and server proxies flush after each line? Is that true, and is it still a good idea…

The disabling of tunnel testing may be the biggest cause of disconnects. Perhaps enabling it for IRC tunnels would help?

For research and improvement.

Subtickets

Change History (6)

comment:1 Changed 8 years ago by zzz

Cc: echelon@… added

Existing advanced config router.disableTunnelTesting=false will enable testing for all tunnels. There is no way currently to enable it on a per-destination basis.

comment:2 Changed 8 years ago by zzz

I tried enabling tunnel testing and it didn't appear to make much difference.

XChat pings every 30 seconds and it waited for 20 pings before giving up (this was with SOCKS proxy, note ping of the proxy in the middle):

<< PING LAG707073199
>> :irc.killyourtv.i2p PONG irc.killyourtv.i2p :LAG707073199
<< WHO #i2p
<< PING LAG737118064
<< PING LAG767158183
<< PING LAG797205887
<< PING LAG827243792
<< PING LAG857286831
<< PING LAG887328917
<< PING LAG917368142
<< PING LAG947414792
<< PING LAG977452425
<< PING LAG1007489785
>> PING 127.0.0.1
<< PONG 127.0.0.1
<< PING LAG1037568866
<< PING LAG1067613037
<< PING LAG1097648593
<< PING LAG1127692018
<< PING LAG1157743855
<< PING LAG1187788186
<< PING LAG1218164149
<< PING LAG1248207870
<< PING LAG1278251128
<< PING LAG1308334366
>> ERROR :Closing Link: zzz[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.b32.i2p] (Ping timeout)

comment:3 Changed 7 years ago by zzz

I know echelon wants to focus on the inter-server links (eche-postman-badger). The best way to do that is:

  • get all the servers on the latest router version.
  • Then, understand the tunnel settings (length and quantity, interactive/bulk) on both sides of those links.
  • Adjust those settings as necessary.
  • Understand and adjust the application-level (IRC server) timeouts for the links
  • Then, look for other issues with those routers (conn limits, overload, etc.).
  • Adjust router settings as necessary

There's a whole lot of streaming and ElGamal?/AES+tags changes in 0.9.1 and 0.9.2 that, in theory, should help low-bandwidth links like IRC. But unless all 3 servers are running the latest, it's very difficult to know if those changes were effective, or what to do next.

comment:4 Changed 7 years ago by str4d

Milestone: 0.9.3

comment:5 Changed 6 years ago by zzz

Milestone: 0.9.7
Owner: set to zzz
Priority: minormajor
Status: newaccepted

Broken in 0.9, close-on-idle clients stop their retransmission timers when the session is disconnected, and they are not restarted on reconnect.

comment:6 Changed 6 years ago by zzz

Resolution: fixed
Status: acceptedclosed

Fixed in 0.9.6-17 8d382751cb0510d306043283b99ef0d8cc595c2b
Don't stop the timers.

This affects any close-on-idle tunnel. IRC is the only one configured that way by default, but for people that set it for shared clients or other tunnels, it could affect HTTP, POP, SMTP, CONNECT, mtn, etc.

Note: See TracTickets for help on using tickets.