морф решает
В принципе я за e2k и против DC коли уж она была упомянута. DC это несколько другая технология,
похожая на e2k.
Вкратце принцип e2k: e2k это пиринговая сеть, суть которой заключается во взаимообмене файлами клиентов данной сети. При этом существует огромное множество клиентов и настроек. Например - скорость отдачи файлов, скорость приёма (кстати она зависит от скорости отдачи - чем быстрее отдаешь, тем быстрее можешь принимать), приоритеты клиентов (основанные на объеме отданного-полученного), блек-листы и прочие блага.
Технически это выглядит так: есть сервер. Есть клиенты пиринговой сети, установленные на обычных комьютерах у людей. Люди расшаривают папки с содержимым. Данное содержимое хэшируется (вычисляется уникальная контрольная сумма каждого файла), при подключении клиентов к серверу на сервер передаётся "каталог" каждого подключившегося клиента. Таким образом сервер знает актуальный список файлов, расшаренных клиентами.
Далее, предположим Вася Пупкин хочет скачать фильм "Терминатор 3". Вася подключается к серверу, пишет в поиске (в своём клиенте) "Terminator". Клиент Васи обращается к серверу и запрашивает у него список файлов, в названии которых содержится слово Terminator. До конца не вникал как реализован алгоритм обмена списками и поиска, но суть дела от этого не меняется, а суть в следующем - у каждого файла имеется уникальная контрольная сумма, зависящая только от содержимого файла. То есть если я скопирую у Пети фильм Терминатор3.avi и назову файл "Тer_миНаt0r_суперверсия_number_III.core, его контрольная сумма не изменится и сервер будет воспринимать данный файл как копию файла Терминатор3.avi. Итак, серверу известно, что этот файл находится у меня и у Пети. Вернемся назад к Нашему Васе.
Вася ищет файл, в названии которого содержится слово Terminator и видит в поиске файл Terminator3.avi у которого есть два
источника - это я и Петя. Вася решает, что это именно то, что нужно, и указывает клиенту закачать данный файл. Клиент Васи напрямую обращается ко мне и к Пете и запрашивает файл с известным хэшем. В зависимости от обстоятельств изложенных ниже, клиент Васи приступает к скачиванию данного файла.
Обстоятельства следующие: у каждого клиента есть свой идентификатор и есть файл приоритетов. Когда Вася скачивает у меня файл, я становлюсь для Васи важнее, поскольку поделился с ним файлом. Вася-же становится для меня менее приоритетным, поскольку он скачал у меня информацию, но сам мне еще ничего не отдал. Предположим затем, что я буду скачивать что-то у Васи. Поскольку я уже отдал Васе энное количество информации, мой приоритет выше, нежели тех клиентов, кто Васе еще ничего не отдал, и Васин клиент будет стремиться отдавать мне информацию в первую очередь. Чем больше соотношение отдано/принято у конкретного клиента, тем приоритетнее он будет. Иными словами, e2k поощеряет тех, кто делится. И чем больше и быстрее он делится, тем больше и быстрее будут делиться с ним. Следует обратить внимание, что приоритеты определяются КЛИЕНТАМИ, учавствующими в отношениях обмена, а не во всей сети/сервере в целом. То есть моя приоритетность у Васи ничего не значит для Пети, который знать не знает сколько и чего я кому-то отдал. Для него главное что я ничего не отдавал ему, поэтому мой приоритет у Пети низкий.
Немаловажный момент - обмен идёт не целыми файлами, а
кусочками (chunks) примерно по 9 мегабайт. Каждый чанк независим от других. И что хорошо - как только клиент скачал один чанк, он(чанк) тут-же автоматически расшаривается для других клиентов, что добавляет еще один
неполный источник для данного файла. То есть в идеале, клиенту имеющему файл целиком, достаточно всем раздать по одному чанку. Далее те клиенты будут взаимодействовать между собой, обмениваясь имеющимися чанками и собирая целый файл, и не будут нагружать первого раздающего, распределяя нагрузку между всеми источниками. Причем число источников будет расти пропорционально количеству получивших чанки данного файла.
Если еще не запутались идём дальше
Что-же происходит с клиентом1, когда он обращается к клиенту2 с запросом чанка файла? Клиент2 проверяет приоритет клиента1. Если он выше, чем приоритет тех, кто уже качает, клиент1 ужимает их скорость и начинает отдавать чанк файла клиенту1. Если-же полоса оказывается узка для всех желающих качать, образуется очередь за данным файлом (типичной скоростью отдачи во всемирной e2k-сети является всего 10-20кбайт/с, что при множестве источников даёт весьма неплохие результаты). Клиент, получивший чанк, отключается, и должен заново вставать в очередь за следующим требующимся чанком. Конечно, его приоритет будет учтен, но такого, чтобы файл постоянно отдавался одному и томуже не бывает - следующая отдача обязательно будет производиться другому просившему. Очередь постоянно перестраивается, но в итоге все дожидаются своей очереди и скачивают нужный чанк. Еще раз напомню, что тот, кто получал чанк до Вас, тутже станет еще одним источником данного чанка и количество источников файла увеличится. Поскольку чанки независимы, клиент может качать сразу множество чанков со множества источников, постепенно собирая файл целиком. Чем у большего количества людей имеется данный файл, тем более он популярен и тем больше у него источников. В итоге как бы долго в очереди вы не стояли, рано или поздно вы получите требуемый файл целиком. Кстати приоритеты тоже со временем устаревают, и вряд ли тот, кому вы отдали гигабайт в прошлом году вспомнит от этом и позволит Вам качать вперед всех.
Система e2k также учитывает популярность файлов, расшаренных клиентами - то есть если файл1 в сети существует в тысяче экземпляров у тысячи источников, а файл2 существует только в одном экземпляре, e2k-клиент будет стараться скорее поделиться редким файл2 с другими, чтобы увеличить количество источников. Поскольку e2k-клиенты в большинстве запущены на компьютерах обычных людей, время от времени их включающих и выключающих, единственным эффективным методом, позволяющий быстро распространять редкие файлы является его раздача другим, те отдадут третьим, четвертым и так далее...
Существует очень досадная вещь - если вы качали какой-то файл, а все его источники пропали, придётся подождать пока они опять появятся. Впрочем, если владелец FTP выключает его, итог будет тот-же.
Итак, что мы имеем - сервер, хранящий каталог файлов клиентов позволяет быстро находить файл у кого бы он не находился. Далее клиенты взаимодействуют между собой, в зависимости от приоритетов обмениваясь запрошенными файлами, источники файлов появляются и исчезают, файл качается. Минусы - нужно постоянно отдавать чтобы повышаться в приоритете у других, при отключении клиентов друг от друга на длительный интервал времени, очередь теряется и приходится стоять в очереди заново. На самом деле это играет роль только в огромной сети. Если-же это будет наша внутрисетевая e2k-сеть, вряд ли очереди выростут больше десятки. Есть еще один момент - на сервере возможно установить минимальный объем информации, который должен расшарить клиент чтобы подключиться к серверу. Если расшарено меньше, клиент просто не сможет подключиться к серверу и искать файл. Аналогично, в клиентах регуляторы "скорость отдачи" и "скорость приема" связаны - если мало отдаешь - мало будешь принимать. И нельзя принимать не отдавая. Конечно существуют клиенты, называемые "
личерскими, которые ничего не отдают, но используют недоделки других клиентов, и качают у них. Однако клиенты и сервера тоже не стоят на месте и в большинстве клиентов существует антилич - как только будет обнаружено подозрение на личерство - клиент попадает в черный список и больше ему ничего не отдается. Если-же сервер обнаруживает при подключении что клиент личерский, он также его банит.
P.S. вот так коротенечко, если кто-то из этого что-то поймёт
Вход
Регистрация
FAQ
Поиск
