Децентрализация сервиса

< Все документы:

Оглавление документа:

Цель

Создание сервиса (php, asp.net, java) который каждый желающий мог бы развернуть на своем сайте.

Сервисы могут быть дружественными по отношению друг к другу. Т.е. метку времени выданную любым из дружественных сервисов можно проверить с помощью любого дружественного ему сервиса.

Вариант 1

Каждый, кто разворачивает сервис меток времени (предположим, желающие есть) имеет возможность выбрать список сервисов, чьи цепочки меток времени он хочет поддерживать.
Так же владелец сервиса может выбрать сервисы, на которых он хочет дублировать свою цепочку меток времени.

Сервис создает и сохраняет «метку времени». После этого он делает запрос-поддержки на дружественные сервисы, передавая им только что созданную «метку времени».
Получив такой запрос-поддержки дружественный сервис вырабатывает «метку времени» на основе переданной метки. Переданная метка сохраняется с указанием ID метки, выработанной на её основе.
Пользователь может производить поиск меток на любом из дружественных серверов, указав URL сервиса.

Вариант 2

Также каждый сервис поддерживает список дружественных серверов. И также посылает на дружественные сервисы запрос-поддержки, содержащий новую дублируемую «метку времени».

В формат «меток времени» добавляется поле Confirm-stamp, которое содержит подтверждаемую метку времени (целиком).

Правда возможны большие «паразитные» связи, когда один сервис подтверждает метку второго, создавая при этом свою метку – которую отсылает для подтверждения третьему. Третий создает новую метку на основе этого запроса и пять отсылает её для подтверждения второму. Второй подтверждает у первого… и так до бесконечности.
Этот вопрос тоже еще надо решить.

Вариант 3

Аналогичен предыдущему варианту, за исключением:

Сервис передаёт запросы-поддержки всем дружественным серверам одновременно.
Одна метка времени, выдаваемая пользователю, может содержать произвольное число полей Confirm-stamp от всех дружественных серверов.

В какой ситуации может произойти что в метке будет более одного поля Confirm-stamp?
Как такое может произойти что сервис получил запросы на подтверждение метки времени от нескольких сервисов одновременно?

Допустим, сервис имеет список из трёх дружественных серверов. Когда пользователь запрашивает метку, сервис отправляет запросы-поддержки всем трём серверам, дожидается от них (в пределах таймаута) ответы с подтверждениями метки и включает все эти ответы в поля Confirm-stamp.

Что сервис отсылает в запросе поддержки? Выше я предлагал что он отсылает уже изготовленную метку времени. И сам ответов никаких не ждет. А поле Confirm-stamp содержит метку, которую подтверждает данная. А не наоборот – кажется не логичным, что в поле Confirm-stamp будет метка подтверждающая родительскую метку – ведь на момент изготовления метки для поля Confirm-stamp родительской метки еще не будет, т.к. для её создания нужна метка которую нужно записать в поле Confirm-stamp.
Если же предполагается отсылка данных пользователя, то зачем тогда дополнительное поле, пусть сервис сразу выдает кучу меток от нескольких серверов. Но тогда проверить чужую метку на другом сервисе будет не возможно, если не добавить поиск по полям hash, но это все же не есть проверить метку, а проверить заверял ли пользователь свой файл еще и на другом сервисе и когда он это делал (неважно автоматически или вручную)

Верно, я матчасть подзабыл. Но всё же мне представляется неверным, что подтвердить метку можно только у одного дополнительного сервера. В качестве развития мысли могу предложить отправлять подтверждающим серверам содержимое полей Hash-SHA512 и Hash-RIPEMD160. Тогда каждое поле Confirm-stamp будет содержать порядковый номер метки от подтверждающего сервера, а также его URL (т.е. поля Signed-by и Number). Что я здесь не учёл?

>мне представляется неверным, что подтвердить метку можно только у одного дополнительного сервера
Это я тоже считаю не правильным, но ведь из того что метка содержит одно поле Confirm-stamp не означает что нельзя отправить несколько запросов на подтверждение разным сервисам.
Мы смотрим на поле Confirm-stamp по-разному. Я предлагаю включать в это поле метку, которую подтверждает родительская. А вы включить в это поле доказательство правильности родительской метки. Что лучше?? В моем варианте не надо ждать ответов от дружественных сервисов (клиент получает метку сразу). Они могут отправлять запросы на подтверждение и попозже, возможно посылать запросы целыми пачками, тогда как раз можно несколько полей Confirm-stamp (так как я их предлагаю использовать) предусмотреть, что бы одна родительская метка заверяла сразу целую пачку

Дружественные сервера, получив запрос на подтверждение метки, не делают собственные запросы-поддержки во избежание рекурсий.

Какой вариант предпочтительнее? Есть ли другие варианты?

На страницу: 1, 2, 3 След.

Комментарии [скрыть комментарии/форму]

—	SATtva (10/07/2009 22:03) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Любому "простому пользователю" может рано или поздно понадобиться такая возможность — установить подтверждения метки, включая и восстановление цепочек, чтобы убедиться в отстутствии подлога. В идеале система должна быть настолько простой, чтобы всю работу можно было сделать практически "на коленке" (и она такой в общем и была до последнего времени), но взятый курс превратит её в самолёт, в функционировании которого без кандидатской не разберёшься. Простота, "наглядность" является критически важным свойством для контроля и доверия.

—	*Гость* (10/07/2009 22:13) <#>

Любому "простому пользователю" может рано или поздно понадобиться такая возможность — установить подтверждения метки

При достаточно большой базе ему всё равно придётся воспользовуаться программной проверкой. Кроме того, потребность в подтверждении случается гораздо реже, чем само проставление метки, imho.

—	SATtva (10/07/2009 22:21) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Нет. В большинстве случаев ему будет достаточно данной метки, предшествующей и последующей. И аналогично с подтверждающими метками на сторонних серверах. Последние как раз и упрощают задачу.

Проверка всей или значительной части цепи меток возможна, и в случае простого протокола может быть реализована простым скриптом даже на баше. Если не придётся для этого строить граф.

Своё imho я тоже высказал, спорить дальше не вижу смысла. По текущему предложению консенсуса нет.

—	*Гость* (10/07/2009 22:28) <#>

логически это должно выглядеть как один сервис, не зависимо от того, сколько физических серверов там участвует

Не лишайте потенциальных владельцев сервисов возможности потешить своё тщеславие. Это может сказаться на их количестве. :)

—	*Гость* (10/07/2009 22:37) <#>

Если не придётся для этого строить граф

В ациклическом графе нет ничего сложного – это просто дерево со "склееными" ветвями. А как без него получить асинхронность и масштабирование?

—	SATtva (10/07/2009 22:41) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

А как без него получить асинхронность и масштабирование?

В том и дело, что не вижу необходимости ни в первом, ни во втором.

—	*Гость* (10/07/2009 22:54) <#>

Cистему меток времени нужно встраивать непосредственно в Gооgle Wave Protocol, поскольку, imho, через несколько лет уже не останется никаких статичных документов (за исключением исторических), а будут только "волны".

—	*Гость* (10/07/2009 23:02) <#>

не вижу необходимости ни в первом, ни во втором

Ну раз так, то на нет и суда нет. А решать разработчику.

—	SATtva (10/07/2009 23:04) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Я Вас умоляю! Тут кто-то уже лет десять предрекает смерть мэйлу в пользу IM, но первый продолжают так же активно использовать (речь не о спамерах). Так же и с rich-media-контентом, который появляется и исчезает, не влияя на распространённость html.

—	SATtva (10/07/2009 23:06) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

Ну раз так, то на нет и суда нет. А решать разработчику.

В отсутствие консенсуса есть риск остаться единственным разработчиком и администратором единственного сервера.

—	*Гость* (10/07/2009 23:15) <#>

Так же и с rich-media-контентом, который появляется и исчезает, не влияя на распространённость html

Google Wave прекрасно подходит для совмесного визуального редактирования html в реальном времени. Вобщем, поживём – увидим...

—	SATtva (10/07/2009 23:18) профиль/связь <#> комментариев: 11558 документов: 1036 редакций: 4118

И работает без js или из "тонких" браузеров?

—	*Гость* (10/07/2009 23:30) <#>

Вопрос не в "толстоте" браузеров, а в адекватности динамического контента человеческой мыследеятельности. Поживём – увидим...

—	poptalk (11/07/2009 00:19, исправлен 11/07/2009 01:00) профиль/связь <#> комментариев: 271 документов: 13 редакций: 4

Было бы неплохо определиться с термином «дружественный». Дело в том, что в обыденной речи «дружественный», как и «друзья», означают симметричное отношение, а у вас используется асимметричное. Предлагаю обозначать это отношение стрелкой: «->» или «<-», направление стрелки совпадает с направлением передачи метки времени.

Я предлагаю ту метку времени, которая перелетает с сервиса A на сервис B (A -> B), трактовать как разновидность пользовательских данных. Хэш этих пользовательских данных хранится в полях Hash-*.

Тогда получаем модульность. Есть «сервис связывания хэшей» и «сервис обмена метками». Сервис обмена метками C спрашивает последнюю выданную метку времени у сервиса связывания хэшей A и регистрирует её как пользовательские данные на сервисе связывания хэшей B.

Ну и формат метки времени не меняется. Отпадают поле Confirm-stamp и соответственно варианты 2 и 3.

Правда возможны большие «паразитные» связи, когда один сервис подтверждает метку второго, создавая при этом свою метку – которую отсылает для подтверждения третьему. Третий создает новую метку на основе этого запроса и пять отсылает её для подтверждения второму. Второй подтверждает у первого… и так до бесконечности.

Один из вариантов убрать «паразитные» связи, то есть зацикливание: запретить отсылать метки времени. Метки времени должны запрашиваться, допустим, раз в сутки. Разумеется, не каждая метка будет подтверждена. Не знаю, то ли это, что вы хотели получить.

На этом этапе было бы неплохо раскрыть ваши цели. «Масштабируемость» лично я понял как выход из ситуации, когда запросов станет настолько много, что сервис окажется перегружен запросами. Допустим, мы будем регистрировать все сообщения в блогах, форумах и даже чатах. Если подтверждать каждую метку времени на все сервисы, то это увеличит глобальное количество запросов в несколько раз. Поэтому подтверждать каждую метку нежелательно.

—	*Гость* (11/07/2009 08:46) <#>

Любую «метку времени» выданную любым из развернутых сервисов можно проверить также с помощью любого сервиса.

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

На страницу: 1, 2, 3 След.

Ваша оценка документа [показать результаты]