Comments 35
А что же gnutella и shareaza.sourceforge.net/?
очень давно занимаюсь децентрализованными сетями и даже веду свои теоретические и практические разработки в этом направлении, если тема будет интересна, могу опубликовать обзор Chord DHT и своих наработок
Тема очень актуальная, ждём Вашего обзора!
Интересная тема, буду ждать продолжения.
Не подскажете, на каком этапе развития находится протокол JXTA?
Не подскажете, на каком этапе развития находится протокол JXTA?
UFO just landed and posted this here
Было бы очень интересно узнать ваше мнение на счет реализации «растущего файла» в p2p-сети, попросту говоря — форума.
На основе DHT? Т.е., например, Kademlia?
Ну я бы вводил тогда три типа сущностей: разделы, темы, сообщения.
Соответственно, привязал бы темы к разделам, сообщения к темам. Таким образом, можно отправлять запросы на поиск каждой сущности. Запрос на добавление сообщения к теме обрабатывается узлами, хранящими ее (они просто дополняют список сообщений внутри себя). Модерировать тему имеет право только создатель, как я думаю. Идентифицировать его можно с помощью публичного ключа.
Клиенту не помешало бы поддерживать закладки, любимое и т.п., дабы сделать итоговый продукт удобоваримым и оправданным.
Вопрос, конечно, интересный, надеюсь, я правильно его понял?..
Что Вы сами думаете о своей идее (наработки, черновики)?
//
Да, забыл заметить в заметке, что в структурированных сетях на Kademlia (да и в других) проблема поиска по ключевым словам и тегам следующим образом: пользователь, публикующий файл должен определить набор тегов и ключевых слов, связанных с файлом, тогда будет вызвать специальный вариант STORE для ключей, произведенных ключевыми словами, который разместит ссылку на настоящий ключ. Того же эффекта, в-принципе, можно добиться, создав в файловой системе символические ссылки на нужный файл с именами-тегами.
Ну я бы вводил тогда три типа сущностей: разделы, темы, сообщения.
Соответственно, привязал бы темы к разделам, сообщения к темам. Таким образом, можно отправлять запросы на поиск каждой сущности. Запрос на добавление сообщения к теме обрабатывается узлами, хранящими ее (они просто дополняют список сообщений внутри себя). Модерировать тему имеет право только создатель, как я думаю. Идентифицировать его можно с помощью публичного ключа.
Клиенту не помешало бы поддерживать закладки, любимое и т.п., дабы сделать итоговый продукт удобоваримым и оправданным.
Вопрос, конечно, интересный, надеюсь, я правильно его понял?..
Что Вы сами думаете о своей идее (наработки, черновики)?
//
Да, забыл заметить в заметке, что в структурированных сетях на Kademlia (да и в других) проблема поиска по ключевым словам и тегам следующим образом: пользователь, публикующий файл должен определить набор тегов и ключевых слов, связанных с файлом, тогда будет вызвать специальный вариант STORE для ключей, произведенных ключевыми словами, который разместит ссылку на настоящий ключ. Того же эффекта, в-принципе, можно добиться, создав в файловой системе символические ссылки на нужный файл с именами-тегами.
Правильно понимаю, что каждое сообщение имеет указатель на «родителя-тему»? Т.е. поиск по хешу, как если бы искали торрент в DHT? Не будет ли слишком накладно искать таким способом? Обычный торрент однозначно идентифицируется по хэшу: хэш = содержимое, а здесь придется добавлять какой-то список, и каким-то образом передавать его в запросе, чтобы в ответ не присылали те сообщения, которые уже у вас есть.
Самый простой был бы вариант со счетчиком, просто сообщать максимальный номер сообщения, который у вас есть. Посколько сообщения появляются по очереди, то это хороший вариант. Но есть проблема: два пользователя одновременно могут создать сообщения с одинаковым номером думая, что дают максимальное значение. Да еще хотелось бы передавать сообщения при создании (получении), а не получать послав запрос, т.е. сократив два движения в одно.
Поиск по тегам вещь безусловная нужная, но без нее получается достаточно изолированная и «секретная» система: не зная хэш не найдешь тему. Это хорошая защита от спама.
Модерировать можно просто: каждый может отключить отображение сообщений от определенного пользователя (можно даже передавать специальное сообщение "-1" для пользователя, чтобы был общий рейтинг и новоподключившиеся могли бы оценивать собеседников сразу, однако это ведет к злоупотреблениям — хабр тому пример; )
Набросков нет, никак не могу продумать эту систему.
Я не уверен, что понял правильно, но кажется вы предлагаете синхронизировать тему через «держателя», обычно пользователя, который начал разговор? У вас список «узлов, хранящие тему» это все участники? Проблема как идентифицировать сообщения, чтобы у всех участников они были одинаковыми, чтобы запрашивать только недостающие сообщения. Хэш не подходит, придется отсылать большой список того, что у вас уже есть. Порядковый номер не подходит, потому что может сбоить, если два клиента будут иметь разные максимальные номера (не до конца скачали), либо просто отправят сообщение одновременно. Может быть подойдет временная метка (точно покажет последовательность), но нужна синхронизация времени, которая не факт что проще, чем синхронизация количества сообщений в теме.
Самый простой был бы вариант со счетчиком, просто сообщать максимальный номер сообщения, который у вас есть. Посколько сообщения появляются по очереди, то это хороший вариант. Но есть проблема: два пользователя одновременно могут создать сообщения с одинаковым номером думая, что дают максимальное значение. Да еще хотелось бы передавать сообщения при создании (получении), а не получать послав запрос, т.е. сократив два движения в одно.
Поиск по тегам вещь безусловная нужная, но без нее получается достаточно изолированная и «секретная» система: не зная хэш не найдешь тему. Это хорошая защита от спама.
Модерировать можно просто: каждый может отключить отображение сообщений от определенного пользователя (можно даже передавать специальное сообщение "-1" для пользователя, чтобы был общий рейтинг и новоподключившиеся могли бы оценивать собеседников сразу, однако это ведет к злоупотреблениям — хабр тому пример; )
Набросков нет, никак не могу продумать эту систему.
Я не уверен, что понял правильно, но кажется вы предлагаете синхронизировать тему через «держателя», обычно пользователя, который начал разговор? У вас список «узлов, хранящие тему» это все участники? Проблема как идентифицировать сообщения, чтобы у всех участников они были одинаковыми, чтобы запрашивать только недостающие сообщения. Хэш не подходит, придется отсылать большой список того, что у вас уже есть. Порядковый номер не подходит, потому что может сбоить, если два клиента будут иметь разные максимальные номера (не до конца скачали), либо просто отправят сообщение одновременно. Может быть подойдет временная метка (точно покажет последовательность), но нужна синхронизация времени, которая не факт что проще, чем синхронизация количества сообщений в теме.
Пардон, промазал с ответом.
habrahabr.ru/blogs/p2p/107342/#comment_3385442
habrahabr.ru/blogs/p2p/107342/#comment_3385442
>Правильно понимаю, что каждое сообщение имеет указатель на «родителя-тему»?
Ага. С каждым сообщением опять же связать набор тегов, поэтому хешировать не каждое слово сообщения, а только ключевые. При этом чтобы не получать повторные данные можно в заголовки ответа включать время модификации (при условии наличия единого времени), т.е. проводить банальное кеширование.
Думаю, что чаще все-таки ищут по темам, а не сообщениям.
> Да еще хотелось бы передавать сообщения при создании (получении), а не получать послав запрос, т.е. сократив два движения в одно.
Передавать кому? Сразу всем участникам? Это дикий трафик. Вы предлагаете хранить у каждого свою копию форума? Это как-то сумбурно и очень накладно.
>Поиск по тегам вещь безусловная нужная, но без нее получается достаточно изолированная и «секретная» система: не зная хэш не найдешь тему. Это хорошая защита от спама.
Не знаю, это еще и защита от пользователя…
>Я не уверен, что понял правильно, но кажется вы предлагаете синхронизировать тему через «держателя», обычно пользователя, который начал разговор?
Нет, держатель имеет право ее модифицировать (удалять неугодные, цензурить и т.п.)
У вас список «узлов, хранящие тему» это все участники? — Нет. Это узлы, ответственные за хэш названия темы.
>Проблема как идентифицировать сообщения, чтобы у всех участников они были одинаковыми, чтобы запрашивать только недостающие сообщения.
Я вообще предлагаю стягивать только нужное по поиску :) знать только список разделов форума на первом этапе, все остальное — поиск…
Ага. С каждым сообщением опять же связать набор тегов, поэтому хешировать не каждое слово сообщения, а только ключевые. При этом чтобы не получать повторные данные можно в заголовки ответа включать время модификации (при условии наличия единого времени), т.е. проводить банальное кеширование.
Думаю, что чаще все-таки ищут по темам, а не сообщениям.
> Да еще хотелось бы передавать сообщения при создании (получении), а не получать послав запрос, т.е. сократив два движения в одно.
Передавать кому? Сразу всем участникам? Это дикий трафик. Вы предлагаете хранить у каждого свою копию форума? Это как-то сумбурно и очень накладно.
>Поиск по тегам вещь безусловная нужная, но без нее получается достаточно изолированная и «секретная» система: не зная хэш не найдешь тему. Это хорошая защита от спама.
Не знаю, это еще и защита от пользователя…
>Я не уверен, что понял правильно, но кажется вы предлагаете синхронизировать тему через «держателя», обычно пользователя, который начал разговор?
Нет, держатель имеет право ее модифицировать (удалять неугодные, цензурить и т.п.)
У вас список «узлов, хранящие тему» это все участники? — Нет. Это узлы, ответственные за хэш названия темы.
>Проблема как идентифицировать сообщения, чтобы у всех участников они были одинаковыми, чтобы запрашивать только недостающие сообщения.
Я вообще предлагаю стягивать только нужное по поиску :) знать только список разделов форума на первом этапе, все остальное — поиск…
> Передавать кому? Сразу всем участникам? Это дикий трафик. Вы предлагаете хранить у каждого свою копию форума? Это как-то сумбурно и очень накладно
Это еще одна проблема. Передавать нужно не всем, а каким-то определенным участникам. Например «ближайшим» через XOR. Например двум: выше(+1) и ниже(-1) вашего идентификатора. Каждый из них передает так же, но тогда вам дважды придет ваше же сообщени.
А вот хранить придется все сообщения из темы у каждого участника темы. Конечно все-все-все сообщения системы хранить ни к чему. Хотя предусмотреть передачу сообщений через клиента-не-участника-темы все же желательно.
> Не знаю, это еще и защита от пользователя…
Конечно. Варианты: 1) по приглашению, а значит тегов никаких нет, и поиска не получится; 2) с тегами, с «подключением» к старшему уровню (теме)
> Нет, держатель имеет право ее модифицировать (удалять неугодные, цензурить и т.п.)
Понял. Тогда придется предусмотреть набор команд для удаления у остальных (а клиент может ее и не выполнять). И вообще я против вахтеров; ) Каждый должен сам решать, что ему читать.
> знать только список разделов форума на первом этапе, все остальное — поиск…
Т.е. единственный вариант: запрашивать хэш темы(раздела, форума) и получать сообщения из нее? Тогда вопрос: как указать, какие у вас сообщения уже есть, чтобы их не присылали?
У меня пока что единственная мысль, которая может сработать: ограничить количество сообщений в теме. Допустим 256 блоков, по 256 сообщений. Тогда можно сделать как bittorrent: при запросе посылать битовую маску блоков, которые уже есть. И, если блок не полный, то еще одну маску обозначающую имеющиеся сообщения. Хотя тут все равно остается проблема, как давать сообщению «место» в битовой маске, т.е. его номер, чтобы несколько клиентов не создали разные сообщения одновременно с одним номером.
Это еще одна проблема. Передавать нужно не всем, а каким-то определенным участникам. Например «ближайшим» через XOR. Например двум: выше(+1) и ниже(-1) вашего идентификатора. Каждый из них передает так же, но тогда вам дважды придет ваше же сообщени.
А вот хранить придется все сообщения из темы у каждого участника темы. Конечно все-все-все сообщения системы хранить ни к чему. Хотя предусмотреть передачу сообщений через клиента-не-участника-темы все же желательно.
> Не знаю, это еще и защита от пользователя…
Конечно. Варианты: 1) по приглашению, а значит тегов никаких нет, и поиска не получится; 2) с тегами, с «подключением» к старшему уровню (теме)
> Нет, держатель имеет право ее модифицировать (удалять неугодные, цензурить и т.п.)
Понял. Тогда придется предусмотреть набор команд для удаления у остальных (а клиент может ее и не выполнять). И вообще я против вахтеров; ) Каждый должен сам решать, что ему читать.
> знать только список разделов форума на первом этапе, все остальное — поиск…
Т.е. единственный вариант: запрашивать хэш темы(раздела, форума) и получать сообщения из нее? Тогда вопрос: как указать, какие у вас сообщения уже есть, чтобы их не присылали?
У меня пока что единственная мысль, которая может сработать: ограничить количество сообщений в теме. Допустим 256 блоков, по 256 сообщений. Тогда можно сделать как bittorrent: при запросе посылать битовую маску блоков, которые уже есть. И, если блок не полный, то еще одну маску обозначающую имеющиеся сообщения. Хотя тут все равно остается проблема, как давать сообщению «место» в битовой маске, т.е. его номер, чтобы несколько клиентов не создали разные сообщения одновременно с одним номером.
Еще раз, соль моего варианта, что весь форум именно распределен, а не скопирован по узлам сети. Боюсь, что мы говорим об абсолютно разных вещах. Сообщения темы пользователь получает либо целиком, либо порциями, но только через поиск! Чтобы предотвратить лишний трафик, у темы есть дата изменения — это банально.
Просто расскажу, как я вижу работу своего варианта:
Я захожу, вижу список разделов… Ищу тему «куплю пылесос», у меня считается хэш этой фразы. Мне присылается тема/несколько, удовлетворяющих поиску, я выбираю нужную, подтягиваются сообщения из нее. Я постю ответ, при этом мое сообщение не остается у меня, а уходит на узел/узлы, ответственные за его хэш, я могу также определить теги для этого сообщения, если вдруг кто захочет искать по сообщениям, далее сообщение также регистрируется в теме (информация о его хэше).
Просто расскажу, как я вижу работу своего варианта:
Я захожу, вижу список разделов… Ищу тему «куплю пылесос», у меня считается хэш этой фразы. Мне присылается тема/несколько, удовлетворяющих поиску, я выбираю нужную, подтягиваются сообщения из нее. Я постю ответ, при этом мое сообщение не остается у меня, а уходит на узел/узлы, ответственные за его хэш, я могу также определить теги для этого сообщения, если вдруг кто захочет искать по сообщениям, далее сообщение также регистрируется в теме (информация о его хэше).
> Сообщения темы пользователь получает либо целиком, либо порциями, но только через поиск!
Согласитесь, что читать нужно все целиком. Другое дело, когда участник получает новые сообщения, тогда ему целиком качать не нужно все сообщения сразу. Но если он только подключился, то скачать надо все.
Не могу понять, как можно не хранить все сообщения темы, если их все нужно читать.
> Я постю ответ, при этом мое сообщение не остается у меня, а уходит на узел/узлы, ответственные за его хэш, я могу также определить теги для этого сообщения, если вдруг кто захочет искать по сообщениям, далее сообщение также регистрируется в теме (информация о его хэше).
«Отвественные узлы» хранят большое количество несвязанных сообщений? По близости хэша?
Разумно, для децентрализации и чтобы концов не найти. Но нет ли тут одной проблемы и одной странной недоработки.
1) Не участник темы, который хранит сообщения не имеет выгоды. Поясню: человек не читает конретную ветку (он и не знает, что она есть) и просто отключается. Навсегда. По вашей схеме получается, что сообщения хранятся у тех, кто их не читает, а значит и срок доступности сообщений уменьшается. Причем при таком раскладе бд на клиенте постоянно растет до бесконечности.
2) Клиент, который читает и пишет в тему не хранит сообщения. Но на компьютере у него они все равно будут (ну не качать же их каждый раз заново при подключении), только по его хэшу в вашей схеме у него никто не будет запрашивать сообщения, хотя у него, как у участника темы спросить их было бы проще всего.
Ну и непонятно, какая должна быть избыточность (на скольких клиентах хранить), чтобы тема была постоянно доступна целиком, а не частично. А то возникнет ситуация, что часть сообщений появляется (а то и совсем не появляется) в процессе чтения темы, причем в произвольном порядке.
В противовес, случай когда тема целиком хранится у участников темы. Сразу понятно у кого запрашивать. Сразу можно получать большие куски — несколько идущих подряд сообщений. Т.е. гонять не по одному килобайту, а сразу хорошую порцию.
Я так понял, ваша схема ничем не отличается от комментариев в Kad. Только дополнена поиском именно по комментариям и деревянной структурой комментарием. Т.е. получить новые сообщения, можно только полным опросом сети. Я же говорил о неком интерактиве: сообщение отсылается участникам по какой-то схеме в момент его создания. Для примера можно посмотреть Streamerp2p (там правда чат). Не знаю как там реализовано конкретно, но сообщения рассылаются в момент создания, и похоже, что блоком. И последний блок новый клиент получает в момент подключения. А в форуме должна быть возможность скачать тему от начала.
Согласитесь, что читать нужно все целиком. Другое дело, когда участник получает новые сообщения, тогда ему целиком качать не нужно все сообщения сразу. Но если он только подключился, то скачать надо все.
Не могу понять, как можно не хранить все сообщения темы, если их все нужно читать.
> Я постю ответ, при этом мое сообщение не остается у меня, а уходит на узел/узлы, ответственные за его хэш, я могу также определить теги для этого сообщения, если вдруг кто захочет искать по сообщениям, далее сообщение также регистрируется в теме (информация о его хэше).
«Отвественные узлы» хранят большое количество несвязанных сообщений? По близости хэша?
Разумно, для децентрализации и чтобы концов не найти. Но нет ли тут одной проблемы и одной странной недоработки.
1) Не участник темы, который хранит сообщения не имеет выгоды. Поясню: человек не читает конретную ветку (он и не знает, что она есть) и просто отключается. Навсегда. По вашей схеме получается, что сообщения хранятся у тех, кто их не читает, а значит и срок доступности сообщений уменьшается. Причем при таком раскладе бд на клиенте постоянно растет до бесконечности.
2) Клиент, который читает и пишет в тему не хранит сообщения. Но на компьютере у него они все равно будут (ну не качать же их каждый раз заново при подключении), только по его хэшу в вашей схеме у него никто не будет запрашивать сообщения, хотя у него, как у участника темы спросить их было бы проще всего.
Ну и непонятно, какая должна быть избыточность (на скольких клиентах хранить), чтобы тема была постоянно доступна целиком, а не частично. А то возникнет ситуация, что часть сообщений появляется (а то и совсем не появляется) в процессе чтения темы, причем в произвольном порядке.
В противовес, случай когда тема целиком хранится у участников темы. Сразу понятно у кого запрашивать. Сразу можно получать большие куски — несколько идущих подряд сообщений. Т.е. гонять не по одному килобайту, а сразу хорошую порцию.
Я так понял, ваша схема ничем не отличается от комментариев в Kad. Только дополнена поиском именно по комментариям и деревянной структурой комментарием. Т.е. получить новые сообщения, можно только полным опросом сети. Я же говорил о неком интерактиве: сообщение отсылается участникам по какой-то схеме в момент его создания. Для примера можно посмотреть Streamerp2p (там правда чат). Не знаю как там реализовано конкретно, но сообщения рассылаются в момент создания, и похоже, что блоком. И последний блок новый клиент получает в момент подключения. А в форуме должна быть возможность скачать тему от начала.
>Согласитесь, что читать нужно все целиком.
Не согласен :) Я про пейджер говорил, т.е. сначала скачать первые 50, потом, при желании пользователя, еще 50 и т.п.
>«Отвественные узлы» хранят большое количество несвязанных сообщений? По близости хэша?
Да.
>1) Не участник темы, который хранит сообщения не имеет выгоды. Поясню: человек не читает конретную ветку (он и не знает, что она есть) и просто отключается. Навсегда. По вашей схеме получается, что сообщения хранятся у тех, кто их не читает, а значит и срок доступности сообщений уменьшается. Причем при таком раскладе бд на клиенте постоянно растет до бесконечности.
Да, частично проблему решит хранение сразу на нескольких ближайших. (Как и сделано в той же Kademlia). Однако, я не думаю, что интерес участника увеличивается, если он хранит только свои сообщения. Ведь нужно, чтоб их читали => опять же оставаться в сети. Понимаете? Тут в любом случае необходимо пребывание.
>2) Клиент, который читает и пишет в тему не хранит сообщения. Но на компьютере у него они все равно будут (ну не качать же их каждый раз заново при подключении), только по его хэшу в вашей схеме у него никто не будет запрашивать сообщения, хотя у него, как у участника темы спросить их было бы проще всего.
Резонно. Он может от них избавляться при публикации.
>Ну и непонятно, какая должна быть избыточность (на скольких клиентах хранить), чтобы тема была постоянно доступна целиком, а не частично. А то возникнет ситуация, что часть сообщений появляется (а то и совсем не появляется) в процессе чтения темы, причем в произвольном порядке.
Экспериментально :)
>В противовес, случай когда тема целиком хранится у участников темы. Сразу понятно у кого запрашивать. Сразу можно получать большие куски — несколько идущих подряд сообщений. Т.е. гонять не по одному килобайту, а сразу хорошую порцию.
Т.е. поступать как с файлами? Хранить у ближайших к хешу только информацию о нахождении сообщения? :) Можно и так.
>Т.е. получить новые сообщения, можно только полным опросом сети.
Не то что бы полным… опросить содержимое темы, по содержимому опросить записанные хэши новых сообщений у ответственных узлов.
Не согласен :) Я про пейджер говорил, т.е. сначала скачать первые 50, потом, при желании пользователя, еще 50 и т.п.
>«Отвественные узлы» хранят большое количество несвязанных сообщений? По близости хэша?
Да.
>1) Не участник темы, который хранит сообщения не имеет выгоды. Поясню: человек не читает конретную ветку (он и не знает, что она есть) и просто отключается. Навсегда. По вашей схеме получается, что сообщения хранятся у тех, кто их не читает, а значит и срок доступности сообщений уменьшается. Причем при таком раскладе бд на клиенте постоянно растет до бесконечности.
Да, частично проблему решит хранение сразу на нескольких ближайших. (Как и сделано в той же Kademlia). Однако, я не думаю, что интерес участника увеличивается, если он хранит только свои сообщения. Ведь нужно, чтоб их читали => опять же оставаться в сети. Понимаете? Тут в любом случае необходимо пребывание.
>2) Клиент, который читает и пишет в тему не хранит сообщения. Но на компьютере у него они все равно будут (ну не качать же их каждый раз заново при подключении), только по его хэшу в вашей схеме у него никто не будет запрашивать сообщения, хотя у него, как у участника темы спросить их было бы проще всего.
Резонно. Он может от них избавляться при публикации.
>Ну и непонятно, какая должна быть избыточность (на скольких клиентах хранить), чтобы тема была постоянно доступна целиком, а не частично. А то возникнет ситуация, что часть сообщений появляется (а то и совсем не появляется) в процессе чтения темы, причем в произвольном порядке.
Экспериментально :)
>В противовес, случай когда тема целиком хранится у участников темы. Сразу понятно у кого запрашивать. Сразу можно получать большие куски — несколько идущих подряд сообщений. Т.е. гонять не по одному килобайту, а сразу хорошую порцию.
Т.е. поступать как с файлами? Хранить у ближайших к хешу только информацию о нахождении сообщения? :) Можно и так.
>Т.е. получить новые сообщения, можно только полным опросом сети.
Не то что бы полным… опросить содержимое темы, по содержимому опросить записанные хэши новых сообщений у ответственных узлов.
> Не согласен :) Я про пейджер говорил, т.е. сначала скачать первые 50, потом, при желании пользователя, еще 50 и т.п.
Ладно. Первые 50 ведь все нужно? И желательно подряд.
> Да, частично проблему решит хранение сразу на нескольких ближайших. (Как и сделано в той же Kademlia). Однако, я не думаю, что интерес участника увеличивается, если он хранит только свои сообщения. Ведь нужно, чтоб их читали => опять же оставаться в сети. Понимаете? Тут в любом случае необходимо пребывание.
О том и речь, поэтому я и говорю, что копия темы должна быть у каждого участника, а не только у некоторых клиентов с похожим хэшем. Тогда получится, что 1) хранит он все не зря, 2) при наличии хотя бы одного участника в сети есть возможность получить тему. Хотя это не исключает возможности хранения сообщений разбросанными согласно хэшу по другим клиентам не участникам темы.
> Т.е. поступать как с файлами? Хранить у ближайших к хешу только информацию о нахождении сообщения? :) Можно и так.
Ага.
А можно и совместить: хранить сообщения и хранить адрес где их можно взять в полном объеме.
Тут момент еще один есть: уместно ли вообще хранить сообщения не у участника темы. Т.е. при нешифрованных несекретных сообщениях проблем нет. А если хочется сделать относительно защищенную (хотя бы против дурака) систему?
Нужно шифровать. А там нужно как-то передавать ключ. А там еще что-нибудь. Т.е. это уже более прикладные вопросы. Но они зависят от общей концепции архитектуры.
> опросить содержимое темы, по содержимому опросить записанные хэши новых сообщений у ответственных узлов.
Смущает, что надо будет опрашивать сеть о наличии новых сообщений с какой-то периодичностью. Т.е. реально сотня мертвых тем, а клиент все равно просит поискать что-то новенькое. В идеале: запрашивать о новых сообщениях не нужно, ввести «подписчика темы» и новые сообщения рассылаются между подписчиками. Плюс возможность для новых участников получать содержимое темы по запросу (также полезно для старых участников, которые уже опредленное время не получали новых сообщений).
Ладно. Первые 50 ведь все нужно? И желательно подряд.
> Да, частично проблему решит хранение сразу на нескольких ближайших. (Как и сделано в той же Kademlia). Однако, я не думаю, что интерес участника увеличивается, если он хранит только свои сообщения. Ведь нужно, чтоб их читали => опять же оставаться в сети. Понимаете? Тут в любом случае необходимо пребывание.
О том и речь, поэтому я и говорю, что копия темы должна быть у каждого участника, а не только у некоторых клиентов с похожим хэшем. Тогда получится, что 1) хранит он все не зря, 2) при наличии хотя бы одного участника в сети есть возможность получить тему. Хотя это не исключает возможности хранения сообщений разбросанными согласно хэшу по другим клиентам не участникам темы.
> Т.е. поступать как с файлами? Хранить у ближайших к хешу только информацию о нахождении сообщения? :) Можно и так.
Ага.
А можно и совместить: хранить сообщения и хранить адрес где их можно взять в полном объеме.
Тут момент еще один есть: уместно ли вообще хранить сообщения не у участника темы. Т.е. при нешифрованных несекретных сообщениях проблем нет. А если хочется сделать относительно защищенную (хотя бы против дурака) систему?
Нужно шифровать. А там нужно как-то передавать ключ. А там еще что-нибудь. Т.е. это уже более прикладные вопросы. Но они зависят от общей концепции архитектуры.
> опросить содержимое темы, по содержимому опросить записанные хэши новых сообщений у ответственных узлов.
Смущает, что надо будет опрашивать сеть о наличии новых сообщений с какой-то периодичностью. Т.е. реально сотня мертвых тем, а клиент все равно просит поискать что-то новенькое. В идеале: запрашивать о новых сообщениях не нужно, ввести «подписчика темы» и новые сообщения рассылаются между подписчиками. Плюс возможность для новых участников получать содержимое темы по запросу (также полезно для старых участников, которые уже опредленное время не получали новых сообщений).
>Ладно. Первые 50 ведь все нужно? И желательно подряд.
Да.
>О том и речь, поэтому я и говорю, что копия темы должна быть у каждого участника, а не только у некоторых клиентов с похожим хэшем. Тогда получится, что 1) хранит он все не зря, 2) при наличии хотя бы одного участника в сети есть возможность получить тему. Хотя это не исключает возможности хранения сообщений разбросанными согласно хэшу по другим клиентам не участникам темы.
Так или иначе, она у него появится, когда он ее запросит :) Поэтому участник темы сразу становится обладателем ее копии. Тогда можно внутри файла темы записать и его контакты, чтобы получать сообщения. Ведь он тоже может и будет делать STORE от своего лица! Всего того, что он скачал :)
>Тут момент еще один есть: уместно ли вообще хранить сообщения не у участника темы. Т.е. при нешифрованных несекретных сообщениях проблем нет. А если хочется сделать относительно защищенную (хотя бы против дурака) систему?
Нужно шифровать. А там нужно как-то передавать ключ. А там еще что-нибудь. Т.е. это уже более прикладные вопросы. Но они зависят от общей концепции архитектуры.
Да, не секурно, если это критично :) Приходим опять же к хранению не самих данных, а контактной информации о них…
>В идеале: запрашивать о новых сообщениях не нужно, ввести «подписчика темы» и новые сообщения рассылаются между подписчиками.
Хороший вариант.
Да.
>О том и речь, поэтому я и говорю, что копия темы должна быть у каждого участника, а не только у некоторых клиентов с похожим хэшем. Тогда получится, что 1) хранит он все не зря, 2) при наличии хотя бы одного участника в сети есть возможность получить тему. Хотя это не исключает возможности хранения сообщений разбросанными согласно хэшу по другим клиентам не участникам темы.
Так или иначе, она у него появится, когда он ее запросит :) Поэтому участник темы сразу становится обладателем ее копии. Тогда можно внутри файла темы записать и его контакты, чтобы получать сообщения. Ведь он тоже может и будет делать STORE от своего лица! Всего того, что он скачал :)
>Тут момент еще один есть: уместно ли вообще хранить сообщения не у участника темы. Т.е. при нешифрованных несекретных сообщениях проблем нет. А если хочется сделать относительно защищенную (хотя бы против дурака) систему?
Нужно шифровать. А там нужно как-то передавать ключ. А там еще что-нибудь. Т.е. это уже более прикладные вопросы. Но они зависят от общей концепции архитектуры.
Да, не секурно, если это критично :) Приходим опять же к хранению не самих данных, а контактной информации о них…
>В идеале: запрашивать о новых сообщениях не нужно, ввести «подписчика темы» и новые сообщения рассылаются между подписчиками.
Хороший вариант.
Было бы ещё здорово, если бы вы проиллюстрировали аргументы сообщений (ping, store, find_value, find_node) в виде списка формальных параметров к каждому «методу». Трудно воспринимается, не очень понятно, где что передаётся.
И я правильно понял, что данные (в виде хэшей) хранятся на ближайших к ним (к их хэшам) узлам, а не на ближайших к нашему идентификатору?
И я правильно понял, что данные (в виде хэшей) хранятся на ближайших к ним (к их хэшам) узлам, а не на ближайших к нашему идентификатору?
>И я правильно понял, что данные (в виде хэшей) хранятся на ближайших к ним (к их хэшам) узлам, а не на ближайших к нашему идентификатору?
Да. Только сами данные остаются у того, кто делает запрос STORE. Узлы, ближайшие к хэшу хранят кэш и контактную информацию узла, сделавшего STORE.
Да. Только сами данные остаются у того, кто делает запрос STORE. Узлы, ближайшие к хэшу хранят кэш и контактную информацию узла, сделавшего STORE.
Так, ну для каждого типа сообщений есть REQ и RES вариант. В зависимости от того, запрос это или ответ, т.е.:
PING_REQ/PING_RES
STORE_REQ/STORE_RES
и т. п.
Для каждого REQ создается уникальный ID сообщения, чтобы при получении RES с тем же ID запрос можно было считать завершенным. Поэтому про ID запроса я дальше уже упоминать не буду, он есть у каждого запроса и ответа.
Аргумент PING — IP:Port. Банально :) Скорее всего, опять же есть какой-то time-out. Вернется через RES статус.
Аргумент STORE — hash, ip:port владельца. Т.е. запрос на сохранение ключа(хэша), значение которого лежит по заданному адресу. Через RES вернет K узлов, опубликовавших файл, в виде кортежей (см. далее).
Аргумент FIND_NODE — hash. Это ID узла, который, например, присоединяется в сеть (как в описанном ранее случае), с помощью RES возвращается кортеж из не более K элементов, вида <NODE_ID, IP:Port>
Аргумент FIND_VALUE — hash. Будет возвращать либо кортежи, либо IP:Port, по которому лежат данные.
Как-то вот получается…
PING_REQ/PING_RES
STORE_REQ/STORE_RES
и т. п.
Для каждого REQ создается уникальный ID сообщения, чтобы при получении RES с тем же ID запрос можно было считать завершенным. Поэтому про ID запроса я дальше уже упоминать не буду, он есть у каждого запроса и ответа.
Аргумент PING — IP:Port. Банально :) Скорее всего, опять же есть какой-то time-out. Вернется через RES статус.
Аргумент STORE — hash, ip:port владельца. Т.е. запрос на сохранение ключа(хэша), значение которого лежит по заданному адресу. Через RES вернет K узлов, опубликовавших файл, в виде кортежей (см. далее).
Аргумент FIND_NODE — hash. Это ID узла, который, например, присоединяется в сеть (как в описанном ранее случае), с помощью RES возвращается кортеж из не более K элементов, вида <NODE_ID, IP:Port>
Аргумент FIND_VALUE — hash. Будет возвращать либо кортежи, либо IP:Port, по которому лежат данные.
Как-то вот получается…
Хорошо, что эти давние задумки наконец-то развиваются.
По-хорошему, задача такова: нужна прозрачная интеграция псевдонимичной децентрализованной сети обмена данными поверх стандартного TCP/IP таким образом, чтобы для пользователя это был обычный обмен файлами — как WebDAV, например.
Ну то есть чтобы пользоваться этой сетью могла любая блондинка, не устанавливая дополнительного софта. Либо чтобы это было удобно и красиво, как uTorrent, например.
По-хорошему, задача такова: нужна прозрачная интеграция псевдонимичной децентрализованной сети обмена данными поверх стандартного TCP/IP таким образом, чтобы для пользователя это был обычный обмен файлами — как WebDAV, например.
Ну то есть чтобы пользоваться этой сетью могла любая блондинка, не устанавливая дополнительного софта. Либо чтобы это было удобно и красиво, как uTorrent, например.
Да-да! Я сам хожу погруженным в эти мысли уже пару дней. Что наличие Javascript реализации p2p + поддержка в браузерах протокола p2p:// могла бы перевернуть мир, если какая-нибудь соц. сеть взялась бы отвечать за bootstrap (поддержка в виде поля в профиле пользователя)…
Зачем такая сложность, браузеры и прочее?
Может, сервис или демон, следит за событиями системы, когда пользователь вставляет магнет ссылку, как файл, — начинается закачка. Вызвал контекстное меню любого файла, выбрал «создать магнет ссылку» — запустилась раздача и сгенерирована ссылка для публикации. То же можно делать и с торрент файлами.
Помотрите на Wuala — p2p хранилище и обмен.
Может, сервис или демон, следит за событиями системы, когда пользователь вставляет магнет ссылку, как файл, — начинается закачка. Вызвал контекстное меню любого файла, выбрал «создать магнет ссылку» — запустилась раздача и сгенерирована ссылка для публикации. То же можно делать и с торрент файлами.
Помотрите на Wuala — p2p хранилище и обмен.
PS не обязательно вставлять ссылку, можно, также, запускать закачку, когда кто-то или что-то пытается открыть файл у которого имя является магнет ссылкой — по мере загрузки открывается содержимое раздачи.
PS2 Для «блондинок» необходимо, чтобы данная служба/демон следили за рейтингом и, даже если пользователь удалит загруженный контент, — наименее доступные части раздаются из кеша. IMHO: учитывая возможности современной техники — пользователь, даже, не должен знать такого слова, как «рейтинг».
PS3 Была бы интересна возможность, кроме содержимого раздачи, получать актуальную информацию о новых версиях и о месте данной раздачи в иерархии: лежала ссылка месяц, поставил на закачку, и тут же узнаешь, что это продолжение какой-то раздачи и уже есть новая версия… Возможностей появляется куча! От публикации и хранения документов, до информации о новых качественных раздачах.
PS2 Для «блондинок» необходимо, чтобы данная служба/демон следили за рейтингом и, даже если пользователь удалит загруженный контент, — наименее доступные части раздаются из кеша. IMHO: учитывая возможности современной техники — пользователь, даже, не должен знать такого слова, как «рейтинг».
PS3 Была бы интересна возможность, кроме содержимого раздачи, получать актуальную информацию о новых версиях и о месте данной раздачи в иерархии: лежала ссылка месяц, поставил на закачку, и тут же узнаешь, что это продолжение какой-то раздачи и уже есть новая версия… Возможностей появляется куча! От публикации и хранения документов, до информации о новых качественных раздачах.
> В сочетании с Peer Exchange, например, DHT позволяет перехватить функции Torrent-трекера
?
?
Sign up to leave a comment.
Kademlia DHT: Основы