View Issue Details

IDProjectCategoryView StatusLast Update
0003038unrealircdpublic2013-05-06 07:58
Reporterbrain4 Assigned Tonenolod 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version3.2.6 
Fixed in Version3.4-alpha1 
Summary0003038: Bandwidth and resource wastage when changing hostnames
DescriptionWhen a user changes their hostname or ident there is a configuration option which allows a the ircd to show the user as parting and rejoining, so clients can stay in sync:

[21:09] <-- Parts: jasont308 ([email protected]) (Rejoining because of user@host change)
[21:09] --> Joins: jasont308 ([email protected])

The problem is that this uses much more bandwidth than neccessary.

Take for example if jasont308 is "visible" to 40 users on 10 channels, this means that 40x10 parts must be sent out, this is 400 part lines to 40 different clients. We must then send 40x10 JOINs, so in total we now have 800 lines of text sent out for one vhost change (even more if you count the 'restoration' of modes if they were opped when they changed hosts).

Instead i propose that the PART is replaced by a QUIT (as the user never actually quits anyway this shouldnt be difficult), taking the number of output lines down to 440 (40x QUIT plus 40x10x JOIN) and saving a LOT of bandwidth in the process:

[21:09] <-- Quits: jasont308 ([email protected]) (Changing host)
[21:09] --> Joins: jasont308 ([email protected])
Steps To ReproduceChange hosts with the required option enabled.
TagsNo tags attached.
3rd party modules

Activities

aquanight

2006-08-26 15:28

reporter   ~0012241

Only true if all 40 people were on the same server.

brain4

2006-08-26 15:38

reporter   ~0012242

If you have remote users, the remote users STILL see parts and joins, they'll act upon the CHGHOST ;)

Stealth

2006-08-26 15:56

reporter   ~0012243

I don't like this idea... if you honestly had an issue with bandwidth, then don't use the feature. Clients really ony desynch if they are crappy and don't check/update their info when people talk

brain4

2006-08-26 15:57

reporter   ~0012244

That's not the point.

Every other ircd with this feature uses QUITs because of this very reason, it is an issue...

Trocotronic

2006-08-27 07:21

reporter   ~0012247

PART is long about ~64bytes. Imagine that channel has 100 users (medium network). That's 6400bytes (~6.4kb). JOIN is less than PART, but we assume is 64bytes long too. So, server sends <12.8kb. On a worse case for a server connection which is 30kb/s for upload, this amount of data would be sent in 3/5seconds=0.4s=4ds. Do you think that's really a big wastage of bandwith?
If you don't like math, I'd like to add QUIT could causes confusion on users. "Hey jasont308, why do you quit? Am I boring you?".

brain4

2006-08-27 07:30

reporter   ~0012248

Last edited: 2006-08-27 07:32

"Hey jasont308, why did you *PART*? am i boring you?" :p

Quit is also shorter (text wise) than Part, as it doesnt have a channel name in its parameters. So even the one QUIT message is shorter than a single PART message, but the point is you have to send X number of part messages, and you have to do this for every channel the user is on, where you only ever have to send ONE quit!

Speaking of which, PART also has the issue that it probably wont update the hosts of users in private message chats... dont quote me on that.

aquanight

2006-08-27 18:38

reporter   ~0012252

Last edited: 2006-08-27 18:39

Makes me wish the RFC people didn't veto the idea of doing JOIN or PART with multiple channels (server->client). Would save even more bandwidth if you could do :who QUIT blah\n:who JOIN #one,#two,#three,#four,#five,#six,#seven,#etc

btw: possible reason for using PART over QUIT: clients with notify might try to be too smart and signal a signoff when the user didn't really sign off. PART at least doesn't trip clients to signal a signoff so they wait until they get a numeric (WATCH) saying so.

[edit: curse you mantis!]

Stealth

2006-08-27 22:26

reporter   ~0012254

Last edited: 2006-08-27 22:26

> "Hey jasont308, why did you *PART*? am i boring you?"

"Hey jasont308, why did you *QUIT*? am i boring you?"
"Hey jasont308, can I have access to some of your hosts?"
"Hey jasont308, are you really an FBI agent?"
(in help chan) "Hey, I think jasont308 uses open bouncers!"

Let's just say that was a bad example...

syzop

2006-09-09 07:34

administrator   ~0012368

While you (brain4) are right about the saving of bandwidth, I don't like the idea for other reasons.
The rejoin stuff already isn't too nice, but it's acceptable. The quit thing on the other hand, is a lot worse in my eyes, causing confusion to both clients and users, since it really looks like the user reconnected.

In my opinion the "correctness" or "visibility" or whatever-you-call-it argument should prevail over the bandwidth argument in this case.

Anyway...... Since it can be a significant decrease in bandwidth (~40% on avg), I think I'll make it an option regardless of what my opinions are. So a network could opt for quit.

syzop

2006-09-19 17:42

administrator   ~0012410

acknowledged as to-be-done, but not assigned. so no ETA.

penna

2006-09-20 04:53

reporter   ~0012411

Well ircu uses quit/join and not part/join and I don't think that quit/join confuses more then part/join.

nenolod

2013-05-06 07:58

reporter   ~0017506

http://hg.unrealircd.org/hg/unreal/rev/df429d68f918

Issue History

Date Modified Username Field Change
2006-08-26 15:23 brain4 New Issue
2006-08-26 15:28 aquanight Note Added: 0012241
2006-08-26 15:38 brain4 Note Added: 0012242
2006-08-26 15:56 Stealth Note Added: 0012243
2006-08-26 15:57 brain4 Note Added: 0012244
2006-08-27 07:21 Trocotronic Note Added: 0012247
2006-08-27 07:30 brain4 Note Added: 0012248
2006-08-27 07:31 brain4 Note Edited: 0012248
2006-08-27 07:32 brain4 Note Edited: 0012248
2006-08-27 18:38 aquanight Note Added: 0012252
2006-08-27 18:38 aquanight Note Edited: 0012252
2006-08-27 18:39 aquanight Note Edited: 0012252
2006-08-27 22:26 Stealth Note Added: 0012254
2006-08-27 22:26 Stealth Note Edited: 0012254
2006-09-09 07:34 syzop Note Added: 0012368
2006-09-19 17:42 syzop Note Added: 0012410
2006-09-19 17:42 syzop Status new => acknowledged
2006-09-20 04:53 penna Note Added: 0012411
2010-07-14 21:07 syzop QA => Not touched yet by developer
2010-07-14 21:07 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2010-07-14 21:07 syzop U4: Upstream notification of bug => Not decided
2010-07-14 21:07 syzop U4: Contributor working on this => None
2010-07-14 21:07 syzop Severity trivial => feature
2013-05-06 07:58 nenolod Note Added: 0017506
2013-05-06 07:58 nenolod Status acknowledged => resolved
2013-05-06 07:58 nenolod Fixed in Version => 3.4-alpha1
2013-05-06 07:58 nenolod Resolution open => fixed
2013-05-06 07:58 nenolod Assigned To => nenolod