|
Joined: Oct 2017
Posts: 47
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2017
Posts: 47 |
Hallo, Greetings from Braunau am Inn
I found a new issue on mirc, in some networks the network administrators can LOCK some irc commands, one of them is /LIST But in mirc is causing issues and keeps saying all the time, * /list: listing in progress... error.
Informations:
- -IRC.NetWorK.Net- The command LIST has been disabled by the network administrators - * /list: listing in progress... - * /list: listing in progress... - (/quote list) -> Server: list - -IRC.NetWorK.Net- The command LIST has been disabled by the network administrators - * /list: listing in progress... - * /list: listing in progress...
mirc keeps saying this all the time that is in progress that seems to acting incorrect.
- GG
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
Thanks for your bug report. This is by design. mIRC is waiting for the correct reply from the server to confirm that the /list request has ended, which in this case would be numeric 323.
mIRC intentionally prevents another /list request from being sent if a listing is currently in progress. This was implemented very early on in mIRC's development, when users were being regularly disconnected from servers due to sending too many /list requests. This was due to servers having difficulty coping with the bandwidth needed to repeatedly send lists to users. So mIRC tried to decrease the strain on servers by preventing users (especially new users) from queuing multiple /list requests (often by mistake, especially if there was lag and issuing a /list did not result in an immediate reply from the server). This means that when you issue a /list, mIRC will wait for numeric 323 to confirm that the listing has ended before allowing you to send another /list. There is no timeout because there is no way to know how long a listing will take. Sometimes it will take a few seconds, other times it can take several minutes. So mIRC depends on the server to send the expected numeric 323 when the listing ends or if there is no list at all.
|
|
|
|
Joined: Oct 2017
Posts: 47
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2017
Posts: 47 |
Yes but in this case the ircd doesn't accepting the command at all (because it is LOCKED by config) , so the mirc there should not start the /list at all because it will always will say that /list is in progress..
Btw that error message that I provided about is into the ircd core, so you can stop the /list if you get back that server notice because it is locked. I know that there is a way via mSL to do that on /list but because UnrealIRCD 5 will come soon in the market (now in alpha stage) they providing a new module that networks admins can LOCK any irc commands.
In InspIRCD the networks admins can lock too irc commands too but the server is sending 421 raw instead of server notice, but in UnrealIRCD 5 they not.
Last edited by DooMaster; 18/09/19 10:54 AM.
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
Yes but in this case the ircd doesn't accepting the command at all (because it is LOCKED by config) , so the mirc there should not start the /list at all because it will always will say that /list is in progress.. How would an IRC client know that an IRC server does not support a standard IRC command? Is the server indicating this in numeric 005 with a token?
|
|
|
|
Joined: Oct 2017
Posts: 47
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2017
Posts: 47 |
Ok clear.
I will talk with UnrealIRCD devs to change it to work as InspIRCD by sending 421 raw instead of server notice, then I am gonna test it to see how will works and reply you back with more details.
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
I will talk with UnrealIRCD devs to change it to work as InspIRCD by sending 421 raw instead of server notice, then I am gonna test it to see how will works and reply you back with more details. If LIST is not supported, sending a 421 is a better way to inform the client. A NOTICE is not because it could be in many different languages, and even in the same language it could be phrased differently by different server administrators. A 421 numeric is the better way to do this. That said, mIRC does not currently support 421 for LIST. I can add it to the next version however.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
Thanks for your bug report. This is by design. mIRC is waiting for the correct reply from the server to confirm that the /list request has ended, which in this case would be numeric 323.
mIRC intentionally prevents another /list request from being sent if a listing is currently in progress. This was implemented very early on in mIRC's development, when users were being regularly disconnected from servers due to sending too many /list requests. This was due to servers having difficulty coping with the bandwidth needed to repeatedly send lists to users. So mIRC tried to decrease the strain on servers by preventing users (especially new users) from queuing multiple /list requests (often by mistake, especially if there was lag and issuing a /list did not result in an immediate reply from the server). This means that when you issue a /list, mIRC will wait for numeric 323 to confirm that the listing has ended before allowing you to send another /list. There is no timeout because there is no way to know how long a listing will take. Sometimes it will take a few seconds, other times it can take several minutes. So mIRC depends on the server to send the expected numeric 323 when the listing ends or if there is no list at all. I would suggest the following algorithm. After a /list command, start a 60s timer. If a 321 or 322 or 323 numeric is received, stop the timer and then wait for a 323 numeric to be received. If after 60s a 321, 322 or 323 has not been received, assume that the server is not going to respond and allow the user to issue another /list command.
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
After a /list command, start a 60s timer. If a 321 or 322 or 323 numeric is received, stop the timer and then wait for a 323 numeric to be received. If after 60s a 321, 322 or 323 has not been received, assume that the server is not going to respond and allow the user to issue another /list command. mIRC was doing this at one point. However, users kept complaining that the timeout was too short due to lag, so I kept extending it, until I eventually decided to comment it out of the code as it no longer made sense to wait several minutes for a /list timeout.
|
|
|
|
Joined: Aug 2003
Posts: 320
Pan-dimensional mouse
|
Pan-dimensional mouse
Joined: Aug 2003
Posts: 320 |
IMO mIRC should never have code which results in something locking out indefinitely. IMO everything should have some sort of timeout which is no longer than a typical users patience level for that function - so something that locks up the UI should have a short timeout, whereas something like /list might have a much longer timeout. But I would say that the user has to take some responsibility for not issuing too many simultaneous /list commands. And bandwidth and server power have both increased substantially over time so perhaps lagging is less prevalent too.
So perhaps 600s would be a more reasonable timeout.
Alternatively, how about a command to cancel the current /list so you can issue a new one.
Finally, how about the message being something like "* /list: Listing in progress - wait xx seconds for timeout or cancel with /cancellist."
|
|
|
|
Joined: Feb 2003
Posts: 2,812
Hoopy frood
|
Hoopy frood
Joined: Feb 2003
Posts: 2,812 |
Khaled, I think he just meant a 60 second timeout timer on receiving an initial LIST reply numeric, as a test to make sure that the server actually got the LIST command. Just a short primer window.
If somebody is lagging so bad (>60 seconds) AND they keep sending new /list commands to the server every 60 seconds, then that's on them. The server doesn't care anymore if you hammer them with /list commands, they've got plenty of resources today.
Well. At least I won lunch. Good philosophy, see good in bad, I like!
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
I think he just meant a 60 second timeout timer on receiving an initial LIST reply numeric That is what was implemented. Users complained about it, so it was removed.
|
|
|
|
Joined: Apr 2004
Posts: 871
Hoopy frood
|
Hoopy frood
Joined: Apr 2004
Posts: 871 |
I feel like the discussion here has skipped a step, namely.. mIRC intentionally prevents another /list request from being sent if a listing is currently in progress. This was implemented very early on in mIRC's development, when users were being regularly disconnected from servers due to sending too many /list requests. This was due to servers having difficulty coping with the bandwidth needed to repeatedly send lists to users. So mIRC tried to decrease the strain on servers by preventing users (especially new users) from queuing multiple /list requests (often by mistake, especially if there was lag and issuing a /list did not result in an immediate reply from the server). ..is this restriction, which certainly was a good thing at the time, still relevant today?
Saturn, QuakeNet staff
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
..is this restriction, which certainly was a good thing at the time, still relevant today? Well, the only reason we are talking about the current /list implementation is because the OP reported an issue that turns out to be due to a server not sending the correct numeric reply. Other than that, this feature has been working well with few, if any, reports of issues for a decade or more. So I am not really inclined to make any changes to it at this point.
|
|
|
|
Joined: Oct 2017
Posts: 47
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2017
Posts: 47 |
I tried beta 2269 beta on unrealircd 5 (dev) , the IRCd replies with 421 raw if the irc-command is disabled by network admins, but the mIRC seems having the same problem and it keeps saying /list in progress beta changelog says: 33.Added 421 numeric check for server disabled LIST command. Debug: -> IRC.NetWork.Net LIST <10000
<- :IRC.NetWork.Net 421 mynickname The command LIST has been disabled by the network administrators This is the result of 2 times using /list command. ![[Linked Image from i.imgur.com]](https://i.imgur.com/phKOkJb.png)
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
Thanks for testing this out. In RFC1459, the 421 numeric is defined as: :host 421 command :reason The "command" needs to be specified so that a client knows which command caused the issue. In your post, it looks like UnrealIRCd is using "nickname" in place of "command"? That said, numeric 421 as returned on almost all IRC networks changed a long time ago to this: :host 421 nickname command :reason This is the format that mIRC is expecting. Update: I just tested this on UnrealIRCd v4 and v5 and they are returning: :irc.foonet.com 421 nickname COMMAND :Unknown command which is the expected format. Are you sure you typed the debug results in your above post correctly? I also tested disabling the "list" command in UnrealIRCd v5 and it returned the expected 421 format which was parsed by mIRC and enabled /list again.
Last edited by Khaled; 11/10/19 09:38 AM.
|
|
|
|
Joined: Oct 2017
Posts: 47
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2017
Posts: 47 |
Unrealircd 5 made a change today by fixing the reply, but it seems mirc keeps stucks in /list in progress... New debug reply: -> IRC.Network.Net LIST <10000
<- :IRC.Network.Net 421 aiaeggaeihgea :The command LIST has been disabled by the network administrators Old debug reply: -> IRC.Network.Net LIST <10000
<- :IRC.Network.Net 421 aiaeggaeihgea The command LIST has been disabled by the network administrators I don't know what else is the fault here and why it is working on your side and not in mine, If you want further details ask me.
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
Unrealircd 5 made a change today by fixing the reply, but it seems mirc keeps stucks in /list in progress... The 421 reply you have included in your post is still wrong. Please read my previous post? I tested the both UnrealIRCd v4 and the latest 5.0.0-alpha3, downloaded today, which use the correct 421 format, as explained in my above post. Which IRC server are you connecting to that shows the results you are seeing?
|
|
|
|
Joined: Oct 2017
Posts: 47
Ameglian cow
|
OP
Ameglian cow
Joined: Oct 2017
Posts: 47 |
If I understood correctly you want the reply to be like below in order to work (like 421 unknown command format) right?: <- :IRC.Network.Net 421 aiaeggaeihgea LIST :The command has been disabled by the network administrators
|
|
|
|
Joined: Dec 2002
Posts: 5,474
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 5,474 |
If I understood correctly you want the reply to be like below in order to work (like 421 unknown command format) right? Yes, this is the 421 numeric format that IRC networks have been using for a long time. Even UnrealIRCd v4 and v5 use this format.
|
|
|
|
|