Мысль

Для тех, кто хочет сделать мир лучше.
Сообщение
Автор
[user]
Эксперты no-Steam
Эксперты no-Steam
Сообщения: 3501
Зарегистрирован: 18.07.2008
Благодарил (а): 2 раза
Поблагодарили: 17 раз
Контактная информация:

#76 Сообщение 26.06.2012, 15:16

nALLITeT писал(а):От другого пира?
А его-то он как найдет? То что от другого пира можно получить дополнительный список пиров, это мне ясно. Но если он еще не знаком ни с одним другим пиром, как он найдет других пиров?

Простейший пример. Вот пришел в мир сей новый пир. С другими пирами он пока не знаком. Трекера нет. Как этот одинокий пир найдет других пиров, "себе подобных"?
Последний раз редактировалось [user] 26.06.2012, 15:18, всего редактировалось 1 раз.
© [user]

Аватара пользователя
nALLITeT
Полковник
Полковник
Сообщения: 2560
Зарегистрирован: 01.08.2008
Откуда: 127.0.0.1
Поблагодарили: 2 раза
Контактная информация:

#77 Сообщение 26.06.2012, 15:18

Monk
Я и предложил использовать наработки Bitcoin, они же добились полной децентрализации за счет юзеров. Мы можем сделать так же, юзер для скачивания должен будет "работать" n часов, за это время они будут делать ту же работу что и майнеры в биткоине и при этом сидировать контент. Чтобы лишний батхерт не создавать, юзеру можно для начала выдать бонус.
Изображение
JIEGOKOJI писал(а)::lol: Steamworks это паблишер вальв лол.

Аватара пользователя
NiGHt-LEshiY
Полковник
Полковник
Сообщения: 10258
Зарегистрирован: 13.06.2008
Откуда: Россия
Благодарил (а): 752 раза
Поблагодарили: 2667 раз
Контактная информация:

#78 Сообщение 26.06.2012, 15:19

Ну, лист доверенных нод можно использовать, но это всё-таки не трекер.
Или как в DHT.
Кодекс поведения участников сообщества — обязательно к прочтению.
Просьба присылать сообщения об ошибках в ЛС.

Аватара пользователя
nALLITeT
Полковник
Полковник
Сообщения: 2560
Зарегистрирован: 01.08.2008
Откуда: 127.0.0.1
Поблагодарили: 2 раза
Контактная информация:

#79 Сообщение 26.06.2012, 15:21

[user] писал(а):
nALLITeT писал(а):От другого пира?
А его-то он как найдет? То что от другого пира можно получить дополнительный список пиров, это мне ясно. Но если он еще не знаком ни с одним другим пиром, как он найдет других пиров?

Простейший пример. Вот пришел в мир сей новый пир. С другими пирами он пока не знаком. Трекера нет. Как этот одинокий пир найдет других пиров, "себе подобных"?
Во-первых, юзер скачает инсталлер на каком-нибудь ресурсе, где уже может быть файл с пирами\нодами\да-чем-угодно, этого достаточно.
Во-вторых, можно в локалке отправить широковещательный пакет отправить, анонс пира.
Изображение
JIEGOKOJI писал(а)::lol: Steamworks это паблишер вальв лол.

[user]
Эксперты no-Steam
Эксперты no-Steam
Сообщения: 3501
Зарегистрирован: 18.07.2008
Благодарил (а): 2 раза
Поблагодарили: 17 раз
Контактная информация:

#80 Сообщение 26.06.2012, 15:44

(nALLITeT опередил)

Как вариант, можно вести БД пиров, поставляемую вместе с приложением и регулярно обновляемую.
  • Доверенные.
  • Первые N с наивысшим рейтингом.
  • Первые M часто бывающих в сети.
В добавление к официальной БД, каждый пир должен вести и поддерживать в актуальном состоянии свою собственную БД пиров.

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

Добавлено спустя 2 минуты 26 секунд:
Чтож, думаю, на этом можно считать вопрос с FTP закрытым.
© [user]

Аватара пользователя
nALLITeT
Полковник
Полковник
Сообщения: 2560
Зарегистрирован: 01.08.2008
Откуда: 127.0.0.1
Поблагодарили: 2 раза
Контактная информация:

#81 Сообщение 26.06.2012, 15:47

[user]
Никаких БД пиров не надо, достаточно несколько наиболее стабильных и наиболее популярных.
Изображение
JIEGOKOJI писал(а)::lol: Steamworks это паблишер вальв лол.

Аватара пользователя
nikit-xxx
Лейтенант
Лейтенант
Сообщения: 208
Зарегистрирован: 28.11.2007
Благодарил (а): 44 раза
Поблагодарили: 5 раз

#82 Сообщение 26.06.2012, 16:17

[user] писал(а):Простейший пример. Вот пришел в мир сей новый пир. С другими пирами он пока не знаком. Трекера нет. Как этот одинокий пир найдет других пиров, "себе подобных"?
технология DHT: пиры ищутся с помощью таблицы маршрутизации, uTorrent и aria2 хранят её в файлах dht.dat(которые между собой не совместимы), для первоначальной генерации(то есть с нуля) которой нужна раздача с разрешённым dht.
Но, теоретически, может получиться и так, что ни с одним пиром из предустановленной БД новый пир связаться не сможет.
тогда облом; нужно сводить эту вероятность к минимуму)
Откуда иксы в моём нике
Изображение
Изображение
скачать С. Прата. Язык программирования C++. Лекции и упражнения. 5-е изд (*Выровнена нумерация страниц, *Содержание)
Краткая инструкция по созданию пиратки-распака CS/HL
Изображение
Использование тэга подсветки синтаксиса
[syntax lang="cpp" lines="n"]
#include <iostream>
using namespace std;

struct cl{
static void f() { cout << "Hi, user!\n"; }
int i;
};

int main()
{
cl::f();
//cl::i = 1;
return 0;
}
[/syntax]

sinangel
Полковник
Полковник
Сообщения: 1337
Зарегистрирован: 28.12.2009
Благодарил (а): 95 раз
Поблагодарили: 561 раз
Контактная информация:

#83 Сообщение 26.06.2012, 21:37

Но, теоретически, может получиться и так, что ни с одним пиром из предустановленной БД новый пир связаться не сможет.
ну почему,сделать постоянный пир (один или n-надцать) связь с которым будет прописана в программе, он же будет собирать/выдавать списки активных пиров

Добавлено спустя 7 минут 59 секунд:
Как вариант, можно вести БД пиров, поставляемую вместе с приложением и регулярно обновляемую.
Доверенные.
Первые N с наивысшим рейтингом.
Первые M часто бывающих в сети.
зачем так сложно, просто сколько отдал
получил флейм бан, получил игру от Svvl_gtn
http://vkоntakte.ru/h4z0r
[txtspoil][ jump down into a large rabbit-hole ][/txtspoil]

MOZGIII
Разработчик
Разработчик
Сообщения: 910
Зарегистрирован: 09.01.2009
Откуда: Переезжаю в /dev/null
Благодарил (а): 7 раз
Поблагодарили: 65 раз
Контактная информация:

#84 Сообщение 27.06.2012, 01:13

Возможно, нам вообще нет смысла изобретать велосипед. Есть сеть Kademilla2 например, посмотрите, почитайте про неё, например на http://anticopyright.ru/wiki/Kademlia. Попробуйте попользоваться *Mule-ами. Она, кажется, даже поддерживает использование дополнительных произвольных метаданных для файлов (нам может понадобиться какая-то дополнительная информация при поиске или загрузке файла). К тому-же там очень много пользователей уже сейчас. Я имею ввиду, что задачу написанию системы п2п обмена контентом можно свести к задаче написания специфического клиента для сети Kad2 или подобной. Но это как вариант, в котором придётся меньше думать о технологии передачи данных.

DHT в торрентах - отличная штука кстати. Только сам протокол бит-торрент не очень нам подходит. По моему, реально, для скачивания или обновления игры нужно знать только какие файлы этой игре нужны (их sha1 хеши к примеру) и куда эти файлы класть в структуре папок игры (то есть путь к файлу).
У меня в лаунчере, кстати, всё так и устроено - для клиента генерируется манифест файлов (client_files_manifest.json), потом файлы называются их хешами и заливаются в хранилища, а манифест импортируется в систему в виде пакета файлов клиента, который потом можно выбрать как клиент для определённого сервера. При скачивании клиента, сервер выдаёт пути к файлам их хеши и место где их брать, клиент скачивает и раскладывает всё по местам. Если бы ланучер мог сам находить файлы (а у него есть их sha1 хеш), система могла бы избавится от серверов-хранилищ.

Добавлено спустя 10 минут 54 секунды:
Да, а зачем все эти рейтинги, ратио, етс? Не плодите сомнительных лишних сущностей заранее, в них во первых может не быть смысла (то есть совсем не будут укладываться в рамки проекта), а во вторых может не быть необходимости (система итак будет успешно и эффективно качать и раздавать файлы). Вот например, какой смысл делать рейтинг нод и учёт их появления в сети, если, по идее, лучше сделать пользователя максимально анонимным, то есть может даже перегенерировать все ключи при перезапуске клиента будет для нас хорошо.

PS: полазайте кто-нить по дев-разделу и запихните всю инфу в один вики, или хотя-бы в этот тред. Этот вопрос уже кучу раз обсуждался, и там есть достаточно полезная инфа.

[user]
Эксперты no-Steam
Эксперты no-Steam
Сообщения: 3501
Зарегистрирован: 18.07.2008
Благодарил (а): 2 раза
Поблагодарили: 17 раз
Контактная информация:

#85 Сообщение 27.06.2012, 04:12

С учетом того, что у проекта не будет централизованного сервера, требуется безопасно и автоматически обновлять само приложение.

Далее. Поиск распространяемого контента. Варианты:
  1. Фиксированный список, загружаемый при старте приложения. (по аналогии с CDR Steam). Кому-то его нужно будет поддерживать а актуальном состоянии.
  2. Или же автоматический поиск раздач контента. Здесь есть потенциальная уязвимость: теоретически возможно захламление списка, что приведет к его долгому получению и анализу на подлинность. Да и вообще тут какая-то неопределенность получается...
В первом варианте - строгое декларирование всего контента. Во втором - неопределенность. Так что наверно лучше a) .

Добавлено спустя 21 минуту 31 секунду:
Возможен такой неоднозначный момент по P2P (Все это уже относится к проекту приложения, а не к протоколу P2P).
Предположим, что все пиры из предустановленного доверенного списка недоступны, а из обычных пиров - есть доступные.
Предположим, что новый клиент выбрал пир (из предустановленного списка обычных пиров) и хочет получить от него информации (допустим, о контенте). А у выбранного пира информация - сильно устаревшая. Это может произойти как случайно (глюк) или же намеренно (фейковый пир).

Как поступать здесь?
  • Ввести такое понятие как срок годности информации ( допустим, информации о контенте).
  • Не доверять отдельно взятому пиру и пытаться перепроверить информацию у другого случайно выбранного пира. Но здесь, опять, же может получиться (теоретически) так, что оба пира окажутся фейковыми с устаревшей информацией.
Хотя эти оба варианта даже можно использовать совместно.
Последний раз редактировалось [user] 27.06.2012, 13:42, всего редактировалось 3 раза.
© [user]

MOZGIII
Разработчик
Разработчик
Сообщения: 910
Зарегистрирован: 09.01.2009
Откуда: Переезжаю в /dev/null
Благодарил (а): 7 раз
Поблагодарили: 65 раз
Контактная информация:

#86 Сообщение 27.06.2012, 04:45

[user] писал(а):С учетом того, что у проекта не будет централизованного сервера, требуется безопасно и автоматически обновлять само приложение.
Это легко, используем RSA, сами обновления распространять можно также по p2p.
PS: я предполагаю что все представляют как работает RSA или хотя-бы имеют представление о системах шифрования с открытыми ключами. Если пойдут вопросы - я объясню общую идею, и почему это нам поможет.
[user] писал(а):Далее. Поиск распространяемого контента. Варианты:
Фиксированный список, загружаемый при старте приложения. (по аналогии с CDR Steam). Кому-то его нужно будет поддерживать а актуальном состоянии.
Или же автоматический поиск раздач контента. Здесь есть потенциальная уязвимость: теоретически возможно захламление списка, что приведет к его долгому получению и анализу на подлинность. Да и вообще тут какая-то неопределенность получается...
Оба варианта неэффективны. Достаточно иметь манифест файлов и, при необходимости, соответствующие плагины. Плагины можно распространять также через саму p2p, при этом у каждого плагина будет свой ключ (опять же RSA, только уже не шифрование, а подпись), который можно будет указать как депенсити в манифесте. От версии к версии ключ меняться не будет, но будет отдельное поле с версией (можно будет указать минимальную версию).
+ надо будет сделать список мастер пиров - это будут просто обыкновенные пиры, но с постоянными адресами и известные всем другим пирам, один, например, который будет содержать все плагины всех версий, и пару больших - с файлами из манифестов - вместо отдельных http или ftp - что-бы файлы были всегда доступны.

Добавлено спустя 8 минут 58 секунд:
[user] писал(а):Возможен такой неоднозначный момент по P2P.
Предположим, что все пиры из предустановленного доверенного списка недоступны, а из обычных пиров - есть доступные.
Предположим, что новый клиент выбрал пир (из предустановленного списка обычных пиров) с устаревшей (сильно) информацией (допустим, о контенте). Это может произойти как случайно (глюк или еще что-то...) или же намеренно (фейковый пир).
При использовании системы манифестов такой ситуации вообще никогда не возникнет. То есть совсем никогда. Для обновления, клиенту нужен будет манифест новой версии, все файлы докачаются сами. Нету манифеста, нету обновления. Манифесты можно распространять не только через пиры, но и на сайте выложить например.
Такая штука очень похожа на торрент, но есть одно, очень существенное, отличие: торрент умеет качать только конкретную раздачу, даже если файлы из этой раздачи есть в других раздачах - они не будут использоваться. В системе манифестов наоборот, есть только список файлов, и выкачиваются сами файлы. Манифест можно собрать на лету, не имея у себя самих файлов, но зная, какие они бывают (хеши), и при этом успешно выкачать его из сети.

Таким образом, мы можем легко бороться с фейковыми пирами, а также довольно защищённо обновляться, через саму же p2p сеть.

Добавлено спустя 16 минут 52 секунды:
Кстати, для стартового поиска пиров (в том случае, если мастер-пиры внезапно упадут или недоступны из определённого сегмента сети), программу-клиент можно научить гуглить %) Гугль всегда доступен, а распарсить наиденные страницы и вычленить из них адреса (можно придумать, как из записать так, чтобы проще было распарсить) - раз плюнуть. Ну, и конечно, банальные броадкасты в лан + скан родной подсети, да да...

[user]
Эксперты no-Steam
Эксперты no-Steam
Сообщения: 3501
Зарегистрирован: 18.07.2008
Благодарил (а): 2 раза
Поблагодарили: 17 раз
Контактная информация:

#87 Сообщение 27.06.2012, 04:55

Я подразумеваю, что фейковые пиры будет распространять подлинную (формально, не к чему придраться), но просроченную информацию. Назову их "качественными фейками".

// У всякого продукта есть срок годности. У кого-то ограничен конкретным значением, у другого - не ограничен. Просроченный продукт к использованию формально считается полностью не пригодным. Думаю, понятие просроченной информации и здесь не будет лишним.

Т.е. Предположим, если клиент со старой БД пиров найдет несколько пиров, но у всех них будет просроченная информация (качественные фейки), то он пошлет пользователя за свежей базой пиров.

Это же ограничение можно наложить и на предустановленную БД. Если очень старая, то можно выдать предупреждение о неактуальности БД, но опционально попробовать соединиться с P2P и найти актуальную информацию.

Добавлено спустя 1 минуту 23 секунды:
Срок годности информации с цифровой подписью.

Добавлено спустя 8 минут 2 секунды:
Понятно, что описываемые мной случаи - скорее теоретические и на практике мало вероятны. И тем не менее, при планировании протокла (Все это относится к проекту приложения, а не к протоколу P2P) нельзя полагаться на авось, даже если вероятность небольшой неточности всего-то, условно говоря, 1-2%.
Последний раз редактировалось [user] 27.06.2012, 13:43, всего редактировалось 2 раза.
© [user]

MOZGIII
Разработчик
Разработчик
Сообщения: 910
Зарегистрирован: 09.01.2009
Откуда: Переезжаю в /dev/null
Благодарил (а): 7 раз
Поблагодарили: 65 раз
Контактная информация:

#88 Сообщение 27.06.2012, 05:03

[user]
Я понял, речь о маршрутизации пиров и поиске по ним. Это отдельная и интересная тема, по этому поводу у меня вообще есть куча умных алгоритмов.
В нашем случае, наличие только "качественных фейков" в списке известных пиров может привести только к состоянию, при котором поиск файла с определённым хешем по p2p сети не заканчивается успешно. Это, кстати говоря, не самый худший случай фейковых пиров. Но в этом ничего страшного нет, в таком случае можно простое расширение сети (поиск новых пиров) решает вопрос. Если найти новых пиров нельзя (например, уже охвачена вся сеть), то считается что запрошен несуществующий файл. В предположении, что наши алгоритмы поиска дополнительных пиров не будут ломаться всякими фейками (потому, что если будут - это провал, и не серьёзно), можно утверждать, что качественные фейки не будут проблемой. Кстати, кто сказал, что что-бы найти файл в сети нужно обязательно иметь пир, имеющий этот файл у себя в списке пиров? И что вообще нужно обращаться к нужному тебе пиру напрямую? Есть очень много разных способов, как можно устроить данное взаимодействие... Советую погуглить, это кстати, интересная общедоступная информация.

Добавлено спустя 2 минуты 7 секунд:
PS: просроченной информации не бывает же.

Добавлено спустя 3 минуты 24 секунды:
И я же просил не вводить лишних сущностей - срок годности информации - одни из них. Я например, даже сейчас играю иногда в какой-нибудь Unreal Tournament 2003, хотя он уже даже, кажется, давно не поддерживается. И релизнулся он очень давно. Но файл есть файл.

[user]
Эксперты no-Steam
Эксперты no-Steam
Сообщения: 3501
Зарегистрирован: 18.07.2008
Благодарил (а): 2 раза
Поблагодарили: 17 раз
Контактная информация:

#89 Сообщение 27.06.2012, 13:11

MOZGIII писал(а):Кстати, для стартового поиска пиров (в том случае, если мастер-пиры внезапно упадут или недоступны из определённого сегмента сети), программу-клиент можно научить гуглить
Одна проблема - защита от ботов. Капча. Срабатывает иногда в случае, если большое число пользователей используют одинаковый внешний ip.

Добавлено спустя 24 минуты 11 секунд:
просроченная информация
Я предлагаю ограничивать срок годности не поставляемого контента пользователю, а лишь некоторой служебной информации, используемой для нужд программы (в частности метаданные конетнта и др.) или сети P2P.
В случае с централизованным управлением такая сущность, да, не нужна. Совсем другое дело - проект с децентрализованным управлением.

Добавлено спустя 21 минуту 27 секунд:
Теоретически описанный случай возможен.
Предположим, что все пиры из предустановленного доверенного списка недоступны, а из обычных пиров - есть доступные.
Предположим, что новый клиент выбрал пир (из предустановленного списка обычных пиров) и хочет получить от него некоторую служебную информации. А у выбранного пира эта информация - подлинная, но сильно устаревшая.
Т.е. если повезет, новый клиент получит актуальную служебную информацию, а если нет - то сильно устаревшую. А протокол (Все это относится к проекту приложения, а не к протоколу P2P) не должен допускать неоднозначности!

Понятно, что при обновлении служебной информации, она по сети P2P разойдется не мгновенно (а некоторые пиры, как я уже упомянул, могут не обновить ее у себя вовсе: случайно (не было возможности или произошел случайный сбой ПО), намеренно ("качественный фейк")). Но, установив срок годности служебной информации, мы сможем гарантировать, что клиент не при каких обстоятельствах не признает устаревшую (формально: вышел срок годности) информацию за свежую.
Последний раз редактировалось [user] 27.06.2012, 13:44, всего редактировалось 2 раза.
© [user]

MOZGIII
Разработчик
Разработчик
Сообщения: 910
Зарегистрирован: 09.01.2009
Откуда: Переезжаю в /dev/null
Благодарил (а): 7 раз
Поблагодарили: 65 раз
Контактная информация:

#90 Сообщение 27.06.2012, 13:35

[user] писал(а):Понятно, что при обновлении служебной информации, она по сети P2P разойдется не мгновенно (а некоторые пиры, как я уже упомянул, могут не обновить ее у себя вовсе: случайно (глюк) или намеренно ("качественный фейк")). Но, установив срок годности служебной информации, мы сможем гарантировать, что клиент не при каких обстоятельствах не признает устаревшую (формально: вышел срок годности) информацию за свежую.
Это не нужно. Во-первых, что такое служебная информация и о чём вообще идёт речь? Пока что в протоколе у нас нет такой служебной информации, которая умеет устаревать.
[user] писал(а):В случае с централизованным управлением такая сущность, да, не нужна. Совсем другое дело - проект с децентрализованным управлением.
Я про наш конкретный случай вообще-то говорю. Даже обновления клиента, подписанные ключами, не имеют срока годности: в них достаточно указать номер версии или дату релиза, которые будут использоваться для автоматического обновления (что-бы ставить версию только старше текущей). Но, при этом, зачем ограничивать передачу предыдущих версий? При этом, по времени? И зачем делать это на уровне протокола? Если говорить о том, что у p2p системы должен быть алгоритм устранения избыточности, но ограничение доступности данных по времени - это очень плохой способ. И вообще время - штука особая, при разработке протоколов вообще не стоит на него полагаться, так как это, фактически, ненадёжная характеристика (время бывает сбито).

Добавлено спустя 7 минут 52 секунды:
Кстати, по поводу
[user] писал(а):Теоретически описанный случай возможен.
Получение сильно устаревшей информации (если иметь ввиду контент, то есть в нашем случае файл) от пира - это, в принципе, нормальное поведение системы, при том, что пользователь запрашивает файл по хешу. Если говорить об информации, которая сопряжена с маршрутизацией пиров и поиском по ним, то тут, пока у нас нету этих алгоритмов, вообще нет смысла что-либо утверждать (ака не о чем говорить). Но, есть очень большая вероятность, что там вообще будет не до срока годности, если, конечно, мы не говорим о TTL и времени вроде 30-300 секунд.

Ответить