Progs wrote: >Hi, > >If I have two servers, AA and AB, with AAAAA and ABAAA on #foo, a +D channel. >AAAAA is delayed on #foo and ABAAA is +d. >There are only AAAAA and ABAAA in #foo. >When AAAAA speaks on #foo, ABAAA is +d so AB doesn't receive message, so ABAAA >doesn't see AAAAA's join. > >Bug or feature ?:) > > This could be used to build a map of the network and determine where the hubs are. Anything which breaks HIS that bad is a bug.
There are several fixes: Fix A: We need to globally synchronise delayed state, which means that we need to transmit it in BURST. We can then apply the "don't propagate WASDELAYED" because we can track delayed state in each server. Finally, if a message causes RevealDelayed, it should propagate to all servers, not just those with non-deaf members on the channel. Fix B: Deaf users can't join +D or +d channels, and users in +D or + d channels can't become deaf. Fix C: Deaf users joining a +D or +d channel force a full reveal to everyone on that server(I think we can rule this one out) Fix D: Deaf users joining a +D or +d channel can see everyone, and can't set -d usermode(to prevent seeing the same join twice, when RevealDelayed is called) while in channel. Fix E: Deaf users joining +D or +d channel get a full reveal, and if they set -d, we set WASDEAF on all +D or +d channels they are in. Users with Deaf usermode or WASDEAF status in the channel do not see messages sent by RevealDelayed as they have already seen them earlier. They do see parts for delayed users. How many users set -d once they are connected anyway? Probably not many, so fix D might be reasonable. Fix A requires a server protocol change(and costs extra bandwidth on burst). In the light of the bandwidth problems with A and C, and the feature restrictions of B and D, only E remains(or G, "do nothing" :) ). Opinions? _______________________________________________ Coder-com mailing list Coder-com@undernet.org http://undernet.sbg.org/mailman/listinfo/coder-com
