Последните промени по този документ са направени на 12ти Юни 1996.

Този документ ще се опита да опише както TS така и Delay идеята в един обективен маниер. Тей като повечето хора знаят, че аз не обичам TS, помолих няколко човека да прочетат този документ и да ми помогнат да го направя до колкото се може по-обективен.

  1. Какво е предназначението на тези идеи?
  2. Резюме за двете идеи
  3. Техническо сравнение
  4. Политически предназначения
  5. ``Проблемите''
  6. Последни бележки

Защо?

И двете (TS и Delay) се опитват да решат широкото разпространените проблеми в IRC 2:

TS

TS идва от TimeStamp.
Протоколът е напълно описан от Roger Espel Llima, неговият създател. Добавен е от Крис Бееренс и Шриари Пандит към техните собствени сървъри.

Delay

Delay идеята е добавена към версия 2.9 на официалния IRC server. Тази версия е все още бета. Все още не е документирана (от 96/06/06).

Забележка: Delay идеята за псевдонимите бе първо представена в така нареченият E1 patch (за 2.8.21) и все още НЕ е част от кода на версич 2.9.

Следното описание не претендира да бъде пълно. Намерението на този документ е да представи материали за някои, които искат да решат кой метод да използват, ако има такива.

Важно е да се забележе, че има два аспекта на този проблем:

Двата аспекта се различават и не трябва да се бъркат.

TS идеята

Псевдоними

TS сървъра знае, кой от двата псевдонима на клиентите е по-скорошен. Така е възможно за него да разбере, кой от двата клиента трябва да kill-не.
Това предпазва старият потребител от преднамерена колизия на псевдонима.

Канали

Както за канали, за TS сървъра е възможно да разбере, кой оператор в канала е най-младият (за всеки канал). Това прави премахването на операторския статус на потребители, които може би използват разделянето не мрежата за да получат операторски статус.

Технически бележки

Delay идеята

Псевдоними

Сървър с delay на псевдонимите, предпазва потребителите и те не могат да ползват скорошно използвани псевдоними, ако псевдонима е бил на разделен от мрежата сървър или е бил kill-нат.

Канали

Сървър с delay на канали, не позволява на потребителите да влизат в канали, които скоро са останали без операторски статус, поради разделяне на мрежата и които са празни(влизането на потребител в канал е винаги разрешено стига той да не е празен).

Технически бележки

Просто техническо сравнение

  1. Като първа бележка, нито едно от двете не спира както колизиите на псевдонимите, така и превземането на каналите. Но и двете имат различен начин, за тяхното решение:
    • TS ще позволи на потребителите, да правят каквото си искат, и след това ще поправи конфликта, който е получен.
    • Delay идеята, няма да позволи на потребителите да правят действия, които после биха довели до конфликт.

    Това просто сравенение обеснява защо Delay често е считано за дразнещо, докато за TS е казано, че е транспарентен, но аз намирам това като слабо възражение:

    • С TimeStamp:
      1. ПотребителA с псевдонимA и потребителB с псевдонимB са в IRC на различни сървъри.
      2. Има разделяне между сървърите, на които са потребителA и потребителB.
      3. ПотребителB си сменя псевдонима на псевдонимA.
      4. Сървърите се връщат
      5. Има колизия на псевдона и Timestamp казва, че псевдонимаA на потребителA е по-стар, затова псевдонимA на потребителB бива kill-нат.
      6. ПотребителA с псевдонимA не разбира разликата, но потребителB я разбира (защото е kill-нат в стъпка 5).

    • С Delay на псевдоними:
      1. ПотребителA с псевдонимA и потребителB с псевдонимB са в IRC на различни сървъри.
      2. Има разделяне между сървърите, на които са потребителA и потребителB.
      3. ПотребителB се опитва да си смени псевдонима на псевдонимA, но не може, поради Delay-а на псевдоними.  
      4. Сървърите се връщат
      5. Нищо не става.
      6. ПотребителA с псевдонимB не разбира разликата, но потребителB я разбира (защото той нямаше възможността да си смени псевдонима в стъпка 3).

    Двете са 'транспарентни' за потребителA, защото той не разбира, какво става.

    Нито едно не е 'транспарентно' за потребителB, защото и в двата случая, нещо неочаквано се случва в резултат на това, че той се опитва да си смени псевдонима на псевдонимаA. За TimeStamp това е kill-а. За Delay на псевдоними това е, че на потребителя не му е разрешено да си смени псевдонима.

    Зависи от ситуацията:

    • TimeStamp може да се окаже по-досадно от Delay на псевдономи: Ако потребителB не се опитваше да се сблъска с потребителA, потребителB ще бъде по-късно kill-нат, което може да му се стори доста досадно.
    • Delay на псевдоними може да се окаже по-досадно от TimeStamp: Ако потребителB е също и потребителA и просто влиза от единия сървър на другия за да избегне разделянето на мрежата, потребителя няма да може да използва псевдонимA (неговия/нейния собствен псевдоним) за малко.

    (Псевдоним) Delay-а се опитва да защити всички, докато TimeStamp се опитва да защити само "законния" потребител.

    Забележка: Подобен пример може да бъде направен и с канали.

  2. Една голяма разлика между двете идеи е начинът, по който проблемът бива решен. TS винаги ще разчита на мрежата, докато Delay никога. Това означава, че TS може да довете до опустошения на цялата мрежа (видяно под някои случаи), докато Delay никога няма да навреди на remote съществуващите.

  3. TimeStamp може да се справи с голям период от време, докато Delay само за 15 минути.

  4. Delay не дава никакаква допълнителна информация, TimeStamp го прави (в повечето случаи 'stamps').

    В примера по-горе, TimeStamp дава повече информация, от Delay на псевдоними: смяна на псевдонима и евентуална колизия на псевдонима на всеки сървър от страната на split-а.

  5. TimeStamp използва паметта за stamps (100Kb за 25K потребителя, 24Kb за 6K канала),
    Delay използва паметта за Delay на псевдоними (близо 400Kb за 25K потребителя). Delay за канали използва около 0.

  6. TimeStamp изисква еднородна мрежа, за да върви ефективно, Delay също, но не чак толкова много.

Политически предназначения

  1. Мрежата има дух (също прочетете и operlist post от M. D. Йесович)

    Мрежата, която ние познаваме, има дълга история и много ``всепознати правила''. Доколкото си спомням, винаги се казваше "псевдонимите и каналите нямат собственици".

    Лесно е да забележеш подобно нещо на мрежа, където колизиите и takeover-ите са обикновенно нещо. С TimeStamp или Delay, нещата се променят, и каквото беше ясно преди, вече не е чак толкова ясно.

    Проблемът е, че TimeStamp решава, кой е законния потребител и логиката използвана от TS има още много да се тества и да се доказва (прочетете по-долу, за дългите разделяния на мрежата и TS примерно). С delay patche-овете, никакъв избор, по този начин и никаква грешка никога не е била допусната, но понякога, ще допусне конфликт да се получи.

    Сега е по-лесно да се разбере, че когато TimeStamp направи 'грешното' решение, потребителят, който е бил "наказан" и който е бил "прав" ще се нуждае или поне ще очаква някой/нещо да поправи грешната ситуация. Това води до нуждата от ``services''.

  2. Channel service

    Channel service, както се знае на другите IRC мрежи е нещо, което съвсем се различава от отдавна установеното правило "каналите нямат собственик" и ще бъде голяма промяна за мрежата. Това е едно от основните неща, поради които хората са против TS, защото, както бе започнато по-горе, това скоро води до "Сега, когато имаме TS, се нуждаем от channel service".

Проблемите

  1. lag-killer ботове.

    Цитирам Дъг М'кларън, който говори за delay на псевдоними: Няма нищо, което да спре `lag-killer ботовете'. Този бот оставя две връзки отворени - една на вашият сървър, и още една на отдалеченият. Също стои и в каналите, в които сте и вие. Веднага щом ви види да си сменята псевдонима чрез своята локална връзка, то сигнализира на отдалечената връзка и се опитва да вземе същият псевдоним. Двете промени на псевдонима биват срещнати някъде по средата, и вие бивате kill-нат.

    TimeStamping-а не рашава и този проблем. То ограничава злоупотребата, защото `lag-killer бота' трябва да е бърз, но това същност не е проблем.

    Роджър Еспел Лима казва: нито една от двете не се справя с тях изцяло: TS ги оставя с шанс за успен около 50%; с ND те винаги са осъществими.

    Веса Руконен отговаря: Delay на псевдоними не прави злоупотребата винаги осъществима. С него, kill-а може да стане само веднъж (на дадения псевдоним), след това псевдонима бива заключен, и бота не може да продължи да се опитва да си смени псевдонима, както става при TS.

  2. рестартирани сървъри

    Цитирам Дъг М'кларън, който говори за delay на псевдоними: Същото се отнася и за наскоро /restart-ирани или стартирани сървъри. Този случай е малко по-различен, защото ако C/N линиите на сървъра са правилно сложете, той ще започне да се свързва към своя ъплинк веднага, давайки само няколко секунди на colliders да се свържат, преди свързването към мрежата.

    Предполагам, че клиентската връзка може да бъде delayed, в този случай. Но не виждам лесен начин за направата на това, както и не се знае дали сървърът е свършил своята връзка към ъплинка си.

  3. дълги splits

    • delay на псевдоними

      Цитирам Дъг М'кларън, който говори за delay на псевдоними: Няма с какво да се спре сървър, който е разделен за повече от 15 минути да направи колицизия на псевдоним. Ако един клиент на този сървър започне да си пуска псевдоними, за всички потребителски псевдоними, които той иска да kill-не, тогава след като сървъра се върне на мрежата, това може да доведе до доста колиции на мрежата.

      Това е почти вярно. Но както ще прочетете по-долу, сървърите не трябва да се разделят за толкова дълго време (поне не много често). Разбира се, че може да се случи..

    • delay на канали

      Цитирам Дъг М'кларън, който говори за delay на канали: Ако сървърът е разделен от мрежата за повече от петнадесет минути, всички delay-и на канали ще изтекът, и потребителите ще имат възможност да хакнат операторския статус за всеки канал, който си искат, като се има предвид, че няма никой в този канал на този сървър.

      Прекъсването на електроснабдяването на мрежите и машините често е повече от 15 минути...

      Има три неща, които мога да ти отговоря по този въпрос.

      Първо, в текущата си версия, delay-а на канали не изтича след петнадесет минути на сървър, който е 'напълно' разделен от мрежата. В подобен случай това би отнело повече.

      Второ, наистина не знам как планираш да злоупотребиш на сървър, който не недостижим. Ако има прекъсване на електроснабдяването на мрежата, само локалните потребители ще могат да злоупотребят, като се има предвид, че те няма да виждат другата част от мрежата, те ще действат само върху определени ``мишени''.
      Това прави броя на потенциалните злоупотребители доста ограничен.

      Най-накрая, ако сървър, или част от мрежата е разделена за дълго време, моето лично мнение е, че не трябва изобщо да е свързана към мрежата.

    • TimeStamp

      Според мен, TimeStamp също има проблеми с дългите splits. Ще взема за пример TimeStamp за псевдоними, но същото мнение може да се направи и за канали.

      Нека да приемем, че двата сървъра са разделени за дълго време. Тогава, двама потребителя могат да ползват един и същи псевдоним, за неопределено време и само един ще бъде kill-нат при връзката на двара сървъра. Мисля, че няма как да се разбере, кой е правноправния претежател.

      Това може да довете до kill-ването на потребител, който обикновенно си ползва псевдонима (ако той си е рестартирал клиента, или си е сменил псевдонима поради някаква причина).

Последни бележки

Вярвам, че този документ дава доста пълно описание и на двете идеи. Целта сега е вие да мислите и да решите, кое предпочитате повече. Но вие трябва да избистрите съзнанието си и да измислите това сами (забравяйки какво и да сте чули до момента).

Вероятно трябва да прочетете това отново, защото има много важни неща, които по-скоро са скрити от големината. Опитах се да адресирам всички предназначения, всички имат различно значение, но това е доста субективно.

Най-важното нещо, което трябва да знаете и да помните е, че която и идея да изберете тя нама да бъде ИЗЦЯЛО ефективна, ако не е на цялата IRC мрежа.

Благодаря на следните хора за това, че прегледаха документа и дадоха своето мнение за него:

Кристофър Калт <kalt@stealth.net>