UnrealIRCd Forums

As the prefix "[Technical]" says, this question is rather directed to developers and advanced users of UnrealIRCd. A similar one has already been raised by aquanight earlier, but it remanied unanswered due to a topic lock.

I'm looking for a reason that certain SVS commands return an acknowledgement (or whatever it is) to the sender, while others not.

To show an example, if an U:lined server issues a well-parametered SVSNICK, a NICK message is sent back. The same is done with, for example, SVSJOIN and SVSPART. However, Unreal silently accepts commands like SVSKILL from the sender. I know the advantages of reducing server traffic like that, but could someone tell me why Unreal servers send replies for some SVS commands? Especially in case of SVSPART, shouldn't Services programs just assume that the result of the command was successful?

Thanks in advance.

That's not all:

Send: SVSO aquanight -
Receive: :aquanight MODE aquanight -oandwhateverotherflags

I can understand why somethings that only have a real effect on a local server (such as snomask change) wouldn't be sent, but stuff that get sent between servers (QUITs JOINs PARTs MODEs NICKs etc)... yeah ;p .

Well, for SVSNICK the reason is simple. There is no guarantee an SVSNICK will succeed. If Services tries to change the nick to, for example, &&&test&&& the SVSNICK will fail. So the only way for services to know if the SVSNICK was accepted is to receive a NICK. The same is true for SVSJOIN. If the channel is, for example, +l, the SVSJOIN fails. Hence, services does not know if the user joined other than by receiving a JOIN. SVSPART, well I guess we just thought it'd be confusing if SVSJOIN send a JOIN but SVSPART didn't send a PART.

Now on to why the command you mentioned doesn't do this. SVSKILL always succeeds. As long as the user is online, and you are a U:line, the user is killed. And, if the user is not online, you should probably still remove it from your user list since you are desynced. So there is no need to send a KILL.

I hope that clears it up?

codemastr wrote:Now on to why the command you mentioned doesn't do this. SVSKILL always succeeds. As long as the user is online, and you are a U:line, the user is killed. And, if the user is not online, you should probably still remove it from your user list since you are desynced. So there is no need to send a KILL.

Well, I would think it'd be QUIT if that were the case, but since it isn't, it doesn't matter .

codemastr wrote:I hope that clears it up?

That still leaves SVS[2]MODE. I know SVS[2]SNO isn't acknowledeged because snomasks aren't sent between servers, but usermodes are.

This also leaves these commands as un-researched, though I'm sure someone with telnet (maybe I'll check it out later ) can find out...
SVSWATCH (But IIRC WATCH changes aren't globally announced)
SVSNOOP (other than opers being -o'd, if they are at all?)
SVSSILENCE (but IIRC SILENCE changes aren't globally announced)
SWHOIS
SVSMOTD
SVSLUSERS
SVSFLINE
TSCTL SVSTIME (NOTE: this isn't listed under /helpop ?svscmds! I believe I've already mentioned to codemastr in the chatroom that this can cause confusion, but I don't really see any better alternative. )

*edit* Naturally, that list is going off of what has already been posted . I'm sure coders and people who read the source already know all the answers here ;p . */edit*

I'm pretty sure SQLINE, UNSQLINE, and SVSNLINE are probably acknowledged by an appropriate TKL command (which no services I know of other than Auspice and maybe IRCServices seem to recognize).

Ok after telnetting a bit, NONE of those sent any form of message back to services.

Also, SVSFLINE appeared to have no visible effect at all (checked /stats denydcc, and didn't see the added filemask...), but that's another story.

SVSSILENCE sent a SILENCE change notice to the user effected, and SVSMOTD did send server notices indicating the effect but services still recieive no notifcation at all.

Everything else had a visible effect if you looked in the right place (for example, /LUSERS after an SVSLUSERS, or /WHOIS after SWHOIS). Though SVSWATCH I couldn't verify since the real WATCH syntax does not appear to be documented anywhere.

I didn't try SQLINE, UNSQLINE, or SVSNLINE, so if anyone else wants to confirm my thoughts there, go for it... I also didn't try TSCTL SVSTIME... yet.

(I really think an SVSNOOP ought to -owhatever any opers on the server... maybe I'll put that on the bugtrack for you guys to play with .)

Here's a slightly off-topic addition:

Why do we have SVSMODE, which changes modes but doesnt return them to clients, and SVS2MODE, which changes modes and DOES return them to clients.

If anything, imho, the way these two work should be reversed, since most IRCds use SVSMODE to change modes, and return (don't they?) which would be "keeping standards" of a sort.

To codemastr: yes, your explanations were quite clear to me, thank you.

To w00t: specifically IRCServices uses SVSMODE to set +r on clients with registered nicknames transparently (by hiding the mode change from the client). I can think of two reasons for that: the main purpose is probably that many people don't know what +r is, it can make them confused; and they can get their modes at any time with /mode. What I'm saying is only one example, hopefully it helps.

Actually, it was discussed on the ircservices mailing list quite a while ago-- everyone except andrew (that I can remember) wanted to use SVS2MODE, so as not to cause a client -- server desync which again, imho is a really BAD thing.

Yes, and some people DO want to see whether or not they have +r...

For example, I have an auto-identify script that uses the notify list to see when NickServ comes online, and when it does, the script sends a mode request (because the modechange is hidden on Unreal servers ) then waits one second for a reply, and if I'm not +r, sends the identify. That script would be so much simpler if usermodes were simply sent to me, instead of me having to request an update...

w00t wrote:Actually, it was discussed on the ircservices mailing list quite a while ago-- everyone except andrew (that I can remember) wanted to use SVS2MODE, so as not to cause a client -- server desync which again, imho is a really BAD thing.

I was the one who started that whole discussion off

Andrew turned it down for the same reasons that AngryWolf mentioned.

If services wants the +r to be seen, it has that feature available. However, I'm not going to force them. There is obviously a reason that they do not want it to show otherwise they'd have switched to SVS2MODE long ago.

Um... isn't Unreal the only IRCd that even has SVS2MODE? If so, then that's probably why they haven't switched because there's really no point... SVSMODE works just as well, and it's what every other IRCd has been using (and they show the changes ;p ).

My thoughts exactly aquanight.

Code, I can see the point, it's just imho the behaviour should have been reversed. Anyhow, not to worry.

Um... isn't Unreal the only IRCd that even has SVS2MODE?

No, in fact, we got the idea from PTLink IRCd.

If so, then that's probably why they haven't switched because there's really no point...

Well, I disagree. Why do they support tokens? Nickv2? Umode2? etc. The "standard" alternatives work, and all those options are Unreal only. Yet, they still support them. IRCServices especially has protocol modules, so making it use SVS2MODE on Unreal should be as simple as adding a character.

SVSMODE works just as well, and it's what every other IRCd has been using (and they show the changes ;p ).

Well if by "every other IRCd," you mean, "Bahamut" (and the Bahamut clones), then yes. Otherwise, no. Unreal took its SVSMODE command from Dreamforge. It works just like it does in Unreal. And you'll notice, IRCServices does still support DF, so not even all the IRCds used by IRCServices show the mode change!

Hm... so then the SVSMODE <-> SVS2MODE thingie predates UnrealIRCd... it would be nice to know the original reasoning this was added (in whatever IRCd first introduced it ).

*edit* Also:

codemastr wrote:

If so, then that's probably why they haven't switched because there's really no point...

Well, I disagree. Why do they support tokens? Nickv2? Umode2? etc. The "standard" alternatives work, and all those options are Unreal only. Yet, they still support them. IRCServices especially has protocol modules, so making it use SVS2MODE on Unreal should be as simple as adding a character.

TOKEN vs. normal commands = Saves bandwidth. (Though last I checked with debugging/etc, Auspice (EW!) is the only one I've seen that supports tokens. Dunno about IRCServices.)
NICKv2 = Saves bandwidth by not needing multiple commands.
UMODE2 = Saves bandwidth. (Haven't seen a service package that uses this though .)

Of course, those gains are only majorly effective when services are on a seperate machine, in which case, it would also help to have ZIPLink and SSL support , yet no services I've seen have those either.

SVS2MODE = uses slightly more bandwidth (yeah like 1 byte makes a big difference ;p ), and the smaller alternative works just as well, if not for the strange side effect. (To be honest, it's more confusing to me to NOT see the mode changes...)