id: Гость   вход   регистрация
текущее время 23:25 28/03/2024
Вступить во владение редакция от 08/07/2009 17:09 (автор: Гость) Печать
Категории: инфобезопасность, политика, разное
создать
просмотр
редакции
ссылки

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

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

Цель


Создание сервиса (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, но это все же не есть проверить метку, а проверить заверял ли пользователь свой файл еще и на другом сервисе и когда он это делал (неважно автоматически или вручную)

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



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