P2P networks – есть ли альтернатива Мулу?

 
+
-
edit
 

Mishka

модератор
★★★

Balancer> В Муле, к сожалению, сервера - не только справочники, но и соержащие всю поисковую инфу.

Так это и есть справочник. :) Так называемые "жёлтые страницы".

Balancer> А так - легко. Если это будет только голый справочник, при чём, фактически, "одноразового коннекта" (подцепился, отметился, взял список других нод дальше вся работа с этими нодами), то и поставить такой сервер будет несложно, и бороться с ним прав особых у государств не будет. И потеря такого справочника будет не так ощутима.

Тут возникает одна очень интересная проблема математического плана. При той архитектуре, которая сейчас тебе на поиск нужна одна связь, на выкачивание — N связей. Для поиска по твоей схеме надо иметь полностью связанный граф. Число рёбер в там графе вычисляется по формуле :) N*(N-1)/2 — где N — это количество вершин. Т.е. тебе надо будет самому открыть 1 соединение с сервером и N-1 соединение с клиентами и самому быть готовым принять N-1 соединение (хотя бы). Если мы ведем разговор о сервере типа Рэйзорбэка, то там было около 600,000 пользователей одновременно. Надо объяснять — сколько времени потребуется, чтобы опросить 600,000 р2р клиентов? :F И что сделает с тобой провайдер, когда на тебя посыпятся запросы с других клиентов, даже в районе 10,000? И это при том, что ещё есть и закачка-выкачка.
 
+
-
edit
 
Как вариант - каждый клиент сам себе создает базу данных. При соединении с другим клиентом он получает список того что он имеет и запоминает. Список понятное дело тоже можно передавать. Конечно такой способ будет кушать много трафика и будет проблема с актуальностью информации, зато никакой централизации.
Пытаясь понять рекурсию, следи за тем, чтобы она не поняла тебя первой...  
+
-
edit
 

Balancer

администратор
★★★★★
Mishka> При той архитектуре, которая сейчас тебе на поиск нужна одна связь, на выкачивание — N связей.

А кто заставляет пользоваться этой архитектурой? Нагружаем N нод информацией о файла M нод, где M > > N :) И вводим систему распределённого роутинга. Точные прикидки нужно уже с привязкой к потенциальному новому протоколу считать, но похоже, что нагрузка будет не сильно большая. Достаточно каждой ноде хранить информацию о 10000 других нод, чтобы снизить уровень служебного трафика в 10000 раз.
 
+
-
edit
 

Balancer

администратор
★★★★★
Abaddon> Как вариант - каждый клиент сам себе создает базу данных. При соединении с другим клиентом он получает список того что он имеет и запоминает. Список понятное дело тоже можно передавать.

Да, именно так.

Abaddon> Конечно такой способ будет кушать много трафика

Если продумать роутинг, то паразитный трафик будет не очень большой.

Abaddon> и будет проблема с актуальностью информации, зато никакой централизации.

А актуальность тут не так важна. Если находишь нужные куски файла, то не грех уже и в явном виде запросить их владельца на предмет актуальности информации :) (и, как и при любой другой трансакции обменяться с ним информацией - у кого актуальнее :) )
 
+
-
edit
 

Mishka

модератор
★★★

Mishka>> При той архитектуре, которая сейчас тебе на поиск нужна одна связь, на выкачивание — N связей.
Balancer> А кто заставляет пользоваться этой архитектурой? Нагружаем N нод информацией о файла M нод, где M > > N :) И вводим систему распределённого роутинга. Точные прикидки нужно уже с привязкой к потенциальному новому протоколу считать, но похоже, что нагрузка будет не сильно большая. Достаточно каждой ноде хранить информацию о 10000 других нод, чтобы снизить уровень служебного трафика в 10000 раз.

И чем такая архитектура отличается от нынешней? Только тем, что ноды должны обмениваться информацией.

Ром, не считай с раутингом — уже всё посчитано — посмотри на работы по BGP (включая BGP-3 и BGP-4), OSPF, RIP, RIP-II. Особенно упирай на BGP — там как раз понятие соседа BGP-раутера не спроста заведено.

Ну, на худой конец получишь не совсем раутинг, а что-то вроде DNS серверов и цепочки из них. Но тогда про поддержку корректной информации и её распространения придется забить — может ходить сутками. Да проблемы будут те же, что с серверами.
 
+
-
edit
 

Mishka

модератор
★★★

Abaddon> Как вариант - каждый клиент сам себе создает базу данных. При соединении с другим клиентом он получает список того что он имеет и запоминает. Список понятное дело тоже можно передавать. Конечно такой способ будет кушать много трафика и будет проблема с актуальностью информации, зато никакой централизации.

Ага, только вместо фильмов ты будешь заниматься тем, что качаешь таблицы баз данных. Вот набрал ты сервер, а на нём 100,000 клиентов. И пошёл связываться со всем подряд. Если кино распределно равномерно, то на 50,000 можно оставновится. Но лучше 100,000 — чтобы наверняка. И с каждого клиента начинаешь качать что у него есть и что он знает про других. Пару килобайт информации наберётся. 2,000 на 100,000 — упс 100,000,000. Хорошо, предположим, что инфу сохранили. Поддерживать 100,000 связей не получится. Значит, как долго хранить инфу? Пару часов? А потом её выкинем и заново. В день получиться 12 раз — вот тебе и 1.2 гига накачали служебной инфы.
 
+
-
edit
 

Mishka

модератор
★★★

Abaddon>> Как вариант - каждый клиент сам себе создает базу данных. При соединении с другим клиентом он получает список того что он имеет и запоминает. Список понятное дело тоже можно передавать.
Balancer> Да, именно так.

Не, не так — ты уже выделил специальных машин — чтобы держать данные о 10,000 клиентов. Они уже сервера в нынешнем понимании и точно такие же, как в нонешней архитектуре.

Abaddon>> Конечно такой способ будет кушать много трафика
Balancer> Если продумать роутинг, то паразитный трафик будет не очень большой.

Будет и достаточно сильный. Посмотри на трафик BGP — в таблице стараются хранить только самые основные рауты (сейчас говорят про 120,000 раутов, вроде), стараются передавать только изменения. А траффику — до... вообщем, вам по пояс будет (С) А зори здесь тихие. И к управлению допускают не всех. Сложные там полиси. А уже если флип-флоппинга получается или цикл образуется, то попа сразу. Спроси у Браба. Он настраивал и много думал. :F


Balancer> А актуальность тут не так важна. Если находишь нужные куски файла, то не грех уже и в явном виде запросить их владельца на предмет актуальности информации :) (и, как и при любой другой трансакции обменяться с ним информацией - у кого актуальнее :) )

Как это не важна? Если ты будешь получать хотя бы половину несуществующих клиентов — ты машину-то присадишь довольно сильно. Она на таймауты какашками просто изойдет.
 
RU slipstream #09.12.2006 05:22
+
-
edit
 

slipstream

втянувшийся
All your base are belong to Join Forces, так или иначе =) вчера:

Info / µTorrent Community Forums
This is Bram Cohen, the creator of the BitTorrent protocol, and Ludvig (Ludde) Strigeus, the writer of µTorrent.

Together, we are pleased to announce that BitTorrent, Inc. and µTorrent AB have decided to join forces. BitTorrent has acquired µTorrent as it recognized the merits of µTorrent's exceptionally well-written codebase and robust user community. Bringing together µTorrent's efficient implementation and compelling UI with BitTorrent's expertise in networking protocols will significantly benefit the community with what we envision will be the best BitTorrent client.

What does this mean for the µTorrent community? Not much, at least not at first. The intention is to maintain the website as it is, and keep the forums and community active. Moving forward behind the scenes, we will continue to develop µTorrent and will be using the codebase in other applications, especially ones where a fast, lightweight implementation is more suitable, such as embedded systems on TVs, cell phones, and other non-PC platforms.

The existent µTorrent and BitTorrent communities are immensely valuable to us, which is why we are announcing this here first to make sure you're all the first to know about the news. The plan is to continue to foster the health and growth of the community that has been critical to the success of µTorrent. Thank you in advance for your support.

Bram and Ludde

+++++

both Bram and Ludde are available now on IRC #utorrent and will be answering questions for the next few hours.
 
RU slipstream #09.12.2006 05:42
+
-
edit
 

slipstream

втянувшийся
(читая лог #utorrent) почти 6 часов Коэна мучали.

хехе
07/21:57:12 < ernest0> Bram: you said before that you're not a big fan of protocol header encryption... do you still stand behind this?
07/21:57:52 <@Bram> ernest0: it isn't much harder for an isp to recognize encrypted headers than unencrypted headers
 
+
-
edit
 

Mishka

модератор
★★★

slipstream> (читая лог #utorrent) почти 6 часов Коэна мучали.
slipstream> хехе

Чего-то меня потеряли этой фразой. :F
 
RU slipstream #24.12.2006 19:15
+
-
edit
 

slipstream

втянувшийся
Balancer> Кстати, кто-нибудь в курсе, почему NNov сервер не пашет? Уже давно... Я хотел было на Авиабазе поднять раздачи только в русские подсети, благо, mldonkey умеет с GeoIP работать. Но в таком режиме клиент только к русским серверам цепляется. А таких сейчас доступных у меня нет.

Обратил внимание, что новый российский сервер появился? -

Darth

опытный

У меня что-то последние 2 месяца Kad практически не работает (выдаёт очень мало результатов, а часто не выдёт вовсе). У всех так? E-Mule 0.47c.
 
+
-
edit
 

Balancer

администратор
★★★★★
slipstream> Обратил внимание, что новый российский сервер появился?

Кстати, быстро умер. Так что Авиабаза опять ничего не раздаёт :)
 

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru