K210.ORG

Итак, я стал смотреть, по каким же запросам попадают ко мне начинающие «разработчики велосипедов», и постарался осветить некоторые вещи, которые для меня самого были неочевидны в начале работ.



1. MVC — наше все!

Где бы не заходил разговор о разработке веб приложений, сразу же всплывает модная аббревиатура MVC (Model-View-Controller). Этот подход гласит, что интерфейс надо отделять от логики, а логику от данных. Не скажу, что я в полной мере проникся этими идеями, но то, что изменения в дизайне (или даже дизайнах) не должны затрагивать логику кода — я готов отстаивать с пеной у рта:)

Вот тут и покоятся грабли номер один: внешний вид надо отделить от логики программы. Как это сделать — каждый решает для себя сам. По этому вопросу копий сломано не мало: тут и различные шаблонизаторы, и xslt преобразования, и просто php+html вынесенные в отдельные файлы. Выбор большой, но «серебряной пули», как водится, не существует: на одной чаше весов лежит гибкость, на другой — понятность. Даже Smarty, с его «программированием для самых маленьких» многим пользователям кажется сложным. Так что если мы ориентируемся на пользователя, который хочет поставить системы «из коробки» и подпилить ее для своих нужд с минимальными знаниями программирования, то тут стоит поломать голову.

Кроме того, дизайны должны быть заменяемые и, возможно, даже «на лету». То есть нужно предусмотреть их удобное хранение и редактирование. И еще одна вещь, которая многими проигнорирована: дизайн должен быть легко редактируем и обновляем. Если вам приходилось адаптировать дизайн какого-нибудь бесплатного форума, состоящего из двух сотен шаблонов, в которых все намертво «прибито» таблицами и откуда-то «из логики» вставляются куски JavaScript, то вы понимаете, что именно видеть не хочется.

Я придумал такую конструкцию: в пользовательском дизайне присутствует только то, чего нет в базовом дизайне. То есть в самом минималистичном случае дизайн состоит из пустого каталога с названием дизайна. Понятно, что в этом случае дизайн будет выглядеть в точности так же как базовый, так как все недостающие части будут позаимствованы от него, но как отправная точка — это очень удобно. Если в дизайне появляется css, то система автоматически переключается на него (при этом html все равно заимствует из базового). Тоже самое и с JS. Что мы получаем при этом: в пользовательском дизайне лежат только те файлы, которые он сам сделал. Пользователю не надо помнить, какой файл он исправлял, а какой попросту скопировал из базового дизайна в начале работы. Так же на сайте отображаются практически все нововведения базового дизайна без правки пользовательского. Мне такая система показалось удобной и логичной, хотя некоторым она кажется несколько неожиданной. Взять ли ее на вооружение или придумать свою — решать вам.

2. Структура сайта

Приступаем к написанию ядра. Что должно делать ядро? А делать оно должно всю «грязную» работу: определять настройки сайта, права и настройки групп пользователей, используемые модули, шаблоны, параметры кэширования, локализации и т.п. То есть, чтобы к тому моменту как начинали работать подключаемые модули, они могли получить все интересующую их информацию от ядра. Звучит жутковато, но все это сравнительно легко пишется и работает, если четко представляешь себе взаимодействие элементов.

 

Я для себя решил, что сайт будет представлять собой не кучу страниц, сваленных куда-то в БД, а строгую иерархию. В итоге структура сайта древовидная и недостающие части, как и в случае с дизайнами, наследуются от родителей. Структура групп пользователей тоже древовидная — права и настройки так же наследуются от родителей. Файлы локализаций и модули так же имеют простенькую иерархию. Четкая иерархия позволила переложить на движок всякие неприятные вещи типа автоматической генерации карты сайта, различных меню, раздачу прав (да-да: чтобы дать право на что-то нескольким группам, совсем не обязательно редактировать каждую — достаточно определить иерархию) и т.п. Живи да радуйся! И все бы ничего, если бы не грабли:

Грабли первые. Кэширование.

Пока занимался проектированием своего «мегадвижка» было как-то не до кэширования… Да и подумаешь — что там сложного? Поместил страницу в переменную, сохранил ее в файл, а в следующий раз ее оттуда показал. Делов-то… в любой момент можно приделать! Ой… а у нас для зарегистрированных пользователей другая страница… Гм… ну подумаешь — две страницы в кэш сохраним! А еще в шапке надо вывести «привет, Вася»… ну значит этот фрагмент в шапке не кэшировать. и такой же фрагмент в подвале… и в середине… Мда… Я еще бы надо разные части страницы кэшировать на разные сроки… Садимся и переписываем движок и систему кэширования на кэширование блоками — чтобы каждый блок имел свой срок жизни.

Грабли вторые. Кэширование.

Как?! Опять кэширование? Уже ведь сделали все красиво! Ну да… сделали… и оно даже работало, пока не встала задача генерировать контент для каждого пользователя на основе его личных настроек. Размер кэша при этом растет со скоростью реактивного истребителя, а его содержимое устаревает много раньше, чем будет запрошено повторно. Вместо ускорения сайта получаем его замедление, и гигабайты никому не нужных кэшированных страниц… Главным скриптом на сайте становится «его величество» инвалидатор кэша. Мда… переписываем движок снова: на этот раз реализуем кэширование на уровне запросов к БД, так как это самое узкое место в производительности. Переписали… все — нирвана.

Грабли третьи. Кэширование.

Смотришь на свое творение и чувствуешь себя полным идиотом: вместо того чтобы сохранить страницу целиком, каждый раз ее создаю. А ведь кэширование задумывалось с точностью для обратного! Как же я так лопухнул-то?

Результатом в итоге явилось то, что некоторые модули кэшируются блоками, а некоторые — на уровне запросов. Это позволило месяцами хранить в кэше такие редкоизменяемые вещи как, например, меню сайта.

Урок же для себя я вынес такой: систему надо изначально проектировать таким образом, чтобы на определенных этапах исполнения иметь сгруппированные данные, которые можно легко положить в кэш или взять оттуда. Так же система кэширования не должна быть жестко завязана на движок, так как сегодня вполне достаточно хранить кэш в файлах, а завтра (или даже сегодня вечером) уже подавай работу с memcache-сервером.

 

В процессе написания движка так же имеет смысл почитать умную книжку про рефакторинг… или почитать ее после написания движка. В любом случае, всем троим (вам, движку и книжке) это может пойти на пользу.

3. Модульность.

Современную систему тяжело представить как «вещь в себе» — она должна иметь интерфейсы для расширения своего функционала. Таким образом, мы переходим к самой вкусной части CMS — написание модулей. Тут тоже полно вопросов: как должен выглядеть модуль, как подключаться к системе и т.п.
В некоторых системах вызов модулей жестко прописан в ядре системы, так что если ты хочешь написать модуль или установить сторонний, то залезайте в исходный код, вооружайтесь мануалом по установке и вписывайте в код соответствующие вызовы. При всем идиотизме подхода, многие системы именно так и функционируют. Есть вариация этого решения: каждый модуль — это отдельный файл в некоем каталоге. В этом случае мы получаем не просто необходимость прописать модуль в ядро, но еще и выполнить его в виде одного файла. Еще встречались варианты с активными шаблонами: то есть вписали в шаблон {module_name} и когда парсер дошел до этого тега — вызывается на исполнение модуль module_name, результат работы которого оказывается на месте тега. Возможно, такой путь и удобен, но в данном случае мы не только не отделили логику от представления, но как раз наоборот — хорошенько их перемешали.

После определенного количества шишек я пришел к системе, которая, возможно, и не является образцом лаконичности и простоты, но мне видится достаточно удобной. Каждый модуль — это отдельный каталог, из которого ядром вызывается всего один файл (index.php). Данный файл может, как выводить «Hello world!», так и подключать файлы управления гиперпространственным квазиизлучателем — это уже как разработчику модуля будет удобно. В том же каталоге лежит xml файл с описанием параметров модуля, возможных настроек и системой прав. Этот файл используется для того, чтобы система могла сама добавлять модули и не перекладывать эту головную боль на пользователя: нажал кнопку «установить модуль» — пожалуйста, получите.

С установкой разобрались. Встает новая проблема — как не позволить пользователю разместить на одной странице, скажем, фотоальбом и, например, форум? К здравому смыслу уповать бесполезно, поэтому нужна типизация модулей. Модуль такого-то типа (я для таких модулей где-то подсмотрел понятие «компонент») может быть на странице только один.

Ну хорошо, компонент на странице будет только один, но остальных-то может быть много — в каком порядке они должны подключаться? Ведь будет глупо, если модуль какой-нибудь переключалки скинов, который в конце своей работы перекидывает пользователя на главную страницу сайта, подключится после того, как отработает модуль анализа динамики поголовья кроликов в брачный период — и результатов анализа не увидим, и время на расчеты потратим. Следовательно, у модулей должен быть оговорен порядок их подключения.

Некоторые вводят для этого аналог никсового runlevel, где для каждого модуля надо прописать между какими именно модулями он должен быть подключен. Как пользователя, меня такое решение повергло в прострацию, но как разработчик я придумал почти тоже самое: модули разделены на три больших группы. Одна из групп — уже упоминавшийся «компонент», две других отличаются только тем, что модули одной группы подключаются до компонента, а другой — после. Причем, это разделение от пользователя я скрыл, так что для него остались только «компонент» и «просто модуль».

Итак, модуль спроектировали, с подключением определились… Теперь надо решить как его настраивать и как к нему допускать. А тут как раз все просто: раз уж у нас ядро предназначено для «грязной» работы, то пусть у него голова и болит — модуль в xml выдал список настроек, а ядро пускай его разбирает, хранит и предоставляет по запросу — тут как раз все просто.

Еще одна проблема, с которой я столкнулся в процессе разработки — передача данных между модулями. По условиям задачки они ничего друг о друге не знают и вызываются ядром в порядке номерков. А вот хочется передать из одного модуля в другой весточку! Для этого я ввел специальный класс для глобальных переменных, куда каждый желающий модуль может что-то сохранить на память тем, кто придет после него. Вот такое, возможно, не очень элегантное решение.

4. Обновления

Всегда хочется иметь самую свежую версию, но совершать для этого минимум телодвижений. Отсюда вытекает желание автоматизировать процесс обновлений. И тут опять существует пусть и не очень обширный, но все же зоопарк решений. Самые прогрессивные предлагают поставить на все каталоги права 777, а на файлы — 666 и тогда «скрипт сам все сделает». То что это дыра в безопасности размером с Гранд Каньон, в общем, никого не волнует.

У меня были идеи относительно двух вариантов: скрипт скачивает обновления во временную директорию, а потом, запросив у пользователя параметры доступа к FTP, обновляет сам себя. Так ему и прав лишних давать не надо, и происходит все автоматически, и обновления гоняются в пределах сервера… вот только придется либо каждый раз запрашивать у пользователя параметры доступа к FTP, либо хранить их тут же на сайте… то есть, все яйца в одной корзине. Поэтому я предпочел другой вариант: пользователь сам скачивает обновления (архивом или через svn), заливает их на сайт, а код на сайте, почувствовав что он стал «новее» вносит необходимые исправления в БД и/или настройки… А первый вариант все же был красивее… но не отважился я.

Это самые запомнившиеся вехи моего «велосипедостроения». Читая это я очень жалею, что в начале работы я не встретил чего-то подобного, а у меня самого было недостаточно опыта и шишек чтобы задать «правильные» вопросы. То что у меня получилось в итоге, вы можете посмотреть здесь и, если у вас появились вопросы, то я готов на них ответить.

Кстати, если у вас появились ответы на незаданные вопросы — я их тоже с удовольствием выслушаю. Ведь опыт — известно, чей сын, а все ошибки совершить в одиночку почти невозможно;)

(c)

Это правильный подход, но 5% на большом диске – это достаточно много: например, из 500 ГБ в резерв уйдут 25!
Кроме того, нет смысла бронировать место там, где не может быть файлов root, например, разделе /home.
Хорошая новость – величина 5% не является жестко зашитой в код ОС, и вы можете менять ее на лету, не рискуя потерять файлы с данными.

Для подстройки параметров файловых систем ext2 и ext3 используется утилита tune2fs.
Она позволяет менять метку тома или порог числа монтирований, после которого автоматически будет запускаться fsck, а также более экзотические настройки.
Нам помогут опции -m и -r.
Первая устанавливает процент блоков ФС, резервируемых для пользователя root, а вторая задает их абсолютное количество.
Поэтому tune2fs -m 2 /dev/sda1 сокращает «бронь root» до 2%, что может оказаться полезным, если у вас объемный раздел / или /var.

Рекомендуем к использованию, если у вас жесткий диск на 500 ГБ или больше.   
Другая команда, tune2fs -r 0 /dev/sda1 отменяет резервирование блоков в файловой системе, а потому подойдет для /home, где не может быть файлов суперпользователя.

(c)

Thanks for the reply. Here's what I did:

# nano /var/lib/polkit-1/localauthority/50-local.d/shutdown.pkla

[system shutdown privs]
Identity=unix-group:users
Action=org.freedesktop.consolekit.system.stop-multiple-users
ResultAny=no
ResultInactive=no
ResultActive=yes

# nano /var/lib/polkit-1/localauthority/50-local.d/restart.pkla

[system restart privs]
Identity=unix-group:users
Action=org.freedesktop.consolekit.system.restart-multiple-users
ResultAny=no
ResultInactive=no
ResultActive=yes

After a restart of hal everything works!  THANKS AGAIN!  I added this great information to the Gnome 2.28 Changes wiki article.  Hopefully others will find it useful.

(c)

устанавливаем Virtualbox

Для Ubuntu документацией рекомендовано иметь Dynamic Kernel Module Support (DKMS)

apt-get install dkms

Скачиваем с http://www.virtualbox.org/ наиболее подходящий пакет. Для 10.10 virtualbox-3.2_3.2.10-66523~Ubuntu~maverick_i386.deb

dpkg -i /путь/virtualbox-3.2_3.2.10-66523~Ubuntu~maverick_i386.deb

он скажет что надо доустановить и пометит для установки пакеты

apt-get -f install

установит все пакеты

создаем гостя с именем ubuntu_srv001

VBoxManage createvm --name "ubuntu_srv001" --register

Конфигурация гостя

VBoxManage modifyvm "ubuntu_srv001" --memory 256 --acpi on --boot1 dvd --nic1 bridged

тип ОС — Ubuntu Линукс (смотреть типы VBoxManage list ostypes )

VBoxManage modifyvm "ubuntu_srv001" --ostype ubuntu

Создаем фиксированный жесткий диск 7Гб для гостя

VBoxManage createhd --filename "ubuntu_srv001.vdi" --size 7000 --variant fixed --remember

Установим созданный файл ubuntu_srv001.vdi первым виртуальным жестким диском SATA

VBoxManage modifyvm "ubuntu_srv001" --sata on --sataportcount 30 --sataport1 "ubuntu_srv001.vdi"

Зарегистрируем контроллер IDE для DVD

VBoxManage storagectl "ubuntu_srv001" --name IDE0 --add ide

Зарегистрируем ISO файл с устанавливаемой ОС

VBoxManage openmedium dvd /export/distrib/OS/Ubuntu/ubuntu-10.10-server-i386.iso

Подключим этот ISO к виртуальной машине

VBoxManage storageattach "ubuntu_srv001" --storagectl "IDE0" --port 1 --device 0 --type dvddrive --medium /export/distrib/OS/Ubuntu/ubuntu-10.10-server-i386.iso

Включаем доступ к экрану виртуальной машины по RDP (стандартный порт 3389 поменяем, если виртуальных машин несколько, надо для каждой свой порт)

VBoxManage modifyvm "ubuntu_srv001" --vrdp on --vrdpport 3390

Пришло премя стартовать установку гостевой ОС

VBoxHeadless -startvm "ubuntu_srv001"

срочно включаем терминальную RDP сессию

В windows mstsc /v:host:port в linux rdesktop host:port

Все работаем …....................

установили систему с образа, делаем загрузку гостя с жесткого диска

VBoxManage modifyvm "ubuntu_srv001" --boot1 disk

диск с VboxGuestAdditions лежит здесь /usr/share/virtualbox/VBoxGuestAdditions.iso. Нужен он при установке графической среды.

Клонирование Виртуальных серверов VirtualBox .

У нас есть виртуальная машина ubuntu_srv001 с виртуальным диском ubuntu_srv001.vdi

Клонируем диск с системой.

VBoxManage clonehd ubuntu_srv001.vdi ubuntu_srv002.vdi

Регистрируем новую машину с аналогичными параметрами

VBoxManage createvm --name "ubuntu_srv002" -register
VBoxManage modifyvm "ubuntu_srv002" --memory 256 --acpi on --boot1 disk --nic1 bridged
VBoxManage modifyvm "ubuntu_srv002" --ostype ubuntu
VBoxManage modifyvm "ubuntu_srv002" --sata on --sataportcount 30 --sataport1 "ubuntu_srv002.vdi"

( VBoxManage storagectl ubuntu_srv002 --name SATA —remove если ошибся виртуальный диск всегда можно отцепить.)

VBoxManage modifyvm "ubuntu_srv002" --vrdp on --vrdpport 3391 (порт у каждой машины свой)

VBoxHeadless -startvm ubuntu_srv002 --vrdp=on > /dev/null 2>&1 &

зайдем на клона (оригинал пока выключен) mstsc /v:host:3391

/nano /etc/network/interfaces

меняем параметры tcpip у машин не должны совпадать ip

командой hostname newname меняем имя сервера, имена не должны повторятся

/etc/init.d/networking restart перезапустит сеть

Все . Можно использовать два виртуальных сервера.

Посмотреть список запущенных виртуальных машин VBoxManage list runningvms

Виртуальные машины в качестве службы

Для корректного вызова завершения работы виртуальной машины с консоли хоста я сначала пользовался VBoxManage controlvm ubuntu_srv001 poweroff лишь спустя время я вычитал, что способ аналогичен обрыву питания на реальном компьютере.

Другой способ, более надежный требует установки пакета управления питанием на виртуальную машину apt-get install acpid.

Старт службы acpid start.

Если мы автоматически стартуем эту службу на виртуальной машине, то имеем возможность корректно завершить ее работу нажав виртуальную кнопку выключения c машины хоста.

VBoxManage controlvm ubuntu_srv001 acpipowerbutton

Теперь хочется рассказать о процессе регистрации виртуальных машин в качестве службы.

Я делаю через webmin, потому, что очень быстро и просто.(Webmin не панацея для всего,не все можно быстро настроить через webmin)

Заходим на хост сервер через https://хост:10000/ рутом.

Раздел System → Bootup and Shutdown → Create a new bootup and shutdown action.

Придумаем имя службы

Bootup commands (в качестве запуска)VBoxHeadless -startvm ubuntu_srv001 --vrdp=on > /dev/null 2>&1 &

Shutdown commands (остановка) VBoxManage controlvm ubuntu_srv001 acpipowerbutton

в конце кнопка Create

Все проверяйте /etc/init.d/имя_службы start запуск виртуальной машины /etc/init.d/имя_службы stop остановка.

При таком раскладе перед перезагрузкой хоста не обязательно выключать гостевые сервера. Они корректно завершат работу автоматически.

(c)

Да Utorrent является плохо созданной программой, вернее та его часть которая отвечает за сетевое взаимодействие и которая создает вам проблемы с которыми вы еще не сталкивались.. пока не перешли на скоростные тарифы.

Другой штрих маслом.. представьте себе инженера проектирующего НЕДОРОГОЙ роутер, ADSL модем со встроенным роутером ну и прочую недорогую дрянь.. что от него требуется? Правильно удовлетворить ТЗ (тех.задание) уложившись в скромный бюджет.. Оборудование то для вас и вы не потратите 700 баксов на хрень в коробке.. вы потратите максимум 100. Вот он (инженер) и засовывает в коробку с надписью МАРШРУТИЗАТОР (ROUTER) комплектующие из самого низкого ценового диапазона… но не сссыте.. коробка то используется классная.. белая, с антенкой и вся вообще зае*ическая.. )) Короче внутри коробки комплектующие и микропрограмма с заявленной поддержкой ADSL 2+ что подразумевает работу на 24 мегабитах.. ан нет у вас не работает.. волнами идет торрент… (кстати попробуйте объяснить как волнами идет тех поддержке.. и не забудьте добавить что не было ни единого разрыва.. ну для антуража ))

Я своему другу кстати который работает в Укртелекоме проблему изложил, но он простой монтер который меряет затухание меняет розетки, настраивает роутеры.. но теперь если к нему обратятся абоненты с жалобами что торрент на ваших новых тарифах НЕ КАЧАЕТ ответит грамотно.. а не*уй качать нелицензиооный контент.. ах хахаха..
Ладно вернемся к проблеме.. коробка с логотипом ADSL 2+ не работает на заявленных скоростях.
Можно обвинить Укртелеком.. попробуйте позвоните и скажите, что вас наЫбали. Вас вежливо попросят не расстраиваться сейчас мир такой..

Но кто-то же вас наи.. кто-то сделал это с вами.. коробка ведь упорно не работает и сбоит.
Мой вам совет не качайте нелицензионный контент… ну или думайте.
Вернемся к инженеру который собирает коробку.. ТЗ выполнил в бюджет уложился, а коробка не работает на 24 мегабитах.. а на 8 работает.. значит инженер сделал с нами это ужасное, он нас отимел за наши же 100 $ прекрасный ход.. но не он. Сейчас мы разберемся кто.

Вернемся к интернету. Что такое это интернет.. пользователи рас..(рас рас рас).. провайдеры два.. контент (то к чему стремятся пользователи) три ну если вспомнить еще то: производители кабельного оборудования, маршрутизаторов (серьезных.. не тех что стоят у вас под диваном)

Производители Серверов, и производители ПО последние по большому счету делятся на производителей сервисного ПО которое обслуживает маршрутизаторы и серверы и прикладного ПО - то что крутится у вас на компьютерах..
Те что пишут программки для серверов и маршрутизаторов обычно десятилетиями работают на одну контору в одной области.. примеры CISCO JUNIPER HUAWEI IBM и т.д. это суровые ребята творящие код по гостам и правилам..
Те что пишут прикладные программы в том числе и те которые требуют сетевого взаимодействия часто самоучки осененные гениальными идеями.. нет я не спорю и среди них есть профессионалы но довольно часто это сумасброды.. оставим штрих про программистов и вернемся к интернету..

Кабеля роутеры компьютеры.. все это хозяйство работает вместе благодаря сетевому взаимодействию, а именно обмену так называемыми «сетевым пакетами» набору битов с «заголовком». Заголовок составлен по определенным правилам, что бы не вдаваться в подробности примерно так <как:куда:кому:> .. и далее сама информация. Правила составления и обработки сетевых пакетов конечным оборудованием (на пример компьютерами) и промежуточным оборудованием (чаще всего это спец компьютеры называемые роутерами на англ манер или маршрутизаторами) называются ПРОТОКОЛОМ. В интернете ПРОТОКОЛ взаимодействия строго говоря не один и потому набор протоколов (правил обработки пакетов напоминаю) называется СТЕКОМ ПРОТОКОЛОВ и тот что сейчас широко распространен и является стандартом де-факто носит название TCP\IP поподробней советую прочитать тут http://ru.wikipedia.org/wiki/TCP/IP.

ТCP\IP разрабатывается уже более 30 лет (точную цифру не помню) и все дополнения к первоначальной версии протокола носят вид RFC (Request for Comments) “ запрос на обсуждение» т.е. кто-то (человек либо организация) вносят предложение, заинтересованные стороны (разработчики маршрутизаторов, ПО к ним, сетевых плат, операционных систем и т.д.) обсуждают его и приходят к единому решению, которое затем находит воплощение в разрабатываемой продукции и на продукции появляется логотип а-ля «к чему-то там READY» (подробно читать тут http://ru.wikipedia.org/wiki/RFC)

Так вот протокол TCP\IP прошел долгий путь и оброс массой дополнения в виде RFC большинство из которых реализовано в современных роутерах, сетевых платах и операционных системах.

Но развитие ИНТЕРНЕТА как среды обмена идеями и реализацией идей в виде программ и медиа продукции (фильмы, музыка и т.д.) наткнулось на обычную человеческую жадность, которая к слову сказать так же как и лень является двигателем прогресса.. ведь если кто-то снял хороший фильм потратив на это либо деньги либо время (кстати я ведь сейчас тоже составляю хорошее медиа что бы вы прочли и сэкономили десятки и то и сотни часов на изучение вопроса) получили с этого отдачу, моральную либо материальную.. но моральную никто не хочет т.к. не ликвид, в холодильник не положишь, и предпочитают материальную.. т.к. на тэньге легко купить себе отдых развлечение или сэкономить время.. и ЭТИ ПРАВООБЛАДАТЕЛИ стали бороться с (нет не с интернетом он им самим нужен для рекламы своей продукции) с теми кто размещал на своих серверах ворованное видео, программы .. сначала это носило стихийный характер, но со временем почти все государства на законодательном уровне промаркировали незаконные действия в интернете и приравняли часть из них к нарушению авторских прав за что светят или космические штрафы или отсидка за решеткой… государственные машины многих стан реорганизовались и появились такие как отдел К в России кибервойска в США и т.д. то есть за интернтом стали пристально следить и скачать откуда-нибудь файлик стало делом опасным.

Народ вообще быстро реагирует на всяческие ограничения физического или морального плана, т.к. народы стран и особо грамотные индивиды это и есть цивилизация человеческая, и уж точно не госаппарат представляет цивилизацию. Так вот группа индивидов объединенная интернетом выдумала TORRENT протокол, который позволял обмениваться файлами находящимися на компьютерах пользователей. Опущу то что было до торрентов, типа Edonkey и других, но они явились лишь ступенькой к технологии которую все знают сейчас как торрент.

В общем по мере развития провайдеров и борьбы за пользователей скорости на которых эти самые пользователи стали быть подключены к интернету стали стремительно увеличиваться, количество нелегального контента и его объемы так же стали стремительно увеличиваться.. и вот уже для высоких скоростей обмена информацией по технологии торрент программам (в частности Utorrent установленной не менее чем на двух третях пользователей технологии) стало откровенно неуютно в рамках протокола TCP\IP разработчики Utorrent так и предложили давайте РАДИКАЛЬНО изменим TCP\IP, но с этим не согласились ни производители маршрутизаторов ни операционных систем.. да и вообще радикально сейчас что-то менять в интернете опасно, т.к. инфраструктура многих стран НЕ СМОЖЕТ ФУНКЦИОНИРОВАТЬ без интернета.. начнутся сбои в работе самых различных предприятий и «институтов государственности» человечество подсадило себя на иглу электричества нефти и интернета.. короче разрабов Utorrent послали с их революцией подальше практически все..

Ребята не расстроились и смастерили свой прикладной протокол uTP который работал поверх протокола UDP, так же входящего в стек TCP\IP . Плохой стороной реализации явилось то, что велосипед изобретался второй раз.. разработчики изобретали TCP\IP но без тех недостатков, которые они считали недостатками. Усилий они приложили откровенно мало.
Не буду копипастить, а дам просто две ссылки на описание проблем протокола uTP http://nuclight.live...com/125372.html
http://torrentblog.r...oix-obeshhanij/

если эти ссылки не читать, то коротко я вам скажу что в результате работы протокола uTP в течении 2-5 минут размер передаваемого пакета уменьшается до 200-300 байт при максимальном разрешенном размере для PPP соединений в 1492 байта и таким образом например на полтора мегабайта информации приходится уже не 1000 пкетов, а 5000 пакетов. С увеличением пропускной способности на тарифе Ultra возросло количество преобразований NAT когда ваш и мой в том числе ADSL роутер откидывает серый IP адрес внутреннего интерфейса и подставляет реальный IP адрес внешнего интерфейса..
ТАКИМ ОБРАЗОМ критичным параметром для роутера становится количество пакетов в секунду PPS (packets per second) и в результате работы Utorrent 2.0 этот параметр прыгает до небес, конечно в случае перехода на новый тариф от Укртелекома, на 8 мегабитах мой ASUS WL-600g еще справлялся а на 24 уже нет… ситуация банально просто.. малое ОЗУ и низкое быстродействие процессора установленного в красивую белую коробку.. ОЗУ переполняется очередью пакетов на NAT преобразование и роутер переходит на 1-2 сек в режим так называемой блокировки (отказа в обслуживании) пока не разгребет очередь.. кстати даже промышленные дорогие роутеры в важных узлах интернета не избежали этой участи и многие зимой жаловались на потери пакетов то в амстердаме то в лондоне то в москве… все это работа ребят из Utoreent
Вот и ответили мы на главный вопрос, кто нас отимел.. составитель ТЗ на красивую коробку с антенкой который или занизил или вообще не учел такой параметр как PPS.

Отсюда вывод который серьезные пользователи и администраторы систем знают давно не введитесь на рекламу и коробку… ни на бренд… доверяйте только информации что может устройство и из чего сделано.. скока ОЗУ какой процессор.. и т.д. удачи.

З.Ы. Если кому то покажется многа букаф то ПНХ, я старался )) пусть поддержка УТК попробует напишет что-то подобное..
З.Ы.2 совес забыл решение проблемы копеечное описано в последней ссылке

(c)