[Цитат]

Цитат (gat3way @ Дек. 21 2006,17:22)

Весо, съгласен съм с голяма част от твоята лекция и затова съм склонен да не се заяждам, честно '> Има само един спорен момент, не че се заяждам де. ама как да се изразя...мисля че не е особено изяснен. По-долният цитат имам предвид '> Цитат Това са две или повече машини (възли), които се виждат като една навън. Така, ако някой от възлите отпадне поради технически проблеми, другите поемат натоварването. За целта вътре в автономната система на кореновия сървър се използват динамични протоколи за маршрутизация, които да са "link state" или да се обвързани с работособността на процеса на DNS демона (щом процеса на демона спред да общува със сокета, се спира анонсирането на възела - ако всички възли са неналични, се спира BGP анонса). Ако се изпълнят тези условия, то услугата е на практика непрекъсваема поради локални технически проблеми. Подобна тестова структура беше градена в мрежата на СУ "Климент Охридски" с учебна цел. Интересна идея за load-balancing на HA услуга. Предполагам имплементацията на link-state динамичния рутинг протокол, нека бъде OSPF, работи доста независимо от named демона, т.е падне ли по някаква причина DNS услугата, заявки идващи отвън ще продължават да бъдат прерутирани до fail-налия node, мм? Ок, да речем че някой напише някакъв скрипт и при падане на named това се отразява и на рутинга (локалната имплементация на динамичният рутинг протокол на всеки node е просто още един потенциален point of failure, но както и да е). Това поставя още няколко проблема, именно: 1) Как zone информацията ще бъде обща за всички машини зад loadbalancer-a във всеки един момент, т.е изисква се някаква консистентност на данните на всички машини. Да речем че проблема се решава с някакъв shared storage и подходящата файлова система (и определено не чрез NFS, поради ред причини). 2) Понятието "сокет" не е правилно използвано в контекста. При умиране на един процес, умират всички сокети асоцирани с него. Да не говорим че няма механизъм по който един процес да разбере друг процес "комуникира" ли през сокетите, които е създал. И това че bind създава един listening сокет не означава, че при всяка нова заявка отвън, accept() не създава по един нов сокет, как мислиш да наглеждаш по всеки един сокет какво минавало (да не говорим и че това са UDP sockets - SOCK_DGRAM - при което "състоянието" им е малко спорна материя) 3) Да речем ъпдейтваш една зона динамично, защото не е практично да променяш zone информацията по сървърите върху техния, както уточнихме, споределен storage, та после да ги рестартираш всичките за да захапят. Стигаме до още един забавен момент. Балансъра ще те реферира dynamic update заявката към един от сървърите и ще го ъпдейт-неш. Обаче това ще си важи за него, не и за останалите. С другите сървъри обаче какво ще правиш? Дори да пуснеш много заявки за ъпдейтване на зоната, как можеш да си сигурен че си ги ъпдейтнал всичките nodes, така че да не се случи при една заявка единия да ти отговори едно, при втора заявка другият да ти отговори друго? Предполагам си мислил по въпроса, така че ще ми е интересно до какво решение си стигнал '> Между другото не знам защо ви е трябвало да си правите такива занимавки в СУ - балансирането чрез някакъв динамичен рутинг протокол е как да кажа...глуповата идея. Най-малкото нямаш никаква сесийност, което прави този метод абсолютно непригоден за балансиране на уеб приложения. Представи си че така балансираш 5 webapp сървъра за един интернет магазин. На всеки 2-3 request ще ходиш на сървър, който няма грам идея за твоята сесия, да речем за това с какъв потребител си се лог-нал и какво има в shopping cart-a ти. И това е само един частен случай, има още сума ти issues свързани с това. Освен което е в пъти по-усложнено и натруфено решение в сравнение с LVS да речем. Просто не виждам никакъв смисъл да си утежняваш живота с динамично рутиране, когато нещата стават доста по-лесно '> Сигурно е имало някаква причина да са упорствали да реализират такова нещо. Интересно ми е каква ли е била тя '>

Не мисля да обяснявам "глуповатите" си идеи и да ти правя удоволствие да ти се хващам на селските заяждания. Точно на теб не. Не струваш толкова усилия. Нещата са описани, има ги в Интернет. Не съм ги измислил аз.

[Примерен код]

Примерен код

ilia@bulgra:~$ dig . any ; <<>> DiG 9.3.2 <<>> . any ;; global options:  printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 920 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;.                              IN      ANY ;; ANSWER SECTION: .                       172800  IN      SOA     ***.maxmv.org. hostmaster.bulgra.com. 2006122002 86400 10800 2505600 86400 .                       279560  IN      NS      d-root.maxmv.org. .                       279560  IN      NS      e-root.maxmv.org. .                       279560  IN      NS      f-root.maxmv.org. .                       279560  IN      NS      a-root.maxmv.org. ;; Query time: 2 msec ;; SERVER:***#53(***) ;; WHEN: Thu Dec 21 14:41:48 2006 ;; MSG SIZE  rcvd: 170

Да си скриеш за всеки случай SOA е много фешън. Много, много хитро е това. Ще си го запазя и ще го покажа на колегите си.Сигурно скоро ще бъде описано с RFC като добра практика. За липсата на AUTHORITY секция и ADDITIONAL секция в отговора няма да говорим. Не съм и очаквал да има такива неща. Някои хора имат особена гледна точка към протокола DNS. Явно вие проектирате нов протокол. Похвално и много забавно.

Минутка за размисъл за теб: Защо в отговора на заявката трябва да има AUTHORITY и ADDITIONAL секции. Ако тръгнеш да кандидатстваш за патриотичен регистър и покажеш изход подобен на горния, ти гарантирам, че не само няма да получиш регистърски права, но ще бъдеш абониран за разни весели книжки и списания. Най-лошото е, че ще те търсят за отмъщение турските фирми и китайското правителство'> Едните има доста странни сексулани нрави, на другите всичките им нрави са странни...

А отговора ти за anycast-а ме размаза от оригиналност'> Много се изкефих, да знаеш. Та значи отговора на това дали има или няма anycast бил:

Примерен код

NSA.I-DNS.NET.            1D IN A         64.62.142.131 .                       1D IN NS        NSA.I-DNS.NET. NSB.I-DNS.NET.            1D IN A         195.161.113.189 .                       1D IN NS        NSB.I-DNS.NET. NSC.I-DNS.NET.            1D IN A         211.169.245.170 .                       1D IN NS        NSC.I-DNS.NET. NSD.I-DNS.NET.            1D IN A         203.81.44.47 .                       1D IN NS        NSD.I-DNS.NET.

Anycast означава един IP мрежов сегмент (формиран като маршрутен обект) да има много източници при рекламирането си в BGP. Подобен anycast бе направен за първи път за коренов сървър за имена за f.root-servers.net и в момента се прави за други сървъри. Понеже виждам, че си тръгнал да правиш коренов сървър за имена без основни познания, смея да ти препоръчам следния технически документ:

http://www.isc.org/index.pl?/pubs/tn/index.pl?tn=isc-tn-2003-1.html

за да не бъркаш anycast с постигането на AS ентропия, което си описал.

За изискванията също се изкефих'> А кой ги е проверил, кой ти е сертифицирал техниката, кой ти е сертифицирал специалистите, това някак си остава неясно. Защото аз лично на такива хора не мога да се доверя.

Що се касае до това дали в root-servers.net има единични машини или не, трябва да ти кажа, че има само две, които са единични възли и по предписанията на IANA до 1 януари и те трябва да са многовъзлови. Anycast реализацията се брои за глобална многовъзловост. Може да се види тук:

http://www.root-servers.org/

Иначе за лобитата в ICANN. Всеки заинтересован има лоби там. Това е проблемът на тази организация, че е политическа.

За другото няма да говоря. Не си струва.

[Цитат]

Цитат (Blue @ Дек. 21 2006,14:01)

А кой да получи правата? Register.bg? Ще си замълча какво е мнението в ICANN за тях. Или американска компания? Не е редно за български TLD. Второ, по какво съдиш че не разбирам от DNS? Поддържам DNS сървър на любителската root мрежа Cesidian Root. А и да напишеш писмо, от компанията имат хора в ICANN - те ще помогнат. Целта е единствено да се стартира преди ICANN и да го получим ние, а не някоя американска компания.

Да оставим настрана аматьорски мрежи с коренови сървъри за имена и да поговорим как се правят нещата всъщност.

Кореновият сървър за имена, известен сред хората завършили с отличие българска филология като "root" сървър, не е просто някаква машина, сложена някъде и облепена с надписи "root server" и домуваща в някоя мрежа в Евронет или друг култов доставчик на порно, филми и музика, а е инфраструктурна мрежова единица, при изграждането на която трябва да се имат предвид голям набор особености. Не знам защо някои индивиди си представят коренов сървър за имена като огледален файлов FTP сървър, който всеки може да си направи. Целта на кореновият сървър е да поддържа сигурно и надеждно особено важна информация, която е решаваща за интернет услугите, доколкото повечето са базирани на информацията в системата за имена. Следователно към изграждането на кореновият сървър има много строги изисквания, които стриктно трябва да се следват.


1. Кореновият сървър трябва да е отделна мрежова инфраструктура.

Това не е измислица или прищявка на някого. Кореновият сървър за имена трябва да се намира в самостоятелна автономна система (ако се следва логиката на развитието на Интернет, то трябва да притежава и 32 битов идентификатор на автономната система), която да има в себе си поне една алокация /24 от адресна фамилия ipv4 (rpsl - afi ipv4.unicast) или поне една /102 от адресна фамилия ipv6 (rpsl - afi ipv6.unicast). Целта е така обособената мрежова структура да може да е достъпна поне през два транзитни доставчика и да има винаги гарантиран резервен канал. Разполагайки с автономна система, кореновият сървър за имена може да участва в много логически схеми за маршрутизация на база на AS идентификатор, например в "BGP Community" базирани схеми за разпределяне на маршрути между съседи и др.

Препоръчително е автономната система на кореновия сървър да бъде обявена в състояние на anycast и да има множество точки на присъствие. Точките на присъствие трябва ясно да са описани в as-num обекта, а също така в as-num обекта да са ясно описание import, mp-import, export и mp-export обектите до ниво на подробност IP адрес на съсед.

Влизането на автономната система на кореновия сървър в anycast режим позволява локализирането на DDoS атаки и свеждането им до ограничени по значимост DoS атаки върху разпределени възли. Това е решение на транспортна задача по разпределяне на трафик чрез метод на сортирова на трафика.

Да сложиш коренов сървър за имена в LAN доставчик е мега простотия и неуважение към потребителите в Интернет. Това е не само смешно, това е жалко. Човек правещ това не може да е нищо повече от квартален окабелител.


2. Кореновият сървър трябва да отговаря на определени изисквания за конфигурация.

Не може кореновият сървър да е набързо асемблирана машина. Това трябва да е сървър, който да е преминал поне 2-3 месечни изпитания, а не утре да спре поради издут кондензатор. Съгласете се, че това е несериозна работа. Освен това кореновият сървър за имена не е никога една машина. Това са две или повече машини (възли), които се виждат като една навън. Така, ако някой от възлите отпадне поради технически проблеми, другите поемат натоварването. За целта вътре в автономната система на кореновия сървър се използват динамични протоколи за маршрутизация, които да са "link state" или да се обвързани с работособността на процеса на DNS демона (щом процеса на демона спред да общува със сокета, се спира анонсирането на възела - ако всички възли са неналични, се спира BGP анонса). Ако се изпълнят тези условия, то услугата е на практика непрекъсваема поради локални технически проблеми. Подобна тестова структура беше градена в мрежата на СУ "Климент Охридски" с учебна цел.

Кореновият сървър за имена трябва да има система за наблюдения на натоварването, която да осигури наблюдението на услугата в реално време от гледна точка на натоварването (брой заявки, характера им, време за отговор, лоши заявки, отхвърлени, зле формарирани и пр).


3. Въпросът за доверието. Кой може да е оператор на коренов сървър за имена?

Системата за имена е винаги йерархична (за разлика от глобалната система за маршрутизация, например). Това значи, че в нея винаги има единоначалие. Коренов сървър за имена е вид доверие, главувано на някого от този, който поддържа системата за имена. Все едно дали това е коренов сървър е от "официалната" мрежа, благословена от ICANN или от друга мрежа. Това доверие се гласува на база технически и организационни способности. Може да има аматьорски мрежи, в които всеки да си играе на коренови сървъри. Но в реалният случай никой няма да се довери на непозната организация със съмнителни технически качества и способности, които отгоре на всичко не са доказани. Аз например нямам гаранция, че някой от тези сървъри за имена не ме лъже. А това би било факт, ако куцо и сакато почне да гради коренови сървъри.

Освен това оператора трябва да бъде нестопанска и неправителствена организация, а не фирма с глупав имидж, оперираща в квартален LAN и ненадскочила тинейджърския манталитет.


4. Колко може да са кореновите сървъри в една система за имена?

Те трябва да са малко. Колкото повече стават, толкова по-трудно се наблюдават, толкова по-трудно се забелязват грешки в конфигурацията и толкова повече доверието системата за имена пада. Да не говорим, че се намалява взискателността към операторите, защото стават много и на една централна огранизация й е трудно да следи какво правят ти и дали не лъжат в нещо.



Какви са особеностите при ccTLD регистрите?

Там регистърът трябва да осигури AS ентропия на точките на пристъствие на своите сървъри за имена така, че те да са в различни автономни системи и да няма простотии от типа "един канал паднал и ccTLD сървърите за имена ги няма". Примерно, точно това ще стане с фирмените DNS сървъри на фирма bulgara, защото те са в една автономна система (тази на Евронет) и даже в един мрежови сегмент вътре в автономната система. Всяка уважаваща себе си фирма, особено ако има някакви претенции, дори по-малки от тези за регистър, не може да си обвърже DNS услугите с една автономна система, защото има ли проблеми с връзката, никой няма да знае, че домейнът на фирмата съществува. Ако някой изпрати поща до нейния домейн и няма връзка до сървърите за имена на фирмата, то всичко ще изглежда така, все едно домейнът е проблемен или несъществуващ.

Регистърът на даден ccTLD може да избере обаче между AS ентропия и съставянето на своя AS, която да поддържа услугата. За момента само няколко регистъра имат подобна практика.

Какво ли да говорим за хора, които имат претенции за каквото и да е, а са се обвързани с доставчик, който има автономна система (че и LIR бил, хехе) и електронните пощенски адреси на техническите лица за контакти са ... в abv.bg и yahoo.com. Не вярвате:

[intruder@roadrunner ~]$ whois3 80.72.80.165

inetnum:      80.72.80.0 - 80.72.80.255
netname:      ARENANETT
descr:        Atronix2000 Ltd
descr:        EVRO.NET assigned addr. space
country:      BG
admin-c:      RS25357-RIPE
tech-c:       AJ870-RIPE
status:       ASSIGNED PA
notify:       info@evro.net
mnt-by:       EVRONET-MNT
changed:      lir@evro.net 20031025
source:       RIPE

person:         Rumen Sarandev
address:        EVRO Network
address:        16, 23th September
address:        Plodviv 4015
address:        Bulgaria
phone:          +359 32 624394
fax-no:         +359 32 624394
e-mail:         tcvetan_d@abv.bg
nic-hdl:        RS25357-RIPE
mnt-by:         EVRONET-MNT
changed:        lir@evro.net 20040723
changed:        lir@netvisio.net 20050804
changed:        tcvetan_d@abv.bg 20061106
source:         RIPE

person:         Alexander Jotov
address:        Atroniks 2000
address:        "Razsadnika" Quarter, Build.25, Entr.G
address:        BG-1000 Sofia
address:        Bulgaria
phone:          +359 2 8224645
e-mail:         balabana2001@yahoo.com
nic-hdl:        AJ870-RIPE
changed:        lir@netvisio.net 20050808
source:         RIPE

% Information related to '80.72.80.0/21AS20876'

route:        80.72.80.0/21
descr:        EVRO.NET
origin:       AS20876
mnt-by:       EVRONET-MNT
changed:      lir@evro.net 20030808
source:       RIPE


Само да спомена, че Теодор Петков няма нищо общо с Register.BG, а е технически персонал в Online.bg. Нормално е да се пита преди да се пишат наизуст глупости и да се изпада в телешки възторг от написаното.

Това за компанията и ICANN ме изкефи'> А в Пентагона компанията има ли свои хора, които да помогнат? Или компанията държи с компромати известни личности в Конгреса'> А вестник за конспирации компанията има ли?

А обявяването на инициатива за създаване на регистър във форум с читателска маса съставена от 80% технически инвалиди и пълни идиоти, чупи от оригиналност! Признавам си. Колкото пъти дойда тук, толкова пъти ахвам. А да, трябваше да има патриотизъм.. да бъдело българско. Супер елементарно, но в този форум нивото е такова. Не се мисли в стил "да се управлява по-добре", а "кенеф да е, ама да е наш, български". Хайде да не си излизаме с номерата "да не го хванела чужда компания, да било българско". Другарят Вени Марковски добре се е погрижил да е лоби на Affilias в ICANN. У нас масовката му с ДАИТС по опитите за предаване на контрола на TLD BG в ръцете на Affilias беше много ефектна, само дето много хора я разбраха и ще му е много трудно сега, като не е шеф в ICANN да мъти така водата.

Иначе какво ли да ви кажа... Що не вземете малко да пораснете, а? Или да поумнеете? Или да разберете, че едно нещо се прави по един начин и този начин трябва да е правилния.

Благодаря на Тодор Петков, че ме насочи към тази тема, изпълнена с толкова "хумор".

Извинявам се, ама как хора, които понятие си нямат от DNS и пишат в този форум мега глупости по темата, имат наглостта да искат да бъдат регистър на ccTLD БГ.

Аз съм първият, който ще напише писмо до ICANN, защо не бива на тези хора да се дава подобно управление. И причината е до болка ясна и се нарича "АМАТЬОРСТВО".

Понеже виждам, че се няма никакви технически аргументи и само разни травестити се напъват да кажат нещо (не визирам VladSun), е време да си кажем "всичко хубаво". Да пиша повече няма смисъл. Нито gat3way ще се излекува, нито ще се разхубави, нито ще поумнее. И след пет месеца да вляза пак, пак ще си е същия непризнат психолог-форумен лъв, за който най-големия дразнител е това някой да знае нещо, което той не знае. Нормалните хора се радват, като виждат знаещи хора около себе си, защото така те си вършат по-добре работата. Ненормалниците само се дразнаят от това, но те и без това никаква работа не вършат.

Останете си със здраве и дано ежедневната олигофрения тук не ви дразни. Аз лично си ценя времето и не може да го губя обяснявайки на някого нещо, което той не иска да разбере.

@VladSun: Стига филмови сцени и лични драми. Дистанциран от човека, тра-ла-ла и глупости, колко хубаво звучи, все едно гледам треторазряден латиносериал. Сигурно си очаквал да бъдеш оригинален и да засегнеш, но дори не ме разсмя. Я вземи се стегни и почти да разсъждаваш малко по-трезво. Да обясняваш на отношението си към някого, за което той не дава и пет пари е повече присъщо на жените...

И още нещо, като препоръчваш такива самоделки, не се чуди, че състоянието на нещата е такова. Едно нещо се прави винаги по правилния начин. За това обаче е нужно да се търсят начини. За да се направи по неправилния начин винаги може да се намерят причини и основания. Именно затова всичко е на този хал. И ще продължава да си бъде и после пак ще има чуденки "ама защо така бееее... ама защо не е добре ...". Ами то реалността е функция на тези, които я градят.


@gat3way: Дарлинг, защо не си толкова хубава, колкото и проста?

Да отминем тирадите на разни IRC герои и смешници, на които падението им е така присъщо и да продължим малко по темата.


В условията на локална свързаност в България има един голям проблем. Този проблем е топологията на взамната свързаност. Причината е, че у нас локалната свързаност не мина през фазата "Internet Exchange" - IX. Какво е това? Както знаете в местата, в които преминава и се разпределя много трафик, са организирани т.нар. локални среди за обмен на трафика. Това са именно IX. Основата им е високоскоростна среда за обмен на данни, връзката до която всеки участник в IX изгражда за своя сметка. Разбира се, има условия, на които един участник в IX трябва да отговаря (няма да ги изброявам, но най-важното е участника да има автономна система и да използва BGP4 за да рекламира маршрутите). В IX топологията на свързване е пак точка в точка, но има много по-добър контрол над скоростта от доставчик до доставчик и разбира се, по-малко настройки, чрез които тя да се поддръжка. Има и по-малък брой BGP сесии, които се реализират чрез свързване на участниците в рефлекторна BGP схема, което намалява натоварването на маршрутизаторите (т.нар. пълен "mesh" е по-малък). От гледна точка на BGP сесиите топологията е звезда (не е нужно всеки доставчик да пуска BGP сесия до всички други), а пуска само една или две сесии до BGP сървъри в рефлекторната топология. Топологията, по която обаче двата доставчика обменят свързаност е точка в точка. Хубавото е, че така се оптимизира топологията за връзка до недиректно свързаните в IX доставчици и е ясен нейния статус и лесно може да се договори резервиран капацитет (технологично лесно е той да се направи). IX води и до по-голяма симетризация на каналите и най-вече прави транзита задължителен. Това задължение се декларира от доставчика му при кандидатстването му за членство в IX. Няма балкански нрави като "абе аз да точа само, а от мен никой да не точи" и т.н. селски тарикатлъци.

У нас нещата се развиха по доста различен сценарий. Първо се създаде т.нар. SIX - Sofia Internet Exchange. Доколкото в дъното й стояха BOL.BG (Димитър Ганчев много обича да ръководи и управлява), тази организация нито имаше ясна представа какво е IX, нито реализира технически среда за IX. Разбира се, разпадна се с гръм и трясък, поради това, че не само BOL.BG не знаеха какво е IX, а и останалите дето се бяха събрали да участват не знаеха и понеже не знаеха, го разглеждаха като заплаха за бизнеса им със обмен на съдържание в нарушение на лиценза за разпространение. Трябва да си го кажем ясно, че ставаше дума за извиване на ръцете на едни доставчици от страна на други с цел продажба на достъп до "free" сървъри. Вследствие на това се започнаха едни тънки сметки кой с кого да се свърже, кой какви мрежи да филтрира (ip.ludost.net помогна на някои хора да филтрират достъпа до "free" съдържание само за български мрежи, а не за разпределение на скоростта, както някои мега специалисти смятат). След това дойде модата на MAN средата за свързване. В нея логиката е, че всеки доставчик предоставя вируален LAN, в които се свързва с други доставчици. Тази схема отново може да се използва за извиване на ръце и тя се използваше като такава. Искахе се гаранции за това, че единия нямало да точини много, пък щял да дава да се точело от него еди колко си пъти повече и не знам си какви абсурдни схеми. За Евронет и ДатаБГ ме е гнус да говоря даже. Такова извиване на ръце, такива мутренски похвати в Интернет и селяния не съм очаквал да видя.

MAN средата за свързаност омрежва много топологията. На практика у нас силно асиметризира връзките (доста време ми отне да анализирам защо, но не мисля, че искам да описвам и това) и не може да даде точна и ясна представа за скоростта между транзитно свързани автономни системи. Много е сложно да се направи подобна оценка. Няма и ясни правила при обмена на трафик, често има асиметрии в маршрутизацията. На практика локален високоскоростен канал за повечето доставчици се формира чрез BGP community обмен на префикси и формирания накрая "mesh" се различава доста от списъка на ip.ludost.net, който е абсолтен, а не топологичен и затова не може да е меродаван източник за конкретната ситуация. Т.е. има делене по BGP community маркер на високо и нискоскоростни направления. Няма единен канал за локална свързаност, няма гарантирани скорости, няма дори минимално прогнозируеми. Именно защото е така, когато се налага висока скорост между два града в България за някакви фирмени цели, се гради канал с гарантирана скорост и въобще не се разчита на тесните канали на доставчиците. Дори в някои случай е по-добре да се изгради сателитен линк. Макар RTT там да е голям и BDP параметъра да е неблагоприятен за връзките, тази свързаност е по-качествена от тази, която уж идвала от "peering" високоскоростните трасета.

Бях голям ентусиаст в София да се изгради IX и мислех да пусна проект за това за финансиране от ЕС (не от мое име, а от името на доста авторитетна организация). След като видях обаче с какъв манталитет на тарикатлък ще се сблъскам у нас, започнах да се поотказвам. Поотказа ме и Делян Делчев, с който след доста обширен спор, стигнахме до мнението, че така само ще позволим на МВР по-лесно да подслушва трафика у нас. За жалост Делян се оказа за пореден път лош пророк. Близо година, след като спорехме с него, МВР използва подслушване и принуда за да се бори с потребителите. И доколкото аз съм много против Интернет да е поле на изява на падари и цензури, оттеглих целия проект за IX.

[Цитат]

Цитат (gat3way @ Дек. 07 2006,11:24)

Тц, разсейваш скуката и създаваш предимно приятни емоции да ти кажа. Твоето мнение по въпроса дали имам коса и как съм бил правил правила за трафик контрол например ми даде една свежа доза положителни емоции. Пък и щом искаш да ти обясня, ще ти обясня бе '> Това беше първото нещо за което се сетих като прочетох ейтва: Цитат ...тъпотии с извличане на мрежи по country поле от RIPE DB и прочие, от които човек само може да се отчайва, че ги има! Ама честно казано нямам нищо против да се опитваш да ме класифицираш. Даже сега съвсем нарочно те провокирам. Липсват ми емоции, липсва ми безплатна психоанализа и как беше там... консултация от истински специалист. Последното всъщност не ми липсва толкова, и не само на мене доколкото разбирам '>

Говори ми глупости, говори ми. Ела и напиши в блога ми пак някой анонимен коментар. Типичен IRC герой си. Понеже нямаш друга среда на изява, много те кефят анонимните изяви тип "селски тарикат от градски тип". Безинтересна циклофрения, а?

[Цитат]

Цитат (gat3way @ Дек. 07 2006,10:47)

Ами предполагам знаеш кой е създал и кой подържа базата с адресни ranges на ip.ludost.net, предполагам че ще е най-коректно да отидеш да им се навикаш и обвиниш в некомпетентност, така де, таргетирай си недоволството по-прецизно. Иначе как очакваш тук да има засегнати хора, те нито са виновни, нито пък си постигаш ефекта така '>

Както винаги пишеш глупости и се опитваш да участваш някъде на принципа "и аз да кажа". Приятно ми е, че те дразня и че не ти създавам душевен комфорт, но за жалост това положение ще продължи.

Ти поне нямаш косица, която да ти пречи да гледаш по-добре в монитора, виж моля те къде на ip.ludost.net пише за какво се използва и къде е написано, че този списък се използва за класифициране на трафика по скорости. Обясни ми в този случай мега кретенската си идея да пиша на Боян Кроснов и да му се карам за това, че е направил този списък, само защото някакъв подобен на теб набеден специалист, е ползвал този списък както си знае? Както винаги се обаждаш неподготвен и не знаеш, че този списък бе напревен с цел направата на access-list-и по време, когато напречните връзки бяха по-скоро изключение и въпрос на политически натиск.

Как се класифицира трафика за да бъде след това подложен на селекция по скорост за клиент.

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


Понеже се навъдиха всякакви писачи по темата, които даже имат претенциите да препоръчват творенията си, искам да напиша как се решава задачата, известна сред ланаджиите-идиоти като разделяне на трафика на "peering" (да ви имам и понятията) и "международен" (въх!'>. Точно идиотски са самоделните решения тип "ТНТМ"

Защо толкова малко хора си дават труда да седнат с лист и химикал и да поразсъждават така, както биха разсъждавали доставчиците, които събират трафика и го класифицират.

Какво значи локален канал (известен като "peering")? Повечето хора си представят едни безкрйно широки канали и по тях достъпват на висока скорост всичко българско. Това са пълни безмислици. Скоростта в самия български интернет е страшно неравномерно разпределена. Висока скорост има само там, където между доставчиците има напречна свързаност и то в рамките на населеното място. Пример е София, където всеки доставчик оперира през някоя от MAN средите и се свързва с другите формирайки виртуални LAN мрежи (VLAN). Дори и там скоростта на свързаност е обект на договорка и не е безгранична. Ако един клиент от Софийска мрежа реши да достъпи файлов съвър във Варна, нали никой не си прави заблуда, че това ще е с някаква висока скорост? Или пък торент сесия до клиент в Малко Търново ще е със скоростта, която ще има сесия с близкия съсед през два квартала? И после има обаждания от клиенти със съдържание "е нали е пиъринг това бе, защо нямам висока скорост". В момента положението е такова, че скоростта до мрежи в чужбина е по-висока от скоростта до повечето мрежи в провинцията.

И тук идват самоделките и мега техническите схеми на разни "специалисти", съгласно които има само два канала и клиентите биват разпределяни по скорост в тях. И веднага се вижда, че по единия канал се задава дефицит на трафик, който може да препълни дори дадено направление, да внесе в него загуби на пакети и да направи услугата "к'ъв да е Интернет". Това е така, защото хората, които правят подобни схеми и идея си нямат от топология. И после творят, че дори и продават подобна услуга (мега наглост!'>, пишат статии и дори не ги е срам да си напишат името като автори на подобни идиотии.

Много от тях се измъкват с оправдание "ами то сега едното по-скъпо от другото", "ами то да работи там нещо" и подобни. Ето заради такъв начин на разсъждения в българското интернет пространство е пълен мрак, дерибейство и безпростветност. И после били обидени защо не им признавали "труда" и не им давали парички за това. Типична постсоциалистическа наглост - да правя каквкто мога, а да ми плащат както искам и да ме признават за баш тарикат. Прочели нещо от тук и там, въоръжили се с неумение да решават елементарни транспортни задачи и после "ау, ами то така сега, какво да направим, то не съм аз виновен, ами Пешо". Също така има оправдания "ами той моя доставчик така иска и аз затова такава идиотска схема правя" и т.н. Ами при прости клиенти (все LAN корифеи, знаещи и можещи, опъващи жици по дървета), големите доставчици се изхитряват да дават за много пари малко услуги. Като клиентът не изисква нещо, то не се предлага.

Ценово оправдание "ами едиия канал е по-скъп от другия" издиша от всякъде, защото ако се следва схемата на разделяне на скоростите, едното разделяне (това с т.нар. "peering") води до създаване на дефицит на скорост и следователно излиза, че по-скъпия канал е по-качествен (като параметри и най-вече ниво на загуби на пакети), а по-евтиния е много по-лош, защото в него има дефицитни откъм скорост направления, които не са покрити с политики за скорост (примерно по едно направление могат да дойдат не повече от 720 Kbps, а на "шейпъра" (велика българска думичка използвана от култовите администратори), сложен клас за 10 Mbps).

Това със списъка с "български" мрежи винаги ме е просълзявало от умиление. Разбира се, аз не мога да очаквам, че всички хора са наясно защо това, че една мрежа е описана с поле "country: BG" в RIPE DB (от където се извлича списъка), не я прави достъпна на висока скорост или дори не я прави "българска". Това по този списък да правиш извод за свързаността до дадена мрежа е признак на стрхотен дефицит от познания. Също така този списък не отчита и ценовата схема на каналите, защото има български мрежи, които продават трафика от и към тях на цени по-големи от тези, които са за Интернет (известен сред широките LAN маси като "международен" канал - канал между народите) - warez-и и не знам си какви още източници на филмчета, музика и кадри с голи какички и батковци.


***


Протоколите, чрез които се маршрутизират пакетите не знаят нищо за принадлежността на една мрежа към дадена държава. За BGP4 (основен маршрутизиращ протокол в момента), няма географски признаци, които той да следва. В него са заложени съвсем различни параметри.

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

Нека аз съм краен разпределител за домашни клиенти. Аз купувам трафик от доставчик и искам той да ми класифицира канала чрез три виртуални LAN-а така. Първи канал (първи виртуален LAN) - Интернет, втори канал (втори виртуален LAN) - локален канал със скорост до точките му на терминиране не по-малка от 80 Mbps, трети канал (трети виртуален LAN) - локален канал със скорост до точките му на терминиране не по-голяма от 10 Mbps. При себе си имам три маршрутизатора, които получават през BGP сесията селектирани маршрутите за трите канала. Тези маршрутизатори са т.нар. "първи вал" в моята автономна система. Вторият вал маршрутизатори са тези при клиентските мрежи и всеки маршрутизатор от втория вал има по една сесия с всеки машрутизатор от първия вал. На маршрутизаторите от втория вал има само контрол на трафика касаещ вътрешната мрежа (превентори на полюции на трафика, защита от потоци с голяма плътност на пакетите и т.н.). На всеки маршрутизатор от първия вал се прави контрол на трафика за всеки клиент по даден канал. И това (ако маршрутизатора е с OS Linux), става само със селектор, без да се прави изобщо маркиране с iptables.

Може да се направи и по-сложна схема на селекция, но тази е достатъчно илюстративна. Може и да се разпредели натоварването по по-уместен начин, но горното стига да опише идеята.

Няма да описвам BGP community схемата при доставчка. Това е обект на различна дискусия и ако някой много иска, ще му бъде обеснено с примери.


***


И нека сега да не започваме по стар български обичай с оправдания от рода "ама то така скъпо, ама то много сложно и т.н.". Никой не е абониран да бъде доставчик и на никой не е гарантирано конституционно правото да бъде доставчик. Това, че е много модерно да доставяш свързаност към Интернет, а предишната или сегашна дейност да ти е месопреработване и продажба на коли втора употреба, изобщо не значи, че ти трябва да оцелееш като доставчик на свързаност. В момента всеки иска да е интернет доставчик, да купува евтинко каналите и да ги разпределя без особени схеми и усилия и да печели повечко. Доставчиците у нас са твърде много и 80% от тях са пълна скръб и трябва да фалират. Не може човек със съзнание на земеделец и скотовъд, да се занимава с мрежи. Хора с манталитет "аз съм админ, тука един леймъри дето не са чували ко туй слак ги мачкам и рулирам", да отварят по една сергия на женския пазар и да почват да се занимават с единственото нещо, което могат. Ето затова не ни взимат не сериозно в чужбина. Защото съм бил в три комисии за одит на телекомуникационни структури у нас и ме е срам от колегите ми от чужина, защото те са в шок от това, което виждат тук. И после този одит отива при инвеститора и той казва "за какво да инвестирам в България, като пазара им е кирлив, а "спациалистите" прости". И от догодина като почнат да идват у нас телекоми, те изобщо няма да се занимават да закупуват даден LAN. Ще пускат своя среда, ще предлагат своя услуга и ще мачкат с качество. На "мегаспециалистите" ще им остане само да си пият ракията и да псуват що сме в Европа и що по-кадърни от тях идват и им взимат клиентите.

[Цитат]

Цитат (VladSun @ Дек. 06 2006,21:52)

Цитат (vesselinkolev @ Дек. 06 2006,19:09) За т.нар. "шейпъри" (баси и българската дума, а) не искам да се нервирам излишно и да обяснявам какви идиотски схеми за контрол на скоростта могат да се измислят. В 1% само се използват u32 селектори. Всички са безумно влюбени във flowid и само това може да обясни защо една задача по селекция на пакети, която може да се направи в tc направо чрез u32 или u8 селектор, трябва да се прави първо през netfilter с iptables и чак тогава чрез tc. И аз благодаря, г-н Колев за *обективната* оценка на положението с Интернет доставчиците в България. По отношение на твърденията в цитираното по-горе - не съм много съгласен и ще обосновя различията си с Вашето мнение в качеството си на автор на статии за прилагане на споменатата от Вас схема. Дали ще отговорите или не - не това е важното за мен. *Всички* големи български Интернет доставчици, които не се занимават с крайни клиенти и от които всички малки доставчици купуват канал правят разграничение м/у български трафик и международен такъв. Естествено разграничението е в цената. По веригата това разграничение отива и до крайния клиент. В такъв случай, аз лично не виждам как би могло да се реализира контрол върху трафика с u32 селектор и за *двете* посоки на канала без това решение да стане в пъти по-неефективно от решението с flowid.

Да, объркал съм handle с flowid, има и правописни грешки, за които се извинявам, но не разполагам с време дори за редакция на написаното.

Също така, хайде без снобщини и разговори на вие. Това, че ти не знаеш как се разделя трафик по канали и пишеш статии достойни за снизходителна усмивкам не значи изобщо, че имаш понятие как това става.

И ще напиша как точно се разделя трафика и къде се прави от опит на аднминистратор с над 8 години стаж точно по проблема и дано най-накрая се разбере това, което пиша и се спрат какви ли не тъпотии с извличане на мрежи по country поле от RIPE DB и прочие, от които човек само може да се отчайва, че ги има!

Аз не влизам от много време в този форум, защото щадя себе си и не искам да чета глупости. Но след като двама приятели ме помолиха да вляза и да напиша някои неща, ще си позволя да пусна тук тази кратка бележка и после пак да си кажем "чао".

Повечето пишещи тук са в максимална и болезнена заблуда какво е доставка на свързаност към Интернет (известна сред масовия неграмотен потребител като "Интернет").


1. Кой какво доставя?

В глобалната мрежа доставчиците на свързаност са разделени в йерархия. Няма да почна да пльосвам термини, а ще се опитам да обясня какво точно прави всеки от тях. Най-високо стоят доставчици, които разполагат с физически трасета и оперират на територията на поне два континента. Тези доставчици често доставят т.нар. "Layer 2" свързаност и не се занимават с маршрутизация. Т.е. те доставят канала за свързаност, а вече в него заделят физически подканали, които продават на т.нар. "Layer 3" доставчици, които извършват маршрутизацията. Някои от споменатите доставчици оперират и с "Layer 2" и с "Layer 3" канали едновременно. Как и защо оперират и на двата слоя в OSI модела няма да коментирам. Това е много дълга тема.

На всеки може да му се струва безкрайно удобно да се свърже към такъв високостоящ в йерархията доставчик, но това не може да става толкова лесно. Една от причините е, че за да стане някакъв субект партньор на такъв доставчик, той трябва да отговаря както на технически условия (да има определен клас оборудване, обучен персонал, да има трасе, отговарящо на определени условия, автономна система и др), така и на финансови (за закупи канал със скорост не по-малка от някаква пределна - никой не продава обем трафик, а канал със зададени параметри). Именно тук се започва веригата от посредници, които донасят доставката, като услуга, до крайния клиент. Колко дълга е тази верига, т.е. колко доставчика един след друг са навързани, е вече въпрос на конкретна ситуация. Броят посредници по веригата до крайния потребител, влияе много силно върху крайната цена на доставка.

Стигаме до последното ниво, с което крайния потребител контактува. Дали това ще е БТК, която предлага ADSL (безобразна услуга) или бизнес линии, или ще е квартален LAN, който предлага "к'ъв да е Интернет" е вече въпрос на конкретна ситуация.



2. Какво получава крайният потребител?

В случая говоря за домашни потребители и само частично ще засегна малки бизнес потребители.

У нас никой доставчик на свързаност за краен клиент не предлага технически документ, с който да покаже пред потребителя какви технически параметри на връзката му предлага и в каква степен му ги гарантира. На практика у нас никой не знае какво се крие зад доставката на услугата "доставка на свързаност към Интернет". Практиката е да се указва скорост, която не е ясна скорост на какво е. Доколкото у нас се е тръгнало към едно напълно потребителско общество с идиотизирани потребители, в което никой нищо не осмисля и гледа само какво има в рекламата като обещания и цена, аз не очаквам в обозримо бъдеще някой доставчик да започне да дава технически спецификации на връзката към клиента, защото именно клиента е идиот и не изисква такава. Освен това никой държавен орган по стандартизация към момента, не се интересува от това кой доставчик на свързаност каква услуга и с какви параметри предлага. Т.е. в момента няма дефиниция на услугата "доставка на свързаност към Интернет" за крайни клиенти. Наскоро ми се наложи да участвам в комисия по провеждане на търг за доставка на свързаност за една голяма организация. Няма да ви казвам какви физиономии имаха участващите като разбраха, че трябва да покажат точно какво ще доставят с точни технически спецификации. Но аз настоявах изрично да бъдат предоставена тази информация и не остъпих от позицията си, защото аз не мога да оценявам предложения само по цена, а искам да знам какво се крие като услуга зад тази цена. И пет пари не давах за притесненията на участниците - след като са тръгнали да печелят пари, да си ги заслужат с качество.

Центата за доставката на свързаност към Интернет може да се раздели на три пера: разходи по оборудване и наемане на канали за свързаност, разходи по персонал (застраховки, работни заплати, отчисления за здравни застраховки, пенсионно осигуряване и др), разходи по поддръжката на клиента. Второто перо обикновено е най-голямото. То зависи от това как се управлява фирмата. Обикновено у нас повечето приходи отиват за управляващото тяло на фирмата и не се влагат в кадърни специалисти. Наемат се какви да са хора като критерия е да не искат много пари. Това води до силно текучество, невъзможност за задържане на кадърните кадри и се изпада в омягьосания кръг на посредствените кадри. Заложените разходи за обслужване на клиента също са като правило ниски. Осигурява се доста семпла поддържка, която трябва да накара клиента да се чувства виновен, че изобщо иска разрешаване на свой проблем. Истината е, че у нас все още няма наистина "фантатична" поддръжка, каквато например има във Великобритания. Не се наемат хора, които да знаят как точно да осъществят поддръжката. Вина за това положение на нещата има начина на мислене: ръководството на доставчиците знае, че клиентите са идиоти и ги разглежда като гъби, които трябва да бъдат изтискани до последно; клиентите в повечето случаи са непретенциозни, не знаят какво искат и ги удовлетворява положението "едно порно на ден, кърваво екшънче, повечко чалга и 'да загеймим' до пълно изпростяване".

Услугите се предлагат на принципа на ограничаването. Това значи, че за по-малко пари ти се предлага услуга с повече ограничения. Тук не говоря за ограничения по скорост. Говоря за чисто техлогични спънки, които биват създавани на потребителя, за да няма той нормален (не високоскоростен) достъп до Интернет. Орязване на портове и протоколи е масова практика в родните доставчици. Рязане на GRE пртокола за капсулация е също нещо, което може да се характеризира у нас като "стар народен обичай". Забележете, че достъпа до някой си порт например, не натоварва с нищо маршрутизаторите на доставчика (освен ако не са настроени рядко глупаво). Ограничаването по скорост на клиента се базира на броене на битовете информация преминали от и към него. За доставчиците у нас все още по-добрата услуга е тази, която предлага по-малко ограничения. Забележете, че тук схемата на печалба не идва от качеството. Доставчикът купува чист канал с накакво качество. След това ограничава достъпа през него (така калкулира разходи) и обявява снижения достъп като по-изгодна ценова услуга. Т.е. той формира някаква своя гледна точка за това какво е Интернет и я налага на клиента срещу цена, която се внушава за по-изгодна за клиента.

За прозрачни проксита няма да говоря. При този богат на съдържание Интернет в момента, да се ползва прокси сървър по подразбиране, е меко казано простотия. Направете си сметка сами. При все по-голямо разнообразие от съдържание, вероятността един обект от кеша да бъде извикан втори път е много малка. Така се напълва дисково съдържание върху прокси сървъра, което на практика не се използва повторно, а това което се използва повторно не може да оправдае дори електроенергията изразходвана от този сървър. За моя радост в София повечето доставчици са махнали прозрачните проксита.

Още имам спомени от идиотиите и мегакретениите на разни доставчици, свързани с IRC войни. Да бъдеш уникално прост не е лесно. От това време датират и прозрачни DNS сървъри, които трябва да направят така, че да не можеш да влезеш на IRC сървъра на конкурентната IRC мрежа. Тази небивала простотия все още стои по някои "местни" LAN доставчици и показва за каква услуга си говорим.

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



3. Технически аспекти на доставката

Преди да продължа с тази част искам да кажа, че бях дълбоко учуден, че няма бомбен атентат срещу някой краен доставчик, извършен от негови клиенти по особено жесток и брутален начин. Това учудване обаче премина, след като си оформих ясна картина за това какви са потребителите в тази страна. Тези потребители просто плачат да бъдат лъгани, крадени, унижавани, бити, подтискани и т.н. И причината е, че те нямат манталитета на граждани в едно реално гражданско общество, където всеки си търси правата, включително и тези на потребител.

В момента има две полулярни форми на свързване на крайните клиент - модем и LAN адаптор.

Модеми: кабелни модеми и ADSL модеми. Това са някакви остатъци от миналото, които не знам защо толкова се харчат и рекламират. Кабелните модеми, чрез които се извършва доставката на свързаност към Интернет през коаксиалните среди на доставчиците на кабелна телевизия са пълна технологична отживелица. Аз не мога да повярвам, че в момента има интерес към подобна форма на свързване. Това е една силно асиметрична услуга (по отношение на скоростта downstream/upstream) и качеството много силно зависи от много странични фактори, които трудно могат да се контролират (качеството на преносната среда). Устройствата за осъществяване на обратен канал в коаксиалната среда да прекалено скъпи. Кабелните модеми са прекалено скъпи. От друга страна ADSL модемите (реализират PPP over ATM), са малко по-добри в някои отношения, но отново при тях има силна асиметрия и много зависи на какво разстояние от ATM концентратора се намира клиента. Максимално достижимата скорост в преносната среда на БТК е около 5 Mbps. Не съм чувал за скорости до 7 Mbps, освен ако БТК не си ги реализират в помещението, където им е ATM концентратора. И при тях асиметрията downstream/upstream е много голяма. Един от основните проблеми при модемите споменати тук, е високата стойност RTT (Round-Trip delay Time) и силната девиация на RTT за обменяните пакети. (RTT си го представете като голямо време на отговор при ping).

LAN: По замисъл хората свързани по етернет стандарта чрез LAN адаптор, трябва да използват най-добрата за момента услуга за домашни клиенти (че и за корпоративни, в повечето случаи). Истината е, че етернет среда за пренос се гради с изключително много опит, който повечето доставчици у нас нямат, защото нямат кадри, които да го направят (а нямат кадри, защото не искат да им плащат добре и да им осигурят среда за развитие). Изключителна субкултурна педерастия е, да имаш едно трасе, с един етернет сегмент в него и да пуснеш в него 802.1q капсулация (известна много като VLAN стандарт). Това обременява преноса на рамки в този сегмент с 4 байта (товари и комутаторите на пакети безмислено). Мислите си, че това е малко на фона на максималния размер на рамката от 1518 байта? Лъжете се. Проблемът ясно изниква при комуникации с малки като размер пакети (примерно телефония, някои мултимедийни услуги), където тези 4 байта са сравнително голяма относителна част от общия трафик в самия етернет сегмент. Друга уникална простотия е да имаш при клиента MTU=1500 байта, такова да е MTU на файловия сървър, а някъде по средата на "високоскоростното" трасе MTU да спада до 1476 байта и когато клиентите затеглят любимите си филмчета (и пакетите с трансфера станат точно равни на MTU), да се получи високо ниво на фрагментация, което да смали ефективния трафик с доста проценти и да мори маршрутизаторите. Безкрайто тъпи изпълнения са тези с разпределението на скоростта. На едно трасе с капацитет N клиента, се закачат N+100 клиента. Вследствие на това се наблюдават ужасно неприятни загуби на пакети (девиациите в скоростта са ужасни). Примерно, представете си да кажем LAN доставчик със загуба от 20% пакети в мрежата си. Всеки знае, че профила на скоростта от доставчика на свързаност до клиента се проектира да е пресечено конусовиден, насочен с върха към клиента. При нашите LAN доставчци, профилът е цилиндричен. Абсурдните схеми, с които доставчиците целят да ограничат torrent клиентите, товарят излишно маршрутизаторите и комутаторите и не само не спират torrent потоците, но и влошават другите услуги. За т.нар. "шейпъри" (баси и българската дума, а) не искам да се нервирам излишно и да обяснявам какви идиотски схеми за контрол на скоростта могат да се измислят. В 1% само се използват u32 селектори. Всички са безумно влюбени във flowid и само това може да обясни защо една задача по селекция на пакети, която може да се направи в tc направо чрез u32 или u8 селектор, трябва да се прави първо през netfilter с iptables и чак тогава чрез tc.



4. Какво следва?

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

Всички кабелни модеми, LAN-ове с неизяснено качество на услугите вече са пътници. Те са такива, защото идва пазара на IP базирани медийни услуги, които изискват високоскоростни трасета с ясни параметри. Така, че забравете за Суперлюбовци и с ADSL-и от миналото, забравете за Евротур с модемите им за коаксиални мрежи, забравете за квартални LAN-ове с 20% загуби на пакети и не сключвайте никакви дългосрочни договори. Още от пролетта нещата ще започнат да се променят и ще е тъпо да се окажете прецакани с дългосрочен договор за услуга с ниско или никакво качество. Аз не виждам нормален човек, който в момента ще сключи двугодишен договор с БТК за ADSL модем, след като само след 6 месеца тази услуга ще е безкрайно остаряла.



Благодаря за вниманието и не поднасям никакви извинения на засегнатите.

Нали знаеш, че Sellinet е по-правилно да се изговаря като "селонет" и е безпредметно със селяндури да говориш за Интернет и за услуга различна от реализиране на огромни капацитети с мултимедия и нелицензирано съдържание. Ако си намислил сериозно да се занимаваш с DNS, можем да помислим къде да хостнем една твоя машина, която да прави само това, което искаш да прави. Има доста хора тук, които могат да ти помогнат... надявам се ще се намерят такива.

Общо взето, от всички книги по темата "Криптография", които са написани от български автори, единствено тази си заслужава:

http://www.digsys.bg/bgnews....9216361

Преди я имаше на хартиен носител в книжарницата на ФМИ. От екран се чете доста трудно. В нея обаче има доста остарели неща.

Никола, все едно дали ще приемеш изказването ми за високомерно, но в цитираната статия има такива откровени глупости, че един човек с поне леки познания в системата за имена в Интернет, ще ги види от пръв прочит (те направо вадят очи). И понеже казваш да се огледаме и да видим кой колко (и с какво) е виновен, аз лично не намирам изобщо в себе си вина за това, че някой преписва без да знае. Осведомеността и знанията са индивидуални придобивки, които всеки сам изгражда в себе си и не може да се търси вината в другите за това, че те не са налице, особено като говорим за пораснали хора. Да, не съм за цензурата, но след като няма цензура на новините, има пък такива теми по форумите и коментари с това съдържание. Така поне се получава обратна връзка и ако в цялата тази работа има преценка и трезв разум, то тази връзка би се взела предвид от тези, които пускат новини и те не би следвално да преписват глупости (особено след като същите преписвачи обясняват на някого как говорел глупости).

По-добре една новина да бъде странна, отколкото глупава. Ако някакво общество (идейно, техническо) иска да бъде приемано насериозно, то не може да си позволи подобно непукиско отношение към материалите от типа "linux-bg.org is not perfect". Такова отношение е пещерно и нямащо нищо общо с действителността и не помага на тази общност по никакъв реален начин, напротив.

Трябва да се търсят начини - стига толкова оправдания.