View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003900unrealircdpublic2010-04-04 10:132012-10-06 11:56
Reporterdriew Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status resolvedResolutionfixed 
PlatformLinuxOSCentOSOS Version5.3
Product Version3.2.8 
Fixed in Version3.2.10-rc1 
Summary0003900: UHNAMES following HTM
DescriptionThis has a lot to do with the following bug:
http://bugs.unrealircd.org/view.php?id=3885

But, would it break clients to disable the extended names reply while in HTM?
I only wonder, if once a client says PROTCTL UHNAMES, that if not giving UHNAMES if that's a violation of the protocol, of which you couldn't do this.

It's extremely trivial to make it do this, I just don't know the consequence of doing so.

Otherwise, I would suspect this would be very beneficial to disable while in HTM and return the old style names reply.

I know there are times while on my network, I've had to enable htm temporarily to get a link to sync up while bandwidth is extremely limited. Since there seems to be many clients using auto /who's on users and channels to check away statuses and whatnot. Which can be bad during a rare, but sucky situation when two slow-link/high-latency hubs are trying to sync together. (such as links between the US and the EU)
Additional InformationLine 209 of 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;
                }

Could be:
                if (lifesux || !uhnames) {
                        s = acptr->name;
                } else {
                        strlcpy(nuhBuffer,
                                make_nick_user_host(acptr->name, acptr->user->username, GetHost(acptr)),
                                bufLen + 1);
                        s = nuhBuffer;
                }
TagsNo tags attached.
3rd party modules

Relationships

related to 0004127 closedsyzop HTM enhancements 
child of 0003915 resolvedsyzop Unreal3.2.10 TODO 
child of 0004301 resolvedsyzop Unreal3.2.10 TODO 

Activities

syzop

2010-04-10 19:44

administrator   ~0016063

Sounds good.
In addition to that, I think we should disable /WHO during HTM (it only seems to limit '/WHO *' at the moment).
As WHO is really one of the most floody commands out there (2nd after LIST).

I think the clients will do fine, even though it might violate some spec...
Anyway, HTM means "I'm really short of bandwidth", so such consequences would be justified (like clients not having a fully up to date IAL due to not receiving UHNAMES and WHO)

driew

2010-04-14 12:28

reporter   ~0016064

Also, I don't know if this has been reported in the past.. but I think HTM should have an outgoing trigger along with the incoming.

Without looking at the code, I don't know how complex it would be to add that.
But if we go with disabling /who, /list, and using short /names replies during HTM, the server should also know when it's reaching it's outgoing limit just as much as it's incoming.

Though I think HTM was originally designed to prevent 100% cpu situations under incoming floods; but it could be adapted very well to handle both aspects of "I have no bandwidth left..". Since the results of running out of outgoing bandwidth is very ugly, nearly as ugly as the ircd getting swapped out ;)

syzop

2012-10-06 11:56

administrator   ~0017144

- Disable sending of UHNAMES when HTM (High Traffic Mode) is ON,
  suggested by driew (0003900).

I've cloned this bug to new issue 0004127 to deal with the other things that were mentioned by you and me.

Issue History

Date Modified Username Field Change
2010-04-04 10:13 driew New Issue
2010-04-10 19:44 syzop Note Added: 0016063
2010-04-14 12:28 driew Note Added: 0016064
2010-07-14 17:17 syzop QA => Not touched yet by developer
2010-07-14 17:17 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2010-07-14 17:17 syzop U4: Upstream notification of bug => Not decided
2010-07-14 17:17 syzop U4: Contributor working on this => None
2010-07-14 17:17 syzop Severity minor => feature
2010-07-14 17:18 syzop Relationship added child of 0003915
2012-10-06 11:52 syzop Issue cloned: 0004127
2012-10-06 11:52 syzop Relationship added related to 0004127
2012-10-06 11:56 syzop Note Added: 0017144
2012-10-06 11:56 syzop Status new => resolved
2012-10-06 11:56 syzop Fixed in Version => 3.2.10-rc1
2012-10-06 11:56 syzop Resolution open => fixed
2012-10-06 11:56 syzop Assigned To => syzop