View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006360 | unreal | documentation | public | 2023-11-05 13:14 | 2023-11-25 14:53 |
| Reporter | armyn | Assigned To | syzop | ||
| Priority | normal | Severity | block | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | ||
| Product Version | 6.1.1.1 | ||||
| Summary | 0006360: Add the 'who' commands sent in a kind of 'nofakelag' exception | ||||
| Description | Hello, Is there a feature or configuration that can be put in place to allow unlimited sending of the "who" command? This is intended for mobile clients, so that they can receive responses to the "who" command as quickly as possible upon automatic reconnection, thereby reducing lag, as it currently takes a very long time. Regards | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
There's not really such a setting, no. When the server processes a WHO request it will send the reply instantly. All of below should not be different for desktop vs mobile, but, here we go: It sounds like you are hitting fake lag, which means processing commands is delayed because there are too many per (10) second(s). This can happen when you are sending a lot of commands after you get connected (after initial USER/NICK/CAP). I don't know what client you use, but for example, if you send "JOIN #a" then "JOIN #b" and "JOIN #c" that already count as 3 commands. It is better to use "JOIN #a,#b,#c" if you already know you will join these 3 channels, since they count as 1. Similarly, maybe you send a "MODE #channel b" on join to get the ban list or some other commands (that would be unusual, most clients don't do that, but it's just an example). Now, if you do a lot of these like 1 JOIN + 1 MODE + 1 WHO for every channel, and you do that for like 4 channels on connect, then that is already 3 x 4 = 12 lines. Once you are above 10 then fake lag will kick in. Allowing 1 command per second. So 12 means, 10 commands will processed fast, then 1 with a second delay, and then 1 with another extra second delay. Well, actually it is a bit more complicated than that, as size of the line also is taken into account, but this to keep it understandable ;D So, yeah, it really depends on the client, what it all sends, and on the settings like which channels are all joined. UnrealIRCd processes commands in the order in which they are received. And when fake lag kicks in it will delay further processing of commands for a second or so. So it isn't really possible for other commands to "jump the line" (get priority), as the other commands, the other lines, haven't even been parsed yet, unrealircd doesn't even know what next pending command will be. Maybe it is possible to tweak the client a little, to send commands more efficiently, or put important commands first and send other less important commands later? I don't know, like i said, it depends on the traffic. If your client has a debug window then this will show what happens exactly. |
|
|
Thank you for all the explanations. I didn't know it was preferable to send /join #chan1,#chan2,#chan3,#chan4 instead of the commands /join #chan1 and /join #chan2... I also made some changes to the client this afternoon to reduce the number of /who #chans and /who <nick> commands, especially the unnecessary ones, as there were too many, sometimes even duplicates or in a loop because in my "join" event, there are some "who user" commands, and when I reconnect to the BNC, I receive the latest joins, and all these joins trigger a "who" command. It's strange that I have to use joins for each user. I need to prioritize improving this aspect with the "who" commands because it's the only thing that could cause problems. I'll work on improving all of this and make my code better. |
|
|
Sure, happy to help :) As for doing "WHO nickname" on every join of nickname: do you use that to get the gecos/realname? Because there is a better way of doing that, have a look at: https://ircv3.net/specs/extensions/extended-join You still have to do a "WHO #channel" when you join yourself to get the current realnames of everyone in the channel, but after that... every next JOIN by someone in that channel... you will see the realnames in the JOIN message already, so no need to do a WHO. |
|
|
The 'extended-join' is already activated. The 'who' command on each user who logs in is meant to gather all their information into a global object array, including around 10-15 data points, somewhat like a 'whois' with the same details. It also includes the user's 'away' status so that I can reach out to them when needed, thereby avoiding the need to perform multiple 'whois' requests. Since yesterday, I've optimized the 'join' event to minimize the number of 'who' requests to be sent, and in the near future, I'll also focus on the commands being sent at the start of the server. When it comes to joining channels like #a, #b, #c, it's working perfectly and helps save space. It's great that there are only between 2 and 4 'join' requests at most, not 10 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-11-05 13:14 | armyn | New Issue | |
| 2023-11-05 16:07 | syzop | Note Added: 0023073 | |
| 2023-11-05 18:28 | armyn | Note Added: 0023074 | |
| 2023-11-05 19:09 | syzop | Note Added: 0023075 | |
| 2023-11-06 13:36 | armyn | Note Added: 0023076 | |
| 2023-11-25 14:53 | syzop | Assigned To | => syzop |
| 2023-11-25 14:53 | syzop | Status | new => closed |
| 2023-11-25 14:53 | syzop | Resolution | open => no change required |
