Forums Bug Reports Assuming PART is always successful

mIRC assumes the PART command is always successful, which is not the proper way to handle PART messages.

mIRC should wait until the PART is received from the server after "PART #channel" is sent. This would be the proper way to handle parts, as PART is a command that returns a success message.

I can't reproduce this issue here, if I join a #channel and then /part #channel, the channel window is closed only when the PART event from the server is received. Can you describe a step by step process that reproduces the issue you are seeing?

Yes, mIRC waits for the PART from the server when /part is used, but not when the window is closed using the close button.

Are you suggesting that when the user closes a channel window, the window should not actually close until it receives the part event from the server?

This is weird..

/part #channel

-> irc.StormIRC.org PART #channel
<- :Andy!Madison@NetAdmin.StormIRC.org PART #channel

Clicking on the close button

<- :Andy!Madison@NetAdmin.StormIRC.org PART #channel
-> irc.StormIRC.org PART #channel
<- :Andy!Madison@NetAdmin.StormIRC.org PART #channel

I don't actually understand all this at all, shouldn't both cases be the same or?

Not really. Clicking the X button is a UI interaction saying you want the window closed. In my opinion that means mIRC should close it ASAP. It's basic useability that the UI should be as responsive as possible. User presses X - window closes. No delays. No "but only if the server agrees". Just close it.

Apparently when you close a channel window, mirc fakes the receipt of a PART message from the server and then sends a PART command to it. From the scripter's point of view, this allows the usage of the on PART event as a form of on CLOSE event for the channel window. The main use of that is presumably the ability to do something like this:
ie to be able to specify a default part message (either global or per-channel/network), sort of like you can specify a default quit message in Options. This way mirc sends two part messages, first the one you specified in the on PART event and then the internal one (which mirc sends anyway). The second PART command results in a "No such channel" response from the server, but mirc hides that message, so the user doesn't notice anything.

I agree that it should not wait for the server to respond. It should first close the window, ignore any server messages pertaining to the parted channel, and then send the part command. I've always assumed this is how it worked.

Originally Posted By: qwerty

The second PART command results in a "No such channel"

Why would that happen when the first is faked? Technically the client would still be on the channel. So, when the window is closed, mIRC would fake the incoming part message triggering the part event, and then issue the part command to the server provided a script has not already done so.

Not sure I'm reading that correctly, but what I said before is that a PART reply is faked (incoming PART message), not a part command (outgoing).

Apparently mirc doesn't check that. If you're asking why not, I can't answer that, but the fact that Khaled chose to hide the "No such channel" message instead of checking whether a script sent a PART command before the internal one probably means that implementing the former was easier.

Edit: as it turns out, mirc doesn't even hide the "No such channel" (or "You're not on that channel") message (thanks Sat)... so implementing nothing is definitely easier :P

I guess what I meant was, why would mirc issue a fake part command. But maybe it would do that for the same reason it would fake an incoming part message from the server. Issue a fake part command so that if there is a scripted part alias, it is used, and fakes an incoming part message so the part event is triggered. I think I have myself confused now.

mIRC doesn't issue a fake part command. It issues a real one after it has faked a part receipt and already closed the channel window.

Yeah that's how I described what I thought happened when I said...

Originally Posted By: RoCk

when the window is closed, mIRC would fake the incoming part message triggering the part event, and then issue the part command to the server provided a script has not already done so.

2 cents from the UnrealIRCd team:

2 cents is about all their IRCd is worth, but they made good points too.

Also note to them that it was users of that "POS client" that were making the comments and giving the opinions, not the creator or the client.

If that's all it was worth, then why do the majority of the servers polled on Search IRC show to be using a version of UnrealIRCd.

In my opinion, the number of servers using Unreal contradicts your statement of it only being worth about 2 cents.

Thanks for the comments, this is just my personal preference... implementing it the other way is easier (and I did try it out many years ago) but I felt more comfortable with the current behaviour. Is there some reason why you would prefer it to behave differently? Is it important?

To put your statistic in perspective: according to the same site, of all 4233 networks, the top 12 combined carry roughly two thirds (66.5%) of the total IRC userbase. None of those networks are using unrealircd.

So, perhaps it's because every idiot and their dog can set up one? Or because its bells and whistles, and in particular its habit of taking away freedom from the user and giving it to IRCops (need I even mention SAJOIN?) are attractive for power hungry kids? I don't know, but none of that automatically means it's not a POS ircd.

Back on topic though.. what could possibly make PART fail anyway?

You'll also note however that none of the top networks use it, including DALnet, Quakenet, IRCnet, EFnet, Undernet, GameSurge, UniBG, Rizon or freenode. Such networks account for around 600,000 users, which is well over 50% of the IRC population as a whole.

I'm not passing judgment here, but its general reputation is that it's used by newbies who are more interested in having lots of IRCop powers, silly amounts of channel levels that extend beyond the basic op/voice/halfop and have little or no experience running a server but want to do it anyway. Despite this however, a few of their developers seem to find it enjoyable being rude/arrogant and so it's not a surprise if their opinion isn't greeted with open arms *shrugs*

As for the "bug report", this is absolutely pointless. The Microsoft comparison doesn't really work, because whilst there are plenty of apps which will ask for confirmation before closing, there are plenty that don't. The decision is based on an individual basis (so Word/Notepad/etc quite obviously should ask for confirmation, IE probably shouldn't). In mIRC's case (in my opinion) the behaviour at the moment is quite correct.

Stealth, your opinion is welcomed, please do not relay further messages from the "unrealircd team" if they can't be bothered to register.

Regards,

It was my opinion, that's all.

I've never seen a failure.

I have however seen delays and message leaking into the Status Window.

All in all though, I'm quite happy for the current behaviour to stay. The occurences of such message leaks are rare (I've seen it twice in the past, what, 11 years?).

This logic is so flawed it amazes me it came from a developer (even an unrealircd one)... When Word gives you a chance to save your documents or mirc asks confirmation to exit, the GUI is being completely responsive. The window doesn't close but another event happens immediately instead: a warning box pops up, informing the user what's going on and asking for further action. This is very different from delaying an action, giving no indication to the user that mirc is waiting for something before it closes the window. To make the distinction even clearer, consider the aforementioned example of mirc asking for confirmation to exit. If the user clicks OK on the confirm dialog box, mirc exits immediately (or almost immediately), ie it doesn't wait for the server to tell it "ok, I acknowledged your quit" before it closes its window. See the difference? Confirmation dialogs have nothing to do with UI responsiveness.

However the above was just to illustrate why confirmation dialogs are a terrible analogy. The actual (and rather perplexing to me) issue is that some people seem to actually prefer experiencing obscure delays in window closing that may last quite a while, depending on network conditions etc. And for what purpose? Does the idea that a channel window might be closed a little while before the client receives the PART reply shock them that much?

I've seen that myself, but I always credited that to lag altho I'm not really sure why it happened. I would quit and a bit later I would see quit messages for nicks that aren't on any common channels but were on the channel I parted. But as you said, in my 10-11 years I've oly seen it less than a handful of times.

Well qwerty's already explained why the UnrealIRCd team's understanding of user interaction is wrong, but here's one simple reason for not waiting for the PART response: There's no need to. The original IRC RFC 1459 doesn't even define a response to the PART command so if mIRC waited for it on RFC1459-compliant servers it would never part a channel. Even in RFC 2812 which does define a PART response it also explicitly states that "[the PART] request is always granted by the server". So there's no reason to wait for it. If a user is on a channel and chooses to part then he will always be able to part it. Any server which tries to prevent it is breaching not only every IRC RFC but also fundamental useability.

Which brings us nicely to UnrealIRCd, which does break all those things with the /SHUN oper command - the biggest disgrace to ever appear in an IRC daemon and yet another reason to see UnrealIRCd as nothing more than an excuse for power-hungry kids to play oper and treat an IRC server as their own personal ant farm. /SHUN serves no administrative purpose and is only there for the oper's pleasure, it's the equivalent of pulling off all an insect's legs and watching it try to crawl around.

With all that said, the day I take useability advice from the UnrealIRCd team is the day Hell freezes over and Hitler and Stalin perform the Nutcracker on Ice on the frozen surface of the River Styx. Outlook today: Not so good.

I do feel this is important, because it is the way parts were meant to work... In the event a part is denied, a user would be unable to reopen the window (the server would deny the join, because the user would already be on that channel)

How can it be the way PARTs were meant to work? PARTs were never meant to be disallowable! And as far as I'm aware the only IRC daemon that attempts to prevent a PART is UnrealIRCd. That's where the fix needs to be made.

Erm... I don't mean to be rude, but have you actually read what other people posted other than Khaled?

Regards,

I did, but then I ignored the ones who posted just to flame an IRCd.

Why? Nobody ignored the unreal ircd team's posting when it simply flamed an IRC client?

The "flame" posts actually give reasonable criticism to certain features of the ircd which seem to be causing the problems you have with this bug.

Regards,

I'm sure some of this has been said already, but I haven't read the whole thread.

Can you name a scenario where a part command will actually fail? I can't think of one unless there's some kind of badly written IRCD playing a part.

Since a part command will always succeed, surely it's beneficial to have the window close instantly, rather than wait until the part receipt is received? I can't see any possible reason why somebody would rather have the window close a second after they hit the button (in the case of high lag, could be even longer), rather than instantly.

That is precisely what the rest of the thread has illustrated. UnrealIRCd has a /shun ability which apparently means the server ignores all commands from a particular client, effectively trapping them on the network. So, if you've been shunned, /part is ignored. So the way I see it is, certain people want to prevent shunned users from closing their windows. Need I say more?

Regards,

Ah.

Do UnrealIRCd's announce the 'SHUN' ability in an 005 (or something)?

If so, more dodgey-ircd-dependent code could be made..

While being shunned disables most commands from a client, /quit and /exit do still work. I thought /part worked as well, but I've been unable to find confirmation of this, one way or the other.

Well then whoever wrote the unrealircd documentation doesn't know what the meaning of the word "ANY" is.

"Prevents a user from executing ANY commands and prevents them from speaking."

To me, /part would be included in this.

Edit: There seems to be a setting ("set::options::allow-part-if-shunned;") that allows users who are shunned to still /part. I would imagine the default setting is that a user can't.

Regards,

Answer to my own question: According to the source, No.