View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003038 | unreal | ircd | public | 2006-08-26 15:23 | 2013-05-06 07:58 |
| Reporter | brain4 | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | All | OS | All | OS Version | All |
| Product Version | 3.2.6 | ||||
| Fixed in Version | 3.4-alpha1 | ||||
| Summary | 0003038: Bandwidth and resource wastage when changing hostnames | ||||
| Description | When 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 Reproduce | Change hosts with the required option enabled. | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
Only true if all 40 people were on the same server. |
|
|
If you have remote users, the remote users STILL see parts and joins, they'll act upon the CHGHOST ;) |
|
|
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 |
|
|
That's not the point. Every other ircd with this feature uses QUITs because of this very reason, it is an issue... |
|
|
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?". |
|
|
"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. |
|
|
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!] |
|
|
> "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... |
|
|
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. |
|
|
acknowledged as to-be-done, but not assigned. so no ETA. |
|
|
Well ircu uses quit/join and not part/join and I don't think that quit/join confuses more then part/join. |
|
|
http://hg.unrealircd.org/hg/unreal/rev/df429d68f918 |
| 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 |
|
Note Added: 0017506 | |
| 2013-05-06 07:58 |
|
Status | acknowledged => resolved |
| 2013-05-06 07:58 |
|
Fixed in Version | => 3.4-alpha1 |
| 2013-05-06 07:58 |
|
Resolution | open => fixed |
| 2013-05-06 07:58 |
|
Assigned To | => nenolod |
