On Thu, Oct 22, 2009 at 12:41 AM, Jason Hill <secrtagnt@gmail.com> wrote:
On Wed, Oct 21, 2009 at 6:14 PM, James Hess <mysidia@gmail.com> wrote: How is faking quit/reconnects a bad idea, especially when such an implementation is not even that complex? Making zero assumptions seems
It does not do anything for assumptions a client makes about its own hostmask. What about IRC clients that resolve their own IP address, and assume the server came to the same conclusion about their hostname? Faking quits/reconnects generates an excessively wasteful amount of IRC traffic. Consider how many messages would be generated when a user who is joined to and opped on 3 channels turns on masking, and each channel has 25 members. At a bare minimum, all people joined to the 3 channels will each need to receive 3 messages, a "PART", "JOIN", and "MODE" message. It may also have other unwanted effects, such as triggering other users' ON-JOIN or QUIT scripted actions: e.g, the user may have to re-authenticate to on-channel bots due to the simulated quit, they may lose places in games, etc. This type of spam is annoying, and 2 or 3 broadcast channel messages for one action is a significant waste, unless it is absolutely essential, it should not be done. IRC is a chatty enough protocol, without coming up with reasons to generate more messages to clients.
worse than at least making some "artificial" assumptions that do actually hold true in some use cases. The reason why such host cycling
"It's dark outside" holds true in some use cases. Some people/devices might have been lead to assume it would always be dark. But that doesn't mean a "sun" can't be introduced without simulating a destruction and instantaneous re-creation of all people on earth.
was added in ircu (and other ircds), for example, is because it has been shown that some clients and scripts assume a user's address can never change without the user quitting and returning. Perhaps that assumption is flawed, but it is what is. At least cycling helps ensure their address lists stayed syncd.
The simple fact is... the _very_ small number of clients and scripts that assume that, can be allowed to keep on their way with their flawwed assumption. Even when the assumption is wrong.. there can be made to be no impact in almost all cases, the "brokenness" is non-fatal. Synchronizing wrong data is a non-issue, when the synchronization doesn't even matter. With static masking, which version of a host a script bans or SILENCEs is not an issue. It basically only leaves hostmask based access lists. Which have another issue.... ( access list entries created before masking existed are now obsolete ) -- -J