Client <-> Server Desynchs

These are old archives. They are kept for historic purposes only.
Post Reply
aquanight
Official supporter
Posts: 862
Joined: Tue Mar 09, 2004 10:47 pm
Location: Boise, ID

Client <-> Server Desynchs

Post by aquanight » Wed Mar 10, 2004 12:06 am

Okay, I know this should be posted in the bug tracker, but I seem to have lost my password :roll: (confusing system), so I'm posting it here.

It has become clear that there are two situations that occur in which a client becomes out of synch with the server. Unfortunately, I believe that this is the fault of the ircd, because the connection between the two was over 127.0.0.1 (so not a connection problem :) ). Allow me to explain:

Desynch #1: User Mode Flags
Problem: User Bob, connected to my.irc.net with services at services.irc.net, registers to NickServ. In response, NickServ sends the command :NickServ SVSMODE Bob +r 123456780. Unfortunately, Bob never hears about the Mode change because UnrealIRCd neglected to update him with a :NickServ MODE Bob +r or similar. Bob is now out of synch with the server.
Cause: UnrealIRCd is not properly updating the affected client of the mode change that was invoked via SVSMODE.
Remedy: Bob can type '/mode Bob' to receive an RPL_UMODEIS showing that he has the +r usermode. This shouldn't be necessary.
Solution: When UnrealIRCd finds (and accepts) an SVSMODE command, it should distribute an appropriate MODE command not only to all servers, but to the affected client.

Desynch #2: Channel User Status Desynchs
Problem: Users Bob and Joe, connected to my.irc.net running services at services.irc.net, are on #Test. Bob decides to register the channel. ChanServ, in response, sets Bob +q. He then SOP's Joe and asks him to hop to affect the changes. Joe does so and gets set +ao on join by ChanServ. Now Bob decides to go afk and sets -q on himself. But now a problem appears:
Bob's name list: @Bob, &Joe
Joe's name list: &Joe, Bob
Not only is Joe desynched with Bob, he is desynched with the server, which will become evident as soon as Bob performs a chanop only command (we'll assume neither is an SA). The reason for the desynch? Joe relied on the NAME list when he hopped to get Bob's state. Since his client wouldn't know what happened during the hop, it can't use prior information.
Cause: UnrealIRCd's NAME list doesn't properly handle users with multiple channel statuses.
Remedy: Joe can fix the desynch by hopping or re-requesting the NAMES list. But what if the server could make this unnecessary...
Solution: A technique I like to call 'OpSynch' which works like this:
When Joe rejoins from the hop to check the SOP, the following appears on Joe's client:

Code: Select all

#Test Joe Bob
#Test End of /NAMES list.
* Now talking in #Test...
* ChanServ sets mode: +ao Joe Joe
* OpSynch (OpSynch@my.irc.net) has joined #Test.
* OpSynch sets mode: +qo Bob Bob
* OpSynch (OpSynch@my.irc.net) has left #Test.
Now Joe sees Bob's proper mode state, and when Bob unsets the q flag, Joe still sees him as having the o flag.
All Bob saw, however, was:

Code: Select all

* Joe (Joe@MyNet-123.someisp.com) has joined #Test.
* ChanServ sets mode: +ao Joe Joe
Basically, when a user has more than one channel status, the NAMES list is changed:
1) In the NAMES reply, report the user as having no status at all.
2) After the RPL_ENDOFNAMES, make OpSynch join the channel. Send a JOIN command for OpSynch only to the user that is requesting the NAMES list. Then send MODE commands updating the users modes.
3) After the job is done, send a PART for OpSynch.

This could be enabled via set::options::enable-opsynch; which would automatically Q-Line OpSynch.

codemastr
Former UnrealIRCd head coder
Posts: 811
Joined: Sat Mar 06, 2004 8:47 pm
Location: United States
Contact:

Post by codemastr » Wed Mar 10, 2004 12:11 am

Ok, first off, any future bug reports here will be ignored. If you forgot your password, you contact someone to have your password retrieved.

Next. The thing with SVSMODE is not a bug at all. The services choose to not have it send the +r. If they wanted to have it shown, then they'd use SVS2MODE which does show it to the user. If you don't like the way services does it, contact the people who write the services.

Next thing. The "+ov" bug has been known since IRC was first created. It's not an Unreal problem, it's an IRC problem. Your suggested fix is definately NOT going to be used as it is incredibly wasteful. You don't work around a broken feature, you fix the feature. The proposed "HANDSHAKE" protocol along with the "NAMESX" protocol will correctly solve this problem once it is made an RFC.
-- codemastr

penna
Posts: 12
Joined: Tue Mar 09, 2004 5:50 am
Location: Germany

Post by penna » Wed Mar 10, 2004 6:42 am

codemastr wrote:Ok, first off, any future bug reports here will be ignored. If you forgot your password, you contact someone to have your password retrieved.
or just make another account. i even now have 3 different accounts :D

eQuiliBrium
Posts: 40
Joined: Sat Mar 06, 2004 9:42 am
Location: Netherland (Amsterdam)
Contact:

Post by eQuiliBrium » Wed Mar 10, 2004 10:33 am

Hello,

I agree with codmastr.
I dont thing that what you have writen above is a dysnch problems.
There are many ways of getting in dysnch with the server.
Just a small lag will throuw you out of synch :)
But in that case its not a problem with the server, but with your IPS/computer.

With the dysinch of usermode's, i totaly dont agree.
After a usermode change via svs cmds(that is given throught RAW) the server <--> client will not go out of dysnch.
Many mode changes are given via RAW like identifying to chanserv on difrent channels.
This is perhaps one synarion that we might have to remember but not a dysnch problem.
Let me think about it

penna
Posts: 12
Joined: Tue Mar 09, 2004 5:50 am
Location: Germany

Post by penna » Wed Mar 10, 2004 10:42 am

i don't think any irc client must see a mode change for +r user mode
if you identified correctly nickserv sends always a notice to you. and then you know that you have +r if you configured your u:lines right. there is no need that on svsmode it shows the mode changes. if you really want to see +r umode changes then either complain at your services developers or change the svsmode to svs2mode yourself in the source.

aquanight
Official supporter
Posts: 862
Joined: Tue Mar 09, 2004 10:47 pm
Location: Boise, ID

Post by aquanight » Wed Mar 10, 2004 2:38 pm

True, but on servers I've seen (running other IRCds) that use services, they've always updated your mode flags. I guess I'm used to that and thought that by not doing so, unreal might have had a bug in it or something (because I first saw this with the beta and figured, well, it's beta!). I guess I thought this was a problem and come to find it's by design :roll: .

:oops:

aquanight
Official supporter
Posts: 862
Joined: Tue Mar 09, 2004 10:47 pm
Location: Boise, ID

Post by aquanight » Wed Mar 10, 2004 6:34 pm

Oh, and before I forget...
codemastr wrote:If you forgot your password, you contact someone to have your password retrieved.
... who and where?

codemastr
Former UnrealIRCd head coder
Posts: 811
Joined: Sat Mar 06, 2004 8:47 pm
Location: United States
Contact:

Post by codemastr » Wed Mar 10, 2004 6:48 pm

If you give me the login name, I'll tell it to reset your password.
-- codemastr

aquanight
Official supporter
Posts: 862
Joined: Tue Mar 09, 2004 10:47 pm
Location: Boise, ID

Post by aquanight » Wed Mar 10, 2004 11:37 pm

It should be the same as here...

Post Reply