You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of away-notify still requires a /WHO performed on an entire channel to receive the current away or not away status of all members. This can lead to SendQ Exceeded quits if done on many large channels as clients often join all at once (or attempt to at least) (this kind of quitting can be observed e.g. on freenode at times).
As account-notify relies on WHOX this might be a suitable approach for away-notify as well at least when WHOX is supported. For the thoughts I here I will assume the environment does support WHOX and that the client can parse it without any issues.
Client /JOINs a new channel e.g. #Chan
Client runs /NAMES and instead of /WHO #Chan it will instead run /WHO * A
Client will receive in this /WHO query only those who are marked as being /AWAY for ANY reason (as the exact reason does not matter, basically just the G or H flags from "old" WHO)
Client will compare received WHOX results with /NAMES and all that appear in both are thus "marked as being away" and those only in /NAMES are thus "not marked as being away"
Why use this instead:
The answer is simple, one receives less results from this WHOX query as even if we take e.g. #freenode on chat.freenode.net with an average usernumber of 1800 and we assume half are /AWAY we will "only" receive up to 900 results in our WHOX query vs all 1800 with an "old" WHO query, thus saving us 50% of results (which we do not care about anyway as it is just about "Here" or "Gone").
Adding this up on more very large channels and joining a lot at once, this can significantly reduce the risk of quitting prematurely due to a SendQ exceeded or even remove the risk "entirely" (technically not possible besides limiting how many channels one can be in, which is a given on all (?) networks these days).
Any thoughts, ideas, feedback are greatly appreciated.
Hint: As I have no programming experience I cannot evaluate how difficult the "compare WHOX results to NAMES" actually is or would be, so those who can tell, feel free to point it out, but it is also a lot about the idea itself.
Regards,
Koragg
The text was updated successfully, but these errors were encountered:
The current implementation of away-notify still requires a /WHO performed on an entire channel to receive the current away or not away status of all members. This can lead to SendQ Exceeded quits if done on many large channels as clients often join all at once (or attempt to at least) (this kind of quitting can be observed e.g. on freenode at times).
As account-notify relies on WHOX this might be a suitable approach for away-notify as well at least when WHOX is supported. For the thoughts I here I will assume the environment does support WHOX and that the client can parse it without any issues.
Why use this instead:
The answer is simple, one receives less results from this WHOX query as even if we take e.g. #freenode on chat.freenode.net with an average usernumber of 1800 and we assume half are /AWAY we will "only" receive up to 900 results in our WHOX query vs all 1800 with an "old" WHO query, thus saving us 50% of results (which we do not care about anyway as it is just about "Here" or "Gone").
Adding this up on more very large channels and joining a lot at once, this can significantly reduce the risk of quitting prematurely due to a SendQ exceeded or even remove the risk "entirely" (technically not possible besides limiting how many channels one can be in, which is a given on all (?) networks these days).
Any thoughts, ideas, feedback are greatly appreciated.
Hint: As I have no programming experience I cannot evaluate how difficult the "compare WHOX results to NAMES" actually is or would be, so those who can tell, feel free to point it out, but it is also a lot about the idea itself.
Regards,
Koragg
The text was updated successfully, but these errors were encountered: