Продолжим разговор (http://netlab.e2k.ru/forum/index.php?showtopic=40617&view=findpost&p=354320 об установлении ограничений на индивидуальный траффик. В идеале такие ограничения должны
(i) Способствовать сбалансированности траффика на трекере за счёт принуждения недобросовестных пользователей к добросовестности.
(ii) Сделать невыгодным оставление старых учётных записей ради регистрации новых и сквотничество (регистрацию множества учётных записей заранее).
Поскольку цель качающего, на которого требуется накладывать ограничения -его личный total_down (забудем пока об альтруистах), и объёмы скачанного квантуются размерами релизов (обычно это DVDR ~ 4GB), представляется естественным рассмотреть ограничение снизу на total_up как функцию total_down, а не наоборот. Поскольку неактивная учётная запись не приносит трекеру ни вреда, ни пользы, то "выслуга лет" в любом её виде не имеет смысла, поэтому не будем учитывать время жизни записи и потребуем, чтобы в каждый момент времени для каждой учётной записи выполнялось неравенство
(1) total_up >= f(total_down)
Цель (i) требует по меньшей мере неубывания f (больше взял - больше отдай). Чтобы новая учётная запись могла начать работу, потребуем f(0) <= 0.
Цель (ii) эквивалентна следующему условию: для любых d1,d2,...dn >= 0 имеет место
(2) f(d1 + d2 + ... + dn) <= f(d1) + f(d2) + ... + f(dn)
(т.е. для скачивания любого объёма с одной записи необходимо отдать не больше, чем для скачивания того же объёма с разных записей).
Условие (2) c очевидностью эквивалентно тому, что ля любых d1,d2 >= 0 имеет место
(2') f(d1 + d2) <= f(d1) + f(d2)
Ограничимся случаем, когда f непрерывна в 0 (разрыв в 0 не имеет практического смысла). Из (2) немедленно следует f(1/n) >= f(1)/n, что c учётом f(0) <= 0 и непрерывности f в 0 влечёт f(0)=0. (Легко проверить, что если f(0)=0, f неубывает, непрерывна в 0 и удоветворяет (2'), то она непрерывна везде).
Каковы непрерывные неубывающие от 0 в 0 фунции, удовлетворяющие условию (2)? Таковыми будут выпуклые функции (в том числе, конечно, и линейные, включая up/down рейтинг r, ведь
r<=rmin <=> total_up <= total_down*rmin), но далеко не только они (например, f(x) = {sqrt(x) на [0,1), x на [1,+inf)}).
Если потребовать от f существования второй производной в 0, то из f(0)=0 и (2') cледует f''(0)<=0. Это важно, так как отсуюда следует, что в окрестности 0 рост f(0) определяется её положительной первой производной в 0 (если она там не существует, как у f(x)=sqrt(x), то такая f не имеет практического смысла - мы слишком много требуем от только начавшего качать!). Таким образом, в 0 ограничение не может быть слабее чем линейное!
Поскольку за счёт альтруистов на толстых каналах трекер может позволить себе роскошь не требовать total_up >= total_down, можно попробовать медленно растущую f, например,
(3) f(d) = {k*d на [0,4), 2k*sqrt(d) на [4,+inf)}
Для k=1 будем иметь:
| CODE |
total_down 1 4 9 16 25 36 49 64 ...
min. total_up 1 4 6 8 10 12 14 16 ...
|
Изменяя k, получим, что в данный момент условию (1) с данными k и f не удовлетворяют L пользователей (из 2996 активных), отдавших LUp, скачавших LDn и имеющих общую задолженность LDeb (LUp, LDn и LDeb - в террабайтах, % - процент от общего числа активных пользователей, Up и Down трекера соответственно, %LUp - процент общей задолженности от закаченного f,k-"должниками"):
| CODE |
k L % LUp % LDn % LDeb %LUp
========================================================
0.1 137 4.57 0.01 0.01 0.27 0.42 0.01 103.87
0.2 334 11.15 0.07 0.10 0.80 1.22 0.05 70.62
0.3 519 17.32 0.20 0.26 1.53 2.34 0.14 69.51
0.4 713 23.80 0.40 0.52 2.29 3.50 0.28 69.91
0.5 872 29.11 0.63 0.83 2.99 4.59 0.48 74.86
0.6 1013 33.81 0.91 1.18 3.71 5.68 0.72 79.47
0.7 1142 38.12 1.21 1.57 4.38 6.71 1.02 84.01
0.8 1239 41.36 1.48 1.93 4.98 7.63 1.35 91.20
0.9 1334 44.53 1.88 2.45 5.79 8.88 1.73 92.01
1.0 1408 47.00 2.20 2.87 6.36 9.75 2.15 97.62
|
Ограничения с k=0.2 (дающие качать первый релиз на скорости 50 при отдаче 10) представляются вполне посильными, да и затрагивают лишь 15.6% записей (а из них приличная доля - записи, брошенные ради новых).
Реализация
Рассмотренные ограничения можно осуществить, запрещая качать, если нарушено (1) (остаётся возможность качать мимо трекера, но с ней, похоже, поделать ничего нельзя). Это позволит отказаться от банов (влекущих, обычно, регистрацию новых записей), оставляя возможность поднять total_up и вернуть привелегию (!) на скачивание. Текущей оперативности учёта траффика на трекере должно хватить, чтобы не заставлять новичков зажимать себе down на первом скачиваемом релизе (хотя BitTornado, например, это позволяет). Именно лаг на практике ослабит принципиально важное
соотношение f(0)=0, ведь реально стабильная отдача начинается с total_down >= 10Mb как минимум.
Пост предполагается изменяемым, поэтому при комментировании, пожалуйста, цитируйте соответствующие места.
|
Поступило следующее предложение:
)
), раз Северо-Американец - 20, .edu - xx, ну и т.д. 
мда....
.20Gbx(-20Gb,20Gb).gif)
.20Gbx20Gb.gif)