id: Гость   вход   регистрация
текущее время 13:16 28/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 След.
Комментарии [скрыть комментарии/форму]
— Гость (11/07/2009 08:56)   <#>
можно проверить также с помощью любого сервиса
Но завтра :)
— Alex_B (13/07/2009 20:08)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Гость (09/07/2009 17:16):
Теория: Operational Transformation
На русском есть что-нибудь? Что-то не слишком понятно. Например, почему transformation function зависит от того чей идентификатор (sid) сайта больше?

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

poptalk:
Разумеется, не каждая метка будет подтверждена
Не вариант.

SATtva:
но взятый курс превратит её в самолёт, в функционировании которого без кандидатской не разберёшься... В отсутствие консенсуса есть риск остаться единственным разработчиком
Никакого курса не взято, только обсуждения идей и поиск того самого консенсуса.
"Хлавное нАчать и консенсус будет достигнут".

SATtva:
Тогда по логике и поле Signed-by не имеет смысла.
В общем да, можно указать что там указывается не URL сервиса а его название (GUID-слишком не юзерфрендли). Ведь сервис теоретически может сменить домен и перекочевать со всей своей цепочкой на другой адрес. Можно при описании сделать оговорку, что очень рекомендовано называть сервис доменным именем по которому он доступен.

Гость (10/07/2009 21:47):
нужно ввести возможность слияния (конвергенции) двух цепочек в одну, то есть в формат метки времени нужно ввести поля не для одного, а для двух независимых предшественников
Интересная идея, только наверно не для двух предшественников а для сколько угодно предшественников. Что-то типа такого

Так я понял идею?
Вопрос: допустим у меня есть метка времени(T (timestamp) ) полученная на сервисе A (Ta). Эта метка содержит поля Ref-Hash от крайней на тот момент метки времени сервиса B.
Выдав еще какое-то количество меток сервис A отваливается. Как мне доказывать правдивость мой метки Ta, при условии что дружественный сервис B продолжает работать?


Вот ещё для обсуждения: Что если все дружественные сервисы ведут цепочку с единой нумерацией. При создании новой метки времени сервисы опрашиваются на предмет у кого порядковый номер последней метки больше. От этой метки и считается Ref-Hash. Раз в день или раз в неделю, сервисы обмениваются метками времени, заполняя в своих базах пропущенные номера.
— SATtva (13/07/2009 20:25)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вот ещё для обсуждения: Что если все дружественные сервисы ведут цепочку с единой нумерацией.

Нужно ли? Тут неминуемо возникнут проблемы с синхронизацией. Допустим, провайдер одного из сервисов затеял технические работы (или просто сайт задосили), тогда и все "дружественные" сервисы на время отпрявятся в вынужденный отпуск.
— poptalk (14/07/2009 08:17)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Вопрос: допустим у меня есть метка времени(T (timestamp) ) полученная на сервисе A (Ta). Эта метка содержит поля Ref-Hash от крайней на тот момент метки времени сервиса B.
Выдав еще какое-то количество меток сервис A отваливается. Как мне доказывать правдивость мой метки Ta, при условии что дружественный сервис B продолжает работать?

Я полагаю, нужно сервис B должен выдать метку, содержащую хэш метки Ta.

Разумеется, не каждая метка будет подтверждена
Не вариант.

И всё-таки, с какой целью нужно сначала размножать сервисы, а потом их синхронизировать?
— Гость (14/07/2009 11:21)   <#>
Я полагаю, нужно сервис B должен выдать метку, содержащую хэш метки Ta.
Не понял, где содержать?

И всё-таки, с какой целью нужно сначала размножать сервисы, а потом их синхронизировать?
Что бы пользователь не зависил от одного сервиса. Что бы при удалении сервиса его пользователи могли доказать легальность своих меток времени, пока существует хотябы один сервис.
— SATtva (14/07/2009 11:28)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Что бы при удалении сервиса его пользователи могли доказать легальность своих меток времени, пока существует хотябы один сервис.

Я-то полагал, что цель — не выживаемость системы, а больший доказательный вес выдаваемых меток. Если предъявленная метка была выдана только одним сервером, остаётся вероятность, что вся цепочка меток могла быть подделана. Если же действует несколько серверов, администрируемых независимыми лицами, то метка, подтверждённая множеством из них, очевидно будет более доверенной.
— poptalk (14/07/2009 11:31)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Что бы пользователь не зависил от одного сервиса. Что бы при удалении сервиса его пользователи могли доказать легальность своих меток времени, пока существует хотябы один сервис.

Я тоже об этом думал, пока не нашёл более простое решение. :) Чтобы пользователь не зависел от одного сервиса, пусть получает метки от всех сервисов. Нет нужды их синхронизировать.

Я полагаю, сервис B должен выдать метку, содержащую хэш метки Ta.

Не понял, где содержать?

Ну, метка времени — это кроме прочего набор хэшей: пользовательских данных, предыдущих меток времени. Либо вы введёте дополнительное поле для хэша метки времени стороннего сервиса, либо пользовательские данные будут являться меткой времени стороннего сервиса.
— Гость (14/07/2009 11:40)   <#>
Я-то полагал, что цель — не выживаемость системы, а больший доказательный вес выдаваемых меток.
Это тоже важно.

Либо вы введёте дополнительное поле для хэша метки времени стороннего сервиса, либо пользовательские данные будут являться меткой времени стороннего сервиса.
Во избежание путанице предлагаю указывать названия полей :)
— Гость (14/07/2009 18:59)   <#>
А чем вам не нравится это, самое простое, на мой взгляд, решение:
пусть на каждом сервере будут просто храниться цепочки всех сервисов. Каждый сервис зеркалирует (инкрементально) остальные, к примеру, ежесуточно, посде чего делает метку времени на эту общую базу как на отдельный документ
Минус, на мой взгляд, только в лаге синхронизации, но поскольку она инкрементальная, её можно делать достаточно часто.
— poptalk (14/07/2009 21:54)   профиль/связь   <#>
комментариев: 271   документов: 13   редакций: 4
Либо вы введёте дополнительное поле для хэша метки времени стороннего сервиса, либо пользовательские данные будут являться меткой времени стороннего сервиса.

Во избежание путанице предлагаю указывать названия полей :)

названия полей
пользовательские данные — Hash-*
дополнительное поле для хэша метки времени стороннего сервиса — «утверждённого названия» пока нет
— Гость (21/07/2009 17:09)   <#>
Гость (14/07/2009 18:59):
А чем вам не нравится это, самое простое, на мой взгляд, решение:
Как отметил SATtva, хочется понятности для пользователя. Что бы имея на руках единственную метку времени он мог её проверить. А не идти на сайт и вычитывать на каких сервисах он копирует свои метки...
— Гость (21/07/2009 20:20)   <#>
Если каждый сервис будет зеркалировать все остальные, обратиться можно будет к любому.
— Гость (21/07/2009 22:07)   <#>
как заставить все зеркалить всеж? Да и не нужно это.
— Гость (22/07/2009 11:00)   <#>
как заставить все зеркалить всеж?
Чисто программным путём, без всякого физического насилия. :)
Да и не нужно это.
Тогда предложите более простое решение, удовлетворяющее вашим же требованиям.
— Гость (22/07/2009 12:00)   <#>
удовлетворяющее вашим же требованиям
Готово.

предложите более простое решение
А решение не обязательно должно быть простым. Данная ветка как раз и создана что бы предлагать и обсуждать.
На страницу: 1, 2, 3 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3