View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003885unrealircdpublic2010-01-10 03:102010-01-12 19:31
ReporterRobin Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilitysometimes
Status resolvedResolutionfixed 
Product Version3.2.8 
Fixed in Version3.2.9-RC1 
Summary0003885: Unreal3.2.8 with UHNAMES: nickname-list LAG & SendQ High
DescriptionHello everyone,

I have been verified that situation, for any channel with 0000837:0002000 users:

With an older UnrealIRCd version (for ex. 3.2.3), when you type a NAMES (every time when you join a channel) it employs 1 second to load the NAMES list completly.
But with a newer version (3.2.8 & 3.2.8.1) when you do the same operation, it employs 4 seconds to load all the NAMES list.

The cause of that problem it's the UHNAMES extension and naturally that problem doesn't exist if you have a small irc network, but when you have 3 or 4 channels with more of 1500 users, the problem persists.

Another consequence of this extension, it's the maxsendq encrease:

For example, in a situation with a sendq -> 300000, if a user want to connect at the network and he use its autojoin, the irc client do that: JOIN #a,#b,#c
So, if the three channels have more of 1500 users, probably happens that:
[16:55:43] -hub6.***.net- *** Notice -- Client exiting at irc.***.org: [email protected].***.*** (Max SendQ exceeded)

Actually all the admins of a large ircnetwork are forced to choose:
1 - increasing the maxsendq (class clients) compromising the IRC security
2 - editing the m_names.c module before compiling to remove UHNAMES itself.

This is just a suggestion, but I think the NAMES function in the IRC protocol was been created to make a fast form of the WHO, with which you can execute a faster nickname-list load.

Newer UnrealIRCd:
[m_names.c]
if (!uhnames) {
s = acptr->name;
} else {
strlcpy(nuhBuffer,
make_nick_user_host(acptr->name, acptr->user->username, GetHost(acptr)),
bufLen + 1);
s = nuhBuffer;
}
/* 's' is intialized above to point to either acptr->name (normal),
* or to nuhBuffer (for UHNAMES).
*/
for (; *s; s++)
buf[idx++] = *s;

Older UnrealIRCd:
[m_names.c]
for (s = acptr->name; *s; s++)
buf[idx++] = *s;


I'm sure, the priority for you it's maintaining unrealircd as a deamon sure and fast, it's for what I suggest you to create an option to enalbe/disable the User+Host NAMES.

Sincerly, Robin (Net Admin @ DarkSin irc network)
TagsNo tags attached.
3rd party modules

Relationships

child of 0003776 resolvedsyzop Unreal3.2.9 TODO 

Activities

syzop

2010-01-10 13:52

administrator   ~0015997

Ok, I've tested it.
First, speed. It looks like the speed decrease you mention is mostly due to the network connection. With that, I mean, that it's not that Unreal becomes terribly slow (or high cpu%), and that if the bandwidth to the irc server is high enough, that it succeeds quickly.
I've tested it on local LAN, and it took 0.5 seconds to do a join to 3 channels (JOIN #test,#test2,#test3) with 1500 users.
I've also tested in on a remote IRC server (same country, though), and it took 1.8 seconds (again, from the JOIN command to 3 channels, until the last NAMES reply ended). Of course, my speed may differ with a real network, this is just testing delay in optimal conditions.
As said, I was concerned that what you were experiencing would be because of high ircd cpu usage, but fortunately that doesn't seem to be the case.

Then... this is still a problem on the Internet, indeed it takes a lot of bandwidth... 208K in my test for these 1500*3 users in names with UHNAMES.
Perhaps, let me explain why UHNAMES was invented in the first place (I didn't invent it, btw, but I can make a good guess as to why).
Currently when you join the channel as a user, you've no idea about the ident&hostname of existing users. This means, when you want to place a ban, and the user hasn't talked yet, your client has to do a 'USERHOST usertobebanned' or similar request to find out the banmask to use (*!*ident@*.someisp.com).
For new users who join after you're there this is no problem, as you see the nick!user@host, the same is true when a user has messaged on the channel, as any command shows the :nick!user@host prefix.
Still.. as said, to have a list of ident@hosts for all users, you need to do some extra command.
What some clients and quite some scripts therefore do is, once you've joined, issue a 'WHO #channel'.
The 'WHO #channel' output includes various other stuff and only shows 1 user per line, and is therefore much less efficient than showing it in NAMES.
The 'WHO #channel' on networks with large channels usually required tweaking of sendq as well, as it generates a lot of output. Pretty much every ircadmin/ircop I know has done this. As otherwise you see: join, quit with sendq exceeded, join, quit with sendq exceeded, and you simply lose users.

So, compared with the previous situation, bandwidth wise UHNAMES is better than NAMES+WHO, but is worse for clients that didn't do any WHO.

Also, let me point out that we don't send these nick!user@hosts to all clients. The client explicitly asks the IRCd to do so, by doing 'PROTOCTL UHNAMES' (which mIRC does automatically, when it sees the IRCd supports it). If the client doesn't ask, then the IRCd will send the old NAMES style :).

Now.. I can understand if you think this is way too much text to send to a client. And indeed, if it causes significant slowdown to your users, then you might want to disable it.
Personally, if it's 2 seconds, I find it quite acceptable. But 4 or more, no, I agree.. that seems too much.
I'll therefore put an option in Unreal to disable UHNAMES.

I just wanted to clear up that it isn't a totally stupid feature :P.

And, thank you for letting us know this is a real issue on your network, we were simply not aware of it before!

syzop

2010-01-12 19:31

administrator   ~0016000

Added in CVS .791:
- Added set::uhnames setting which can be used to disable uhnames by setting
  it to 'no', the default is 'yes' (on). Requested by Robin (0003885) as
  UHNAMES may increase the time of the nick list being loaded from 1 to 4
  seconds when joining several channels with more than 1000 users. As this
  problem is only present on some networks, we keep UHNAMES enabled by default.

Thanks for the report.

Issue History

Date Modified Username Field Change
2010-01-10 03:10 Robin New Issue
2010-01-10 13:52 syzop Note Added: 0015997
2010-01-10 13:52 syzop Status new => confirmed
2010-01-10 13:52 syzop Relationship added child of 0003776
2010-01-12 19:31 syzop QA => Not touched yet by developer
2010-01-12 19:31 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2010-01-12 19:31 syzop Note Added: 0016000
2010-01-12 19:31 syzop Status confirmed => resolved
2010-01-12 19:31 syzop Fixed in Version => 3.2.9-RC1
2010-01-12 19:31 syzop Resolution open => fixed
2010-01-12 19:31 syzop Assigned To => syzop