UnrealIRCd Forums

Unreal3.2.8.1 nickname-list LAG & SendQ High

Hello Everyone,

I use UnrealIRCd since 2004 with the status of Net Admin. I code to myself many patch to make more confortable the unrealircd and I thank you very much for your great work.
I'm sorry to first if my english it's not correct, I'm Switzerland and I usually speak Italian or French.

I write here because I think it's very important to know that:
With the older unrealircd (for example 3.2.3), when you type a NAMES (every time when you join channel) It empolys 1 second to load a NAMES list composed by ~2000 users.
But with the newer unrealircd version (3.2.8 & 3.2.8.1), when you do the same operation, it employs 4 seconds to load all the NAMES list.
I think the priority for you it's maintaining unrealircd a faster irc-deamon.

Naturally, the 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.

For example:

I am 'X' and I want to join in my usually ircnetwork; with my autojoin, i do that: JOIN #a,#b,#c
So, if #a #b and #c are under 1500users no problem, but if all the three channels are over 1500, probably happens that:
[16:55:43] -hub6.***.net- *** Notice -- Client exiting at irc.***.org: [email protected].***.*** (Max SendQ exceeded)
That because:
class clients
{
...
sendq 300000;
...
};

###########################################################

Now the PROBLEM need a SOLUTION:

### Simply solution ###:

INCREASE YOUR MAXSENDQ (class clients)

Therefore all the admins of a large ircnetwork are forced to increase the maxsendq (class clients) compromising the IRC security

### Another solution ###:

Replacing that:
[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;

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

###########################################################

I'm not an irc expert, 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.

Dear UnrealIRCD Staff, I pose to you a question:
Why, in the new unrealircd you have been added a "GetHost" function into the NAMES?

(Actually you have created a NAMES similar to the WHO; why?)


Sincerly, Robin (Net Admin @ DarkSin irc network)

I think you're talking about the UHNAMES extension (note: the command is still /NAMES). Yes it outputs a lot more, namely the nick!user@host, so yes, this can easier cause your sendq to be exceeded. This is enabled by the client through 'PROTOCTL UHNAMES' (which for example, mIRC does).
I don't think there's an option to disable NAMESX/UHNAMES at the moment. If you want that, go to http://bugs.unrealircd.org and post it as a feature request.

I doubt that you will have a 4 second delay with only 1500 users though, that's really a lot, but I'll test it!

Actually, you should have reported this on bugs.unrealircd.org, as it's not really something for a forum discussion.

I have been opened a feature: http://bugs.unrealircd.org/view.php?id=3885

Can i know why you have been implemented UHNAMES ?
I hope the feature (if confirmed) allows to resolve the problem without editing m_names.c / increasing maxsendq

Best Regards, Robin

UHNAMES was added to Unreal because it was heavily requested by the community. The purpose of UHNAMES is to eliminate the need for supporting clients to request a WHO listing for a channel when joining to fill their address lists. Many clients request a WHO listing upon joining so they have the addresses of all the users in the channel to assist in automated tasks such as banning and clone detection.

Implementing an option to disable UHNAMES will likely require a modification to m_names.c, because as you already know all the NAMES command handling is handled in m_names.c.

Please use http://bugs.unrealircd.org/view.php?id=3885 for any further discussion (if any).