Всячина

[doldonius]

Кто тут у нас математики?

По поводу впрыска статей в NNTP-подобную P2P систему. Допустим, мы разделяем передачу статей и анонс (оповещение всей сети о том, что статья существует и может быть запрошена). То есть юзер А пишет статейку. Его тачка кидает в шапку IDы соседей и свой и вытаскивает один наугад. Если вытянут свой, тачка анонсирует статью. Если соседский, тачка отправляет статью соседу, не анонсируя. Там повторяется фокус с шапкой.

Вопрос: насколько это затруднит любознательным органам идентификацию автора?

Comments

[link01]

Вполне. Если каждый хост знает в среднем N соседей, статья объявится в среднем через N-1 хопов. А если еще и список соседей обновлять как-нибудь столь же случайно и не хранить историю - насовсем.

[doldonius]

Да какая ж история у статьи, которой еще как бы нет? Вот с динамикой соседей может быть хуже. Плюс, видимо, для противодействия мировому западлу придется добавить таймаут и через M минут с момента написания анонсировать безусловно.

[link01]

Да, я имел в виду историю "соседей, известных данному хосту". "Не помню, откуда я взял эту статью, гад буду, начальник, ходят тут всякие, шо я, всех помнить должен? Не, правда не помню."

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

[doldonius]

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

Дублирование... Так, меняем концепцию. Статья уходит всем пирам, у которых ее еще нет (стандартный обмен). Дальше смотрим список наличных статей и список анонсов. Если нашлась неанонсированная статья, тупо берем из /dev/urandom два байта и сравниваем полученное целое с возрастом статьи в секундах. Если возраст статьи больше или равен случайному числу, вносим запись в свой список анонсов. Таким образом, примерно через 18 с половиной часов статья будет анонсирована, как бы ни старалось мировое западло. А уж на скольки узлах она к тому времени будет лежать... допустим, раз в 10 минут клиент обменивается с одним из 20 известных ему узлов. Дальше ты считай :)

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

[doldonius]

Кстати: попробуй еще прикинуть вариант "партизанский отряд с предателем". Допустим, у нас в сети появился модифицированный клиент, ведущий подробную статистику. Как зависит вычислимость автора от числа узлов в сети?