0003038: Bandwidth and resource wastage when changing hostnames

(0012241)
aquanight (reporter)
2006-08-26 15:28

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

(0012242)
brain4 (reporter)
2006-08-26 15:38

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

(0012243)
Stealth (administrator)
2006-08-26 15:56

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

(0012244)
brain4 (reporter)
2006-08-26 15:57

That's not the point.

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

(0012247)
Trocotronic (reporter)
2006-08-27 07:21

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?".

(0012248)
brain4 (reporter)
2006-08-27 07:30
edited on: 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.

(0012252)
aquanight (reporter)
2006-08-27 18:38
edited on: 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!]

(0012254)
Stealth (administrator)
2006-08-27 22:26
edited on: 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...

(0012368)
syzop (administrator)
2006-09-09 07:34

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.

(0012410)
syzop (administrator)
2006-09-19 17:42

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

(0012411)
penna (reporter)
2006-09-20 04:53

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

Issue History
Date Modified	Username	Field	Change
2006-08-26 15:23	brain4	New Issue
2006-08-26 15:25	brain4	Issue Monitored: brain4
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-08-29 04:43	tabrisnet	Issue Monitored: tabrisnet
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

Notes
(0012241) aquanight (reporter) 2006-08-26 15:28	Only true if all 40 people were on the same server.

(0012242) brain4 (reporter) 2006-08-26 15:38	If you have remote users, the remote users STILL see parts and joins, they'll act upon the CHGHOST ;)

(0012243) Stealth (administrator) 2006-08-26 15:56	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

(0012244) brain4 (reporter) 2006-08-26 15:57	That's not the point. Every other ircd with this feature uses QUITs because of this very reason, it is an issue...

(0012247) Trocotronic (reporter) 2006-08-27 07:21	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?".

(0012248) brain4 (reporter) 2006-08-27 07:30 edited on: 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.

(0012252) aquanight (reporter) 2006-08-27 18:38 edited on: 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!]

(0012254) Stealth (administrator) 2006-08-27 22:26 edited on: 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...

(0012368) syzop (administrator) 2006-09-09 07:34	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.

(0012410) syzop (administrator) 2006-09-19 17:42	acknowledged as to-be-done, but not assigned. so no ETA.

(0012411) penna (reporter) 2006-09-20 04:53	Well ircu uses quit/join and not part/join and I don't think that quit/join confuses more then part/join.

Relationships