Този документ ще се опита да опише както TS така и Delay идеята в един обективен маниер. Тей като повечето хора знаят, че аз не обичам TS, помолих няколко човека да прочетат този документ и да ми помогнат да го направя до колкото се може по-обективен.
Защо?
И двете (TS и Delay)
се опитват да решат широкото разпространените проблеми в IRC 2:
TS
TS идва от TimeStamp.
Протоколът е напълно описан от Roger Espel Llima,
неговият създател. Добавен е от Крис Бееренс и Шриари Пандит към
техните собствени сървъри.
Забележка: Delay идеята за псевдонимите бе първо представена в така нареченият E1 patch (за 2.8.21) и все още НЕ е част от кода на версич 2.9.
Следното описание не претендира да бъде пълно. Намерението на
този документ е да представи материали за някои, които искат да решат кой метод
да използват, ако има такива.
Важно е да се забележе, че има два аспекта на този проблем:
Това просто сравенение обеснява защо Delay
често е считано за дразнещо, докато за TS е казано, че е
транспарентен, но аз намирам това като слабо възражение:
Двете са 'транспарентни' за потребителA,
защото той не разбира, какво става.
Нито едно не е 'транспарентно' за потребителB,
защото и в двата случая, нещо неочаквано се случва в резултат на това, че той се
опитва да си смени псевдонима на псевдонимаA. За TimeStamp
това е kill-а. За Delay на
псевдоними това е, че на потребителя не му е разрешено да си смени псевдонима.
Зависи от ситуацията:
(Псевдоним) Delay-а се опитва да защити
всички, докато TimeStamp
се опитва да защити само "законния" потребител.
Забележка: Подобен пример може да
бъде направен и с канали.
В примера по-горе, TimeStamp дава повече
информация, от Delay на псевдоними:
смяна на псевдонима и евентуална колизия на псевдонима на всеки
сървър от страната на split-а.
Мрежата, която ние познаваме, има дълга история и много ``всепознати
правила''. Доколкото си спомням, винаги се казваше "псевдонимите
и каналите нямат собственици".
Лесно е да забележеш подобно нещо на мрежа, където колизиите и
takeover-ите са обикновенно нещо. С TimeStamp
или Delay, нещата се променят, и каквото
беше ясно преди, вече не е чак толкова ясно.
Проблемът е, че TimeStamp решава, кой е
законния потребител и логиката използвана от TS има още
много да се тества и да се доказва (прочетете по-долу, за дългите разделяния на
мрежата и TS примерно). С delay patche-овете,
никакъв избор, по този начин и никаква грешка никога не е била
допусната, но понякога, ще допусне конфликт да се получи.
Сега е по-лесно да се разбере, че когато TimeStamp
направи 'грешното' решение, потребителят, който е бил "наказан"
и който е бил "прав" ще се нуждае
или поне ще очаква
някой/нещо да поправи грешната ситуация. Това води до нуждата от
``services''.
Channel service, както се знае на другите IRC
мрежи е нещо, което съвсем се различава от отдавна установеното
правило
"каналите нямат собственик" и ще
бъде голяма промяна за мрежата. Това е едно от основните неща, поради които
хората са против TS, защото, както бе започнато по-горе,
това скоро води до
"Сега, когато имаме TS, се нуждаем от
channel service".
Цитирам Дъг М'кларън, който говори за delay
на псевдоними:
Няма нищо, което да спре `lag-killer
ботовете'. Този бот оставя две връзки отворени - една на
вашият сървър, и още една на отдалеченият. Също стои и в каналите, в които сте и
вие. Веднага щом ви види да си сменята псевдонима чрез своята локална връзка, то
сигнализира на отдалечената връзка и се опитва да вземе същият псевдоним. Двете
промени на псевдонима биват срещнати някъде по средата, и вие бивате
kill-нат.
TimeStamping-а не рашава и този проблем.
То ограничава злоупотребата, защото `lag-killer бота'
трябва да е бърз, но това същност не е проблем.
Роджър Еспел Лима казва: нито една от
двете не се справя с тях изцяло: TS ги оставя с шанс за
успен около 50%;
с ND те винаги са осъществими.
Веса Руконен отговаря: Delay на
псевдоними не прави злоупотребата винаги осъществима. С него, kill-а
може да стане само веднъж (на дадения псевдоним), след това псевдонима бива
заключен, и бота не може да продължи да се опитва да си смени псевдонима, както
става при TS.
Цитирам Дъг М'кларън, който говори за delay
на псевдоними:
Същото се отнася и за наскоро /restart-ирани
или стартирани сървъри. Този случай е малко по-различен, защото ако C/N
линиите на сървъра са правилно сложете, той ще започне да се свързва към своя
ъплинк веднага, давайки само няколко секунди на colliders
да се свържат, преди свързването към мрежата.
Предполагам, че клиентската връзка може да бъде delayed,
в този случай. Но не виждам лесен начин за направата на това,
както и не се знае дали сървърът е свършил своята връзка към ъплинка си.
Цитирам Дъг М'кларън, който говори за
delay на псевдоними:
Няма с какво да се спре сървър, който е разделен за повече
от 15 минути да направи колицизия на псевдоним. Ако един
клиент на този сървър започне да си пуска псевдоними, за всички потребителски
псевдоними, които той иска да kill-не, тогава след като
сървъра се върне на мрежата, това може да доведе до доста колиции на мрежата.
Това е почти вярно. Но както ще прочетете по-долу, сървърите не
трябва да се разделят за толкова дълго време (поне не много често). Разбира се,
че може да се случи..
Цитирам Дъг М'кларън, който говори за delay
на канали:
Ако сървърът е разделен от мрежата за повече от петнадесет
минути, всички delay-и на канали ще изтекът, и
потребителите ще имат възможност да хакнат операторския статус за всеки канал,
който си искат, като се има предвид, че няма никой в този канал на този сървър.
Прекъсването на електроснабдяването на мрежите и машините често
е повече от 15 минути...
Има три неща, които мога да ти отговоря по този въпрос.
Първо, в текущата си версия, delay-а на
канали не изтича след петнадесет минути на сървър, който е 'напълно' разделен от
мрежата. В подобен случай това би отнело повече.
Второ, наистина не знам как планираш да злоупотребиш на сървър,
който не недостижим. Ако има прекъсване на електроснабдяването на мрежата, само
локалните потребители ще могат да злоупотребят, като се има предвид, че те няма
да виждат другата част от мрежата, те ще действат само
върху определени ``мишени''.
Най-накрая, ако сървър, или част от мрежата е разделена за дълго
време, моето лично мнение е, че не трябва изобщо да е свързана към мрежата.
Според мен, TimeStamp също има проблеми с
дългите splits. Ще взема за пример TimeStamp
за псевдоними, но същото мнение може да се направи и за канали.
Нека да приемем, че двата сървъра са разделени за дълго време.
Тогава, двама потребителя могат да ползват един и същи псевдоним, за
неопределено време и само един ще бъде kill-нат при
връзката на двара сървъра. Мисля, че няма как да се разбере, кой е правноправния
претежател.
Това може да довете до kill-ването на
потребител, който обикновенно си ползва псевдонима (ако той си е рестартирал
клиента, или си е сменил псевдонима поради някаква причина).
Вероятно трябва да прочетете това отново, защото има много важни
неща, които по-скоро са скрити от големината. Опитах се да адресирам всички
предназначения, всички имат различно значение, но това е доста субективно.
Най-важното нещо, което трябва да знаете и да помните е, че
която и идея да изберете тя нама да бъде ИЗЦЯЛО ефективна, ако не е на
цялата IRC мрежа.
Благодаря на следните хора за това, че прегледаха документа и
дадоха своето мнение за него:
Кристофър Калт <kalt@stealth.net>
Двата аспекта се различават и
не трябва да се бъркат.
TS идеята
Псевдоними
TS сървъра знае, кой от двата псевдонима на клиентите е
по-скорошен. Така е възможно за него да разбере, кой от двата клиента
трябва да kill-не.
Това предпазва старият потребител
от преднамерена колизия на псевдонима.
Канали
Както за канали, за TS сървъра е възможно
да разбере, кой оператор в канала е най-младият (за всеки канал). Това прави
премахването на операторския статус на потребители, които може би използват
разделянето не мрежата за да получат операторски статус.
Технически бележки
Delay идеята
Псевдоними
Сървър с delay на псевдонимите, предпазва
потребителите и те не могат да ползват скорошно използвани псевдоними, ако
псевдонима е бил на разделен от мрежата сървър или е бил kill-нат.
Канали
Сървър с delay на канали, не позволява на
потребителите да влизат в канали, които скоро са останали без операторски
статус, поради разделяне на мрежата и които са празни(влизането на потребител в
канал е винаги разрешено стига той да не е празен).
Технически бележки
Просто техническо сравнение
Delay използва паметта за Delay на
псевдоними (близо 400Kb за 25K
потребителя). Delay за канали използва
около 0.
Политически предназначения
Проблемите
Това прави броя на потенциалните злоупотребители доста
ограничен.
Последни бележки
Вярвам, че този документ дава доста пълно описание и на двете
идеи. Целта сега е вие да мислите и да решите, кое предпочитате повече.
Но вие трябва да избистрите съзнанието си и да измислите това сами (забравяйки
какво и да сте чули до момента).