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

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

Запомните! Один запрос → Одна запись в «журнале».

Результаты операции могут быть такими (эти результаты также называются как HTTP коды):

• 200 ←- файл найден и начат процесс закачки (грубо говоря)
• 206 ←- кусок файла найден и закачка возобновлена (грубо говоря)
• 404 ←- файл не найден и никакая закачка не начата
• 503 ←- закачка запрещена (для aUmi это обозначает, что сервер насчитал уже 3 потока с вашего ip адреса, и вы пытаетесь лезть 4-ым)
  

404 и 503 ←- это ошибки, а вот 200 и 206 ←- это не ошибки. Здесь перечислены далеко не все HTTP коды. Поверьте их значительно больше. Мы отлавливаем только часто встречающиеся ошибки пользователя («клиента») и считаем их отдельно для каждого.

Если порог в 1000 ошибок уже пройден, сервер удаляет все ваши сгенерированные файлы и ставит вас в бан.

upd(26 мая 2007 года): Так как были введены нововведения (http://aumi.ru/index.php?showtopic=21168165), автобан работает различая группы пользователей:

• для «участников»: 1000 ошибок → бан
• для «Donaters»: 1000 ошибок → личка с предупреждением, 2000 ошибок → бан
• для «VIP»: 1500 ошибок → личка , 3000 ошибок → бан.
• Закачка за заначку: 5000 ошибок → личка , 10000 ошибок → бан.

а также: каждый внешний неизвестный запрос ( то есть запрос несгенерированной ссылки, или когда пользователь просто наобум рвется на d*.fenrirko.aumi.ru ) веден к бану на сутки на уровне ядра ( reject-with icmp-port-unreachable ).
Мы решили не вешать дополнительную работу на администраторов по разбаниванию пользователей и сделали специальный раздел, в котором все, кто имеет больше 10 орехов может разбанить любого из перечисленных пользователей. Раздел этот находится здесь: http://aumi.ru/index.php?autocom=banned.

Выдержка из правил закачки:
(!) Ссылки живут 5 дней со дня генерации, либо 1 день с момента последнего их использования.
Что это значит? С момента генерации (показа Вам страницы со ссылками) качать можно по ссылке только 5 дней, после семи дней ссылка удаляется и при обращении к несуществующей ссылке Вы получаете ошибку 404.
Если Вы сгенерели очень много ссылок и неуспеваете их все скачать, то при неиспользовании ссылки более суток, они тоже удаляются и при обращении к несуществующей ссылки Вы получаете ошибку 404.


Ошибки считаются суммарно, за всё время. Текущее их кол-во можно посмотреть там же, в разделе для забаненых. При снятии бана кол-во ошибок обнуляется.

Все достаточно просто.
Если вы передадите ссылку другу, а друг другому другу и т.д., то достаточно просто одному из ваших друзей ошибится в правилах закачки, и все вы в бане.
Если вы запостите ссылку на другом сайте ⇒ см. немного выше.

Данное объяснение использует несколько терминов, которые могут знать продвинутые пользователи или администраторы сетей.
Каждый сервер (будь то веб, или почта, или еще что-то) после соединения оставляет после себя TIME_WAIT на целых 120 секунд (в зависимости от настроек вашего сервера). Это фактически занятый socket. От TIME_WAIT избавится можно только если работать с SO_LINGER. Однако, в разного видах документациях написано, что использовать SO_LINGER очень и очень не желательно. А в некоторых операционных системах его вообще не реализовывают. В условиях, когда одновременных соединений очень много, TIME_WAIT-ы плодятся с огромной скоростью. И настает момент, когда процесс сервера не может создать socket. В зависимости от реализации сервера, последний может просто уничтожится, и все обслуживаемые им клиенты получат disconnection.
Уменьшение количества ложных запросов способствует более эффективной работе сервера, а также повышению качества сервиса.