id: Гость   вход   регистрация
текущее время 10:03 19/03/2024
Вступить во владение (создано 24/06/2009 15:57), редакция от 22/07/2009 11:57 (автор: Гость) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

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

< Все документы:
Оглавление документа:

Цель


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


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


Вариант 1


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


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


Вариант 2


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


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


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

Вариант 3


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


  1. Сервис передаёт запросы-поддержки всем дружественным серверам одновременно.
  2. Одна метка времени, выдаваемая пользователю, может содержать произвольное число полей 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. Дружественные сервера, получив запрос на подтверждение метки, не делают собственные запросы-поддержки во избежание рекурсий.



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


 
На страницу: 1, 2, 3 След.
Комментарии [скрыть комментарии/форму]
— Гость (09/07/2009 10:31)   <#>
Чем плох вариант без изменения формата (вариант 1)?
— Гость (09/07/2009 12:27)   <#>
Для асинхронных коммуникаций в сети рекомендую обратить внимание на Google Wave Federation Protocol (Over XMPP)
— Гость (09/07/2009 17:16, исправлен 09/07/2009 18:43)   <#>
Теория:
Operational Transformation
Google Wave Operational Transformation
— SATtva (09/07/2009 18:43)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Wave Federation излишне тяжеловесен для такой задачи, imho.
— Гость (10/07/2009 00:35)   <#>
Зато можно будет попроситься на работу в гугл. :)
— Гость (10/07/2009 14:02)   <#>
Спасибо за ссылки – попробую разобраться в выходные.

На мой взгляд сперва надо решить следующие вопросы:

1. Менять ли формат "меток времени" (добавить новое поле Confirm-stamp)?

Если менять формат, то:
2. В поле Confirm-stamp записывается "метка времени" которую подтверждает данная(родительская) метка?
Или в поле Confirm-stamp записывается что-то что подтверждает данную "метку времени"?
— SATtva (10/07/2009 14:26)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Менять ли формат "меток времени" (добавить новое поле Confirm-stamp)?

Моё мнение — да. И повысить версию в Timestamp-version.

В поле Confirm-stamp записывается "метка времени" которую подтверждает данная(родительская) метка?
Или в поле Confirm-stamp записывается что-то что подтверждает данную "метку времени"?

На мой взгляд, лучше второй вариант, желательно в формате полного url до подтверждающей метки, чтобы можно было её запросить в автоматическом режиме. Это позволит пользователю получить свою метку у данного сервиса и больше не морочить себе голову, но при необходимости взять дополнительные подтверждения, полагаясь лишь на информацию в полученной метке. Ну, и, так в метке могут содержаться ссылки на несколько подтверждений. Примерно так:

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

Не согласен – API доступа может смениться, оно то к формату никакого отношения не имеет.

Описанный вариант это практически тоже самое что в ручную пройтись по списку сервисов меток времени и сделать на каждом свою метку.
Вижу недостаток – чем больше дружественных серверов (а к множеству серверов и стремимся) тем дольше пользователь ждет изготовления метки.

Еще не учитывается момент:
Допустим есть сервисы A, B, C, D.
B и С – это дружественные сервера для A.
D – это дружественный сервис для C.

Делая метку на сервисе A пользователь по идее должен получить возможность проверки своей метки и на сервисе D.
(полагаю описанная ситуация как раз и описывается по ссылкам выше (еще не читал))
— SATtva (10/07/2009 18:15)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Не согласен – API доступа может смениться, оно то к формату никакого отношения не имеет.

Причём тут API? Есть такая общепринятая штука, как permalink. Сервис должен обеспечивать доступ к меткам по постоянным ссылкам; они не обязаны быть стандартизированными, только неизменными.
— Гость (10/07/2009 20:34)   <#>

Мне кажется, что каким образом сервис предоставляет цепочки меток никаким образом оговариваться не должно. Похорошему и к урл сервиса привязки нежелательны (ИМХО).
— SATtva (10/07/2009 20:49)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Тогда по логике и поле Signed-by не имеет смысла.
— Гость (10/07/2009 21:26)   <#>
Пользователю не интересны детали реализации – логически это должно выглядеть как один сервис, не зависимо от того, сколько физических серверов там участвует. Ну типа raid-массив дисков, который виден как один.
— SATtva (10/07/2009 21:31)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если пользователь не может определить, что метки выдаются независимыми друг от друга сервисами, то какой смысл в подтверждениях меток времени? Идея именно в том, что они явно должны различаться, но подтверждать друг друга для большего веса свидетельства.
— Гость (10/07/2009 21:47)   <#>
По моему для нормальной асинхронной работы нужно ввести возможность слияния (конвергенции) двух цепочек в одну, то есть в формат метки времени нужно ввести поля не для одного, а для двух независимых предшественников и тогда будет строиться уже не цепочка а ациклический граф меток времени.
— Гость (10/07/2009 21:52)   <#>
Если пользователь не может определить, что метки выдаются независимыми друг от друга сервисами
Ну не надо совсем забирать у него такую возможность. Дать более низкоуровневый интерфейс "для продвинутых". А простым пользователям не надо по умолчанию забивать голову излишними подробностями.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3