Open DarthGandalf opened 9 years ago
Comment by Meliorator on 15 Sep 2012 11:24:12 Forgot to say, just closing the channel window is undesired, since channel buffer is not be preserved. Also, if the shell host has had the misfortune of a ddos attack, it can lead to the window opening/closing lots of times. Just FYI it's impossible for a shell host to have complete ddos protection, just look at Staminus.
Comment by Meliorator on 16 Sep 2012 13:37:23 Just thought I would mention the correct IRC implementation as described in RFC2812:
Servers and clients send each other messages, which may or may not generate a reply. If the message contains a valid command, as described in later sections, the client should expect a reply as specified but it is not advised to wait forever for the reply; client to server and server to server communication is essentially asynchronous by nature.
The relevant part being "the client should expect a reply as specified". EG: client sends a "JOIN #channel" it should wait for a reply (with a timeout) and handle the response (clear channel status).
Comment by Meliorator on 22 Sep 2012 11:54:25 I have also noticed this issue more wide spread than the above mentioned issues, such as is the case when a 435 occurs after connection to an irc server is lost and there is a nickname collision.
@staticfox thoughts? can this be closed or?
@staticfox thoughts? This is more your turf.
Reported by Meliorator on 15 Sep 2012 11:16:59 UTC When connecting KVirc through one or more bouncers and the last bouncer in the chain is disconnected from IRC, values returned by things like $channel $chan.ison are still > 0. If KVirc handles return codes correctly, such as 404, 473 and many others, it would reset the channel status variables, when those return codes are received. Currently it is impossible to tell if KVIrc is actually on a specific channel, when connected through bouncer(s).
Migrated from: https://svn.kvirc.de/kvirc/ticket/1324