Open Bug 461404 Opened 11 years ago Updated 5 years ago

Merge netsplit quit messages

Categories

(Other Applications :: ChatZilla, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: mardeg, Assigned: rginda)

References

Details

(Whiteboard: [Parity: irssi])

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3
Build Identifier: 

Forwarded from irc:
<Halabund> It would be nice if Chatzilla handled netsplits as gracefully as irssi
Here's an example of a message that irssi outputs on a netsplit:
" Netsplit kornbluth.freenode.net <-> irc.freenode.net quits: Toerkeium, Guest177, Fivesheep, Dr_future, webPragmatist"
Chatzilla would just fill the window with the list of people who left, each on a separate line.

Reproducible: Always

Steps to Reproduce:
1. Connect to a multiserver irc network
2. Wait for a netsplit (or induce one through DrDOS .. j/k!)
3. Observe the eyesore of a screenroll effect
Actual Results:  
ChatZilla announces every user quitting your server from a netsplit on separate lines

Expected Results:  
Combine all those quits into one announcement.

[Parity: irssi]
Severity: trivial → enhancement
Whiteboard: [Parity: irssi]
I'm confused. What would the gain be of displaying things as one message if we still add one line for each user who leaves? The screenwiping effect is just as bad then...
Umm.. this bug is for *not* adding one line for each user who leaves, but replacing all those lines with just one. Sorry if that wasn't clear.
Any suggestions on how to implement this?

we should probably do something similar with the MOTD - its much easier with the MOTD, as we can store all the 372 lines until we hit the 376, and then release them as one table cell.

In the case of a netsplit, what would be the best way to know that we have reached the end of the splitting flood?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Other Branch
Version: Other Branch → Trunk
Duplicate of this bug: 520110
(In reply to comment #3)
> In the case of a netsplit, what would be the best way to know that we have
> reached the end of the splitting flood?

The best thing I can think of is setting a time limit of a few seconds such that if no quit messages are sent before that time limit expires, then a merged quit message is delivered to the user displaying the nicks all of the users who had quit messages in that netsplit. Of course, this time limit that I speak of would reset upon every netsplit quit message that arrives. If more users happen to split off after the time limit expires, then those could just be grouped into a second merged netsplit message that would then be shown to the user. Even if this happened, these two netsplit messages being shown to the user would be a lot less than say...50. I'm not sure if what I just described is technically possible, but if it is, I think it would work fairly well.

Also if possible, I would recommend leaving the current netsplit behavior available as an option for those who want to see all of the quit messages individually, but I would think it would be better to have the "merged" variety be the default setting.
Can we rely on the quit message of the netsplit being in a specific format for the detection? That'd make it a lot more reliable...
Yes, it's always "server1 server2" where those are the servers which have disconnected from each other. The short delay for quit messages is basically what I've concluded we'd need to do in the past, too, though maybe only 1s?
How does server lag factor into a big netsplit? Are all of the quits sent within 1 second, or is there a high possibility of it lagging over a period of a few seconds?
All the quits will originate from either server1 or server2, depending which is on the side of the split you're on (indeed, each side may well report the servers in the opposite order), so they should be sent all at once from a single source.

The main reason for wanting a shorter delay is that we'll be delaying *every* quit message by that ammount - unless a non-quit message arrives within the time, which should force the timeout to expire. Good luck coding this, btw. ;)
Sorry, I forgot we'd be matching the message; we *could* be delaying lots of quits. Still, it needs to expire on non-quit messages or quits with different messages arriving.
Is there a feasible way to match a netsplit quit message? Sure, Chatzilla knows what server it's connected to, but is it aware of the names of the other servers on the network?
I've always thought something like this: /^(\w+\.)+\w{2,} (\w+\.)+\w{2,}$/

Obviously very basic and may well not work with IDN hostnames, but it's a start.
(In reply to Spring Rubber from comment #11)
> Is there a feasible way to match a netsplit quit message? Sure, Chatzilla
> knows what server it's connected to, but is it aware of the names of the
> other servers on the network?

Depending on software in use, typical netsplit messages could be
   :username QUIT server1 server2
where server1 is the server you're connected to, or
   :username QUIT *.net *.split
http://ircv3.atheme.org/extensions/batch-3.2 and http://ircv3.atheme.org/extensions/batch/netsplit might be useful here. I haven't actually seen any networks that has implemented this yet, unfortunately.
You need to log in before you can comment on or make changes to this bug.