mIRC Homepage
Posted By: Wims /exit and quit message - 06/03/15 09:24 PM
It seems to me, I didn't check, earlier versions of mIRC would properly issue a QUIT message to all server you are connected on when using /exit.
In current version, using /exit seems to exit the application too early, without allowing the sockets to send their data, resulting in quit message such as "Client exited" or "Connection reset by peer".
Posted By: Khaled Re: /exit and quit message - 07/03/15 08:20 PM
Thanks for your bug report. mIRC always sends a QUIT when a server connection is closed. This can be confirmed by using /debug on to output to a debug.log. However:

When you use /quit, mIRC will wait until the server closes the connection.

When you use /disconnect, mIRC will detach the socket connection from the status window and will keep it open in the background for a few seconds waiting for the server to close the connection, which may or may not happen depending on the network state. In one version of mIRC, this was changed to behave like /quit, so that a /disconnect would only complete once the server closed the connection, however many users complained about the delay and it was reverted and the current behaviour was implemented.

When you use /exit, mIRC closes all sockets immediately, so a QUIT may or may not reach the server. There is no way of ensuring that QUIT has reached the server after an /exit without keeping mIRC open for several seconds, ie. blocking the mIRC GUI to prevent further input or hiding mIRC in the background, in the hope that all servers you are connected to receive the QUIT and close the connection, which may or may not happen since it will depend on the network state. It is questionable whether mIRC should be forced to stay open in such a situation, as the user has explicitly asked for mIRC to exit.
Posted By: Wims Re: /exit and quit message - 07/03/15 09:15 PM
Well, I guess /disconnect shouldn't wait since you have /quit if you want to wait and get the quit message sent properly.. But as far as /exit is concerned, there is no mention that mIRC will use /disconnect or /quit (really, their underlying behaviors) on connected server when /exit is involved, your reply says
Quote:
When you use /exit, mIRC closes all sockets immediately, so a QUIT may or may not reach the server. There is no way of ensuring that QUIT has reached the server after an /exit without keeping mIRC open
But are you even sending a QUIT message when we use /exit? If you are, it's pointless if you purposefuly close the sockets right after confused .
Note that this has nothing to do with /disconnect or /quit, it's really what /exit does which changed in behavior, before it would always get the quit message sent correctly, or was that just luck? I doubt it was.
I think that /exit should do a clean quit (/quit), first because it was the behavior for year (or so it seems, again I don't recall /exit ever ending up with QUIT messages not sent properly), but also because it makes more sense imo, there is simply nothing wrong with mIRC issuing QUIT messages, hidding/deleting the UI and only close once there are no more data to send on the socket(s). Currently, when you exit, it seems to the others users your internet connection is broken or that mIRC crashed when you just exited the cleaniest way possible, suggesting we should use /scid -at1 quit | exit if we want that (old) behavior is a bit ridiculous imo!
If this isn't going to change I think /exit should definitely get a new switch to issue /quit on those connected server.
Posted By: Khaled Re: /exit and quit message - 08/03/15 09:36 AM
Quote:
before it would always get the quit message sent correctly, or was that just luck?

Yes, it is luck. It depends entirely on the network state. If Windows is able to send the message immediately, it does. If there is a network delay for whatever reason, it does not. The same happened with the old /disconnect method, where mIRC would close the socket immediately. Sometimes the server would receive the QUIT message, sometimes it would not. Even with the new method, where mIRC keeps the socket open in the background for a few seconds, this may not resolve the issue since it may take more than a few seconds for the message to be received by the server depending on the network state.

Quote:
I think that /exit should do a clean quit (/quit), first because it was the behavior for year

When exiting, either through using /exit or Exit through the menu, mIRC has always sent QUIT and exited immediately.

Quote:
(or so it seems, again I don't recall /exit ever ending up with QUIT messages not sent properly)

This has always been the case.

What you are requesting is: if mIRC has server connections open and you try to exit mIRC, you want mIRC to not exit immediately but instead to remain open, freeze the GUI to prevent further input, and wait for confirmations from all open server connections that they have received your QUIT message. Note that this could take anything from a second to several minutes, depending on the network state, server lag, and so on. I could make it so that mIRC only remains open for five seconds at most, however that is still no guarantee that the server will receive the message.
Posted By: Wims Re: /exit and quit message - 08/03/15 11:29 AM
Luck or not, in practice, the quit message was always seen by the IRC server, I just tested it with mIRC 6.35, I can reproduce 100% of the time (ok I'll admit that might not be a sign of anything since I'm probably not having any problem with my network, but the tests shows mIRC 6.35 doesn't behave the same, consistently, nonetheless) it will, somehow, wait for the message to be sent on the socket before exiting.
Since there is no documentation that exiting (even manually) the application will do X or Y, I think it's normal for people to assume the behavior being there for years is the correct behavior (you often go that way), and the behavior to be seen was that the QUIT message was sent correctly.

Quote:
What you are requesting is: if mIRC has server connections open and you try to exit mIRC, you want mIRC to not exit immediately but instead to remain open, freeze the GUI to prevent further input, and wait for confirmations from all open server connections that they have received your QUIT message. Note that this could take anything from a second to several minutes, depending on the network state, server lag, and so on. I could make it so that mIRC only remains open for five seconds at most, however that is still no guarantee that the server will receive the message.
Yes, although I'm not sure you need to wait anything from the server, just wait for the sending queue of the socket (mIRC-wise, $sock().sq) to be 0 (if that's what you meant with "confirmations from all open server", nevermind then). I'm good with "waiting 5 secs at most", you could make that 3 secs even, in my opinion. I really think it's normal for an application like mIRC to wait for the QUIT message to be sent, at least I think mIRC should offer that possibility for users who can afford to wait 2 secs when exiting. I'd be good if the default was to exit right away and a new options in alt + o and a new switch for /exit was added
Posted By: Khaled Re: /exit and quit message - 08/03/15 12:01 PM
I am sorry but no, in practice the message was not always seen by the server. On exit, mIRC v6.35 sends the QUIT message, closes the socket, and exits immediately, in the same way as mIRC v7.41, and no versions of mIRC have ever, on exit, waited for the message to be received by the server.

Also, please note that this has nothing to do with the send queue. The send queue is empty. It it is the underlying operating system and network transport that is the cause of the issue. You can find a technical explanation here.

As I mentioned, many users disliked the /disconnect delay when it was added in an older version, that is why it was reverted. It is very likely that users will equally dislike trying to exit mIRC and finding that it just hangs around for five seconds. And even this would not guarantee that the server receives the QUIT message - the only way to guarantee it would be to wait as long as it takes to receive a message back from the server, which could be anything from a second to several minutes. So I am not inclined to add support for this. I will however add it to my to-do list and may look into it in future.
© mIRC Discussion Forums