Message delay/lag when sending a large number of lines #768

Shawn-Smith opened this Issue Feb 7, 2014 · 14 comments


None yet

6 participants


The issue seems to happen when InspIRCd is sending a large number of lines to a user. Part way through the sending InspIRCd will stop all sending and wait for the user to send another command of any kind before continuing sending the previous commands lines.

The logs below are from the channel #InspIRCd on

> 16:56:04 chatspike +| NAMES #inspircd
< 16:56:04 chatspike +| 353 Shawn = #inspircd :@ChanServ! %slush!djslash@ChatSpikepti.kgv.188.89.IP psychon! jenkins! alprox! ruok! macgyver-dgi! &@Attila! berndj! alyx!
< 16:56:04 chatspike +| 353 Shawn = #inspircd :SmallR2002! mac-mini! KindOne! &@danieldg!me@i.know.regexes +grawity! &@Majic! @spb! %fraggeln!fragg@ChatSpiketd4.2v0.63.144.IP %Shutter! cereal! kylef!
< 16:56:04 chatspike +| 353 Shawn = #inspircd :mlatin! &@aquanight!aquanight@ChatSpikevmq.0kl.118.159.IP MillenniumFalc0n! +Adam! jerith! +Colgate! Murarth! deathspawn! Googolplexed!
< 16:56:04 chatspike +| 353 Shawn = #inspircd :md_5! LinDaa!MzBabii@ChatSpikeo3l.6nb.199.99.IP +special! Meistarin! Kazuma! Nazca__!Nazca@ChatSpikesma.i0t.75.77.IP Stmeter!Stmeter@ChatSpike528.v1a.71.64.IP Rylee! AleX!agent@ChatSpike0kh.6nb.163.46.IP +beorn! Duck!
< 16:56:04 chatspike +| 353 Shawn = #inspircd :Colin! %SaberUK! cooper! danneh_!d@ChatSpikeesv.9ej.165.101.IP Ikaros! edem! tty0! Ch4c!Blink@ChatSpike3rj.4bk.47.78.IP ~@FrostyCoolWork! Techman! %ChrisTX!
< 16:56:04 chatspike +| 353 Shawn = #inspircd :Domin_! therock247uk! Ben!Ben@ DanielNM! HeavyMetal!user@ChatSpikempc.3bj.248.206.IP alamar! Svetlana! Syloq!Syloq@ChatSpikeq4i.v8d.254.173.IP macmaN! Kross!
< 16:56:04 chatspike +| 353 Shawn = #inspircd :@satmd! cooldude! Xaquseg! shayne! LeaChim! O_O! xyzzy!.@ChatSpikepd0.5uv.45.92.IP &@peavey!ambient@devils.own Cronus! Sagar!ICP@ChatSpikegas.nn1.63.74.IP
< 16:56:04 chatspike +| 353 Shawn = #inspircd :roe_! JanE! nimrod!cdxx@ChatSpikea30.ajs.241.199.IP ~@w00t! k1ng!k1ng@ChatSpike3er.9mc.73.76.IP Simos! Phantomal! Vincent! JD! +Robby! m4z!

< Nothing happens from here until I issue another command, 20 seconds later. >

> 16:56:24 chatspike +| MAP
< 16:56:24 chatspike +| 353 Shawn = #inspircd :Alpha! Dragon! Whiskey!Whiskey@ChatSpikeneg.us2.44.31.IP kraft!kraft@ChatSpike17d.a67.246.46.IP Sporks! Simwar! blaster! +Brick! tomaw! DukePyrolator!
< 16:56:24 chatspike +| 353 Shawn = #inspircd :Keith!Keith@ChatSpiken9c.kvp.214.67.IP Zyferus! hayuto!hayuto@ChatSpikehqt.p1v.59.37.IP +TinMan!metal@ChatSpikecnl.a6h.162.178.IP MzLinDaa!Mzbabii@ChatSpikeo3l.6nb.199.99.IP Milliways! ctcp! wloo299! pcpl2! %Shawn!
< 16:56:24 chatspike +| 366 Shawn #inspircd :End of /NAMES list.
< 16:56:24 chatspike +| 006 Shawn     255 [49.51%]
< 16:56:24 chatspike +| 006 Shawn      250 [48.54%]
< 16:56:24 chatspike +| 006 Shawn    10 [ 1.94%]
< 16:56:24 chatspike +| 270 Shawn :3 servers and 515 users, average 171.67 users per server
< 16:56:24 chatspike +| 007 Shawn :End of /MAP

As you can see, part way through sending me the NAMES reply it stops for at least 20 seconds before I send the MAP command. It then finishes sending me the NAMES reply and then sends me the output of MAP.


I can also reproduce this by issuing LIST. The list wont finish until I send another command. Similar to the above logs with NAMES.


This sounds like something I remember having been fixed already. What client are you using, and are you connected using SSL?


@ElementalAlchemist Weechat 0.4.2, and yes I'm using SSL.

Colgate on IRC thought it sounded like something that was mentioned before too but couldn't find a commit or other issue to reference.

Adam- commented Feb 8, 2014

@Adam- Thanks! Is there anything clients should be doing to fix this on their end?

Adam- commented Feb 8, 2014

I don't know what the problem is or why this fixes it. Attila might know.


I'll leave this issue open until @attilamolnar sees it and can provide more insight to what client authors should be doing to fix this then.

Robby- commented Feb 8, 2014

I'll be damned, I first hit this problem a LONG time ago, when creating an opered bot, connected via SSL. I've not experienced this bug much lately, though, but a CHECK * also causes this issue on a network with a few hundred users. I always blamed the bot for this as I could never reproduce it on my own client for some reason. I didn't think this was an InspIRCd issue as making the bot send another command (or anything) simply triggered the pending data to be processed by the bot, I just figured it was the bot being stalled and didn't investigate further.


It's primarily a client issue, specifically in how they handle the message queue in SSL packets. There was a change in 1.2 to send as many messages as possible in a single packet, which chokes some clients that have no idea how to SSL.

The issue can be mitigated with server changes, but at the core, it's a client issue.

SaberUK commented Feb 8, 2014

Is the server you are testing on running the latest version of InspIRCd? This should have been fixed in 7dd381f. Adam already said this.


@ElementalAlchemist How would client authors fix this?


Don't just stop processing the message queue after the first line in an SSL packet is processed? I'd imagine that's the problem anyway. Most clients didn't seem to have an issue with it, of course.

Of course, all these clients that just delay processing are still doing better than Pidgin did when this was first implemented, and Pidgin would just drop all the lines that weren't the first.


Going to close this now since it's not an InspIRCd issue and information has been given for client authors to fix this on their end.

@Shawn-Smith Shawn-Smith closed this Mar 5, 2014

Just an FYI for those dealing with this:
I encountered this issue, and was able to remedy it by doubling the size of the read buffers in my client app. Seemed otherwise lines were getting dropped / missed by my client.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment