С производительностью и совместимостью мунлайт есть определенные проблемы, не только у меня…
Что ж, не буду утверждать, что профессионал, поэтому второй пункт приму на веру :)
1. Не хочу я смотреть видеокурс на Silverlight, почему это так в духе Microsoft — безальтернативно. Я сейчас с Gentoo Linux, но по работе тема топика весьма интересна и заманчива.
2. Про файл ответов… Странно, но не проще ли воспользоваться сторонними утилитами, типа nLite/vLite?
Да-да! Я сам хожу погруженным в эти мысли уже пару дней. Что наличие Javascript реализации p2p + поддержка в браузерах протокола p2p:// могла бы перевернуть мир, если какая-нибудь соц. сеть взялась бы отвечать за bootstrap (поддержка в виде поля в профиле пользователя)…
>Ладно. Первые 50 ведь все нужно? И желательно подряд.
Да.
>О том и речь, поэтому я и говорю, что копия темы должна быть у каждого участника, а не только у некоторых клиентов с похожим хэшем. Тогда получится, что 1) хранит он все не зря, 2) при наличии хотя бы одного участника в сети есть возможность получить тему. Хотя это не исключает возможности хранения сообщений разбросанными согласно хэшу по другим клиентам не участникам темы.
Так или иначе, она у него появится, когда он ее запросит :) Поэтому участник темы сразу становится обладателем ее копии. Тогда можно внутри файла темы записать и его контакты, чтобы получать сообщения. Ведь он тоже может и будет делать 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, по которому лежат данные.
>Согласитесь, что читать нужно все целиком.
Не согласен :) Я про пейджер говорил, т.е. сначала скачать первые 50, потом, при желании пользователя, еще 50 и т.п.
>«Отвественные узлы» хранят большое количество несвязанных сообщений? По близости хэша?
Да.
>1) Не участник темы, который хранит сообщения не имеет выгоды. Поясню: человек не читает конретную ветку (он и не знает, что она есть) и просто отключается. Навсегда. По вашей схеме получается, что сообщения хранятся у тех, кто их не читает, а значит и срок доступности сообщений уменьшается. Причем при таком раскладе бд на клиенте постоянно растет до бесконечности.
Да, частично проблему решит хранение сразу на нескольких ближайших. (Как и сделано в той же Kademlia). Однако, я не думаю, что интерес участника увеличивается, если он хранит только свои сообщения. Ведь нужно, чтоб их читали => опять же оставаться в сети. Понимаете? Тут в любом случае необходимо пребывание.
>2) Клиент, который читает и пишет в тему не хранит сообщения. Но на компьютере у него они все равно будут (ну не качать же их каждый раз заново при подключении), только по его хэшу в вашей схеме у него никто не будет запрашивать сообщения, хотя у него, как у участника темы спросить их было бы проще всего.
Резонно. Он может от них избавляться при публикации.
>Ну и непонятно, какая должна быть избыточность (на скольких клиентах хранить), чтобы тема была постоянно доступна целиком, а не частично. А то возникнет ситуация, что часть сообщений появляется (а то и совсем не появляется) в процессе чтения темы, причем в произвольном порядке.
Экспериментально :)
>В противовес, случай когда тема целиком хранится у участников темы. Сразу понятно у кого запрашивать. Сразу можно получать большие куски — несколько идущих подряд сообщений. Т.е. гонять не по одному килобайту, а сразу хорошую порцию.
Т.е. поступать как с файлами? Хранить у ближайших к хешу только информацию о нахождении сообщения? :) Можно и так.
>Т.е. получить новые сообщения, можно только полным опросом сети.
Не то что бы полным… опросить содержимое темы, по содержимому опросить записанные хэши новых сообщений у ответственных узлов.
Еще одно допустимое условие — вызов копирующего/move конструктора может опускаться, если объект не связан ссылкой в коде).
Кроме того, С++11 позволяет избегать и move-конструктора + добавляется еще два условия для Copy elision, связанные с обработкой исключений.
§12.8/31
(в добавок к ниженаписанному).
Что ж, не буду утверждать, что профессионал, поэтому второй пункт приму на веру :)
2. Про файл ответов… Странно, но не проще ли воспользоваться сторонними утилитами, типа nLite/vLite?
Да.
>О том и речь, поэтому я и говорю, что копия темы должна быть у каждого участника, а не только у некоторых клиентов с похожим хэшем. Тогда получится, что 1) хранит он все не зря, 2) при наличии хотя бы одного участника в сети есть возможность получить тему. Хотя это не исключает возможности хранения сообщений разбросанными согласно хэшу по другим клиентам не участникам темы.
Так или иначе, она у него появится, когда он ее запросит :) Поэтому участник темы сразу становится обладателем ее копии. Тогда можно внутри файла темы записать и его контакты, чтобы получать сообщения. Ведь он тоже может и будет делать STORE от своего лица! Всего того, что он скачал :)
>Тут момент еще один есть: уместно ли вообще хранить сообщения не у участника темы. Т.е. при нешифрованных несекретных сообщениях проблем нет. А если хочется сделать относительно защищенную (хотя бы против дурака) систему?
Нужно шифровать. А там нужно как-то передавать ключ. А там еще что-нибудь. Т.е. это уже более прикладные вопросы. Но они зависят от общей концепции архитектуры.
Да, не секурно, если это критично :) Приходим опять же к хранению не самих данных, а контактной информации о них…
>В идеале: запрашивать о новых сообщениях не нужно, ввести «подписчика темы» и новые сообщения рассылаются между подписчиками.
Хороший вариант.
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, по которому лежат данные.
Как-то вот получается…
Да. Только сами данные остаются у того, кто делает запрос STORE. Узлы, ближайшие к хэшу хранят кэш и контактную информацию узла, сделавшего STORE.
Не согласен :) Я про пейджер говорил, т.е. сначала скачать первые 50, потом, при желании пользователя, еще 50 и т.п.
>«Отвественные узлы» хранят большое количество несвязанных сообщений? По близости хэша?
Да.
>1) Не участник темы, который хранит сообщения не имеет выгоды. Поясню: человек не читает конретную ветку (он и не знает, что она есть) и просто отключается. Навсегда. По вашей схеме получается, что сообщения хранятся у тех, кто их не читает, а значит и срок доступности сообщений уменьшается. Причем при таком раскладе бд на клиенте постоянно растет до бесконечности.
Да, частично проблему решит хранение сразу на нескольких ближайших. (Как и сделано в той же Kademlia). Однако, я не думаю, что интерес участника увеличивается, если он хранит только свои сообщения. Ведь нужно, чтоб их читали => опять же оставаться в сети. Понимаете? Тут в любом случае необходимо пребывание.
>2) Клиент, который читает и пишет в тему не хранит сообщения. Но на компьютере у него они все равно будут (ну не качать же их каждый раз заново при подключении), только по его хэшу в вашей схеме у него никто не будет запрашивать сообщения, хотя у него, как у участника темы спросить их было бы проще всего.
Резонно. Он может от них избавляться при публикации.
>Ну и непонятно, какая должна быть избыточность (на скольких клиентах хранить), чтобы тема была постоянно доступна целиком, а не частично. А то возникнет ситуация, что часть сообщений появляется (а то и совсем не появляется) в процессе чтения темы, причем в произвольном порядке.
Экспериментально :)
>В противовес, случай когда тема целиком хранится у участников темы. Сразу понятно у кого запрашивать. Сразу можно получать большие куски — несколько идущих подряд сообщений. Т.е. гонять не по одному килобайту, а сразу хорошую порцию.
Т.е. поступать как с файлами? Хранить у ближайших к хешу только информацию о нахождении сообщения? :) Можно и так.
>Т.е. получить новые сообщения, можно только полным опросом сети.
Не то что бы полным… опросить содержимое темы, по содержимому опросить записанные хэши новых сообщений у ответственных узлов.