Вот возникла интересная задача. Скорее даже теоретическая.
Пусть у нас есть некоторая сетевая система с несколькими равноправными серверами. Клиентское ПО может подключится к любому и конкретный выбор не отражается на поведении. Клиентское ПО пишет и читает данные с сервера. Время от времени сервера обмениваются данными полученными от клиентов. Пожалуй наиболее похожая система это Active Directory для Windows 2000 и выше.
Проблема: регистрация пользователя.
Пусть пользователь Вася Пупкин зашёл на сервер A и зарегистровал логин vasja, а пользователь Вася Тяпкин зашёл на сервер B и тоже зарегистрировал логин vasja. Очевидна проблема — что делать с двумя одинаковыми логинами (пользователи идентифицируются по GUIDам, но для аутенфикации используются логины)? Тем более что до того как ситуация будет обнаружена оба пользователя могут записать некоторые данные, связанные с ними.
Я не хочу
Заставлять регистрироваться одновременно на всех серверах
Нарушать равноправие серверов и помечать какой-либо сервер как главный.
Удалять какие-либо учётные записи и связанные с ними данные.
A>Проблема: регистрация пользователя. A>Пусть пользователь Вася Пупкин зашёл на сервер A и зарегистровал логин vasja, а пользователь Вася Тяпкин зашёл на сервер B и тоже зарегистрировал логин vasja. Очевидна проблема — что делать с двумя одинаковыми логинами (пользователи идентифицируются по GUIDам, но для аутенфикации используются логины)? Тем более что до того как ситуация будет обнаружена оба пользователя могут записать некоторые данные, связанные с ними. A>Я не хочу A> Заставлять регистрироваться одновременно на всех серверах A> Нарушать равноправие серверов и помечать какой-либо сервер как главный. A> Удалять какие-либо учётные записи и связанные с ними данные.
Так это вроде стандартно
1. Сервер, получивший запрос на регистрацию, отсылает всем остальным серверам сообщение о блокировке логина
2. Регистрирует пользователя
3. Отсылает всем серверам, что логин зарегистрирован.
Единственный вопрос — как сервера будут узнавать друг о друге. Без этого никак.
Re: Распределённая база пользователей и регистрация.
Здравствуйте, adontz, Вы писали:
A>Вот возникла интересная задача. Скорее даже теоретическая.
A>Пусть у нас есть некоторая сетевая система с несколькими равноправными серверами. Клиентское ПО может подключится к любому и конкретный выбор не отражается на поведении. Клиентское ПО пишет и читает данные с сервера. Время от времени сервера обмениваются данными полученными от клиентов. Пожалуй наиболее похожая система это Active Directory для Windows 2000 и выше.
A>Проблема: регистрация пользователя. A>Пусть пользователь Вася Пупкин зашёл на сервер A и зарегистровал логин vasja, а пользователь Вася Тяпкин зашёл на сервер B и тоже зарегистрировал логин vasja. Очевидна проблема — что делать с двумя одинаковыми логинами (пользователи идентифицируются по GUIDам, но для аутенфикации используются логины)? Тем более что до того как ситуация будет обнаружена оба пользователя могут записать некоторые данные, связанные с ними. A>Я не хочу A> Заставлять регистрироваться одновременно на всех серверах A> Нарушать равноправие серверов и помечать какой-либо сервер как главный. A> Удалять какие-либо учётные записи и связанные с ними данные.
Ок. А почему бы не классифицировать сервера по выполняемым задачам? Получается, если четыре сервера могут раздавать данные, а бсолютно равноправно, то регистрироваться действительно нельзя, а кроме того нужно ещё считать например деньги за проспотренный контент и проводить прочее административное журналирование, т.о. ИМХО всплывает пятый сервер — сервер регистрации и у правления, а так же он же мршрутизатор и редиректор .... но сам контент он не предоставляет, такая модель помоему имеет право на жизнь ...
Per Aspera Ad Astra
Re[2]: Распределённая база пользователей и регистрация.
Здравствуйте, _INDY_, Вы писали:
_IN>Ок. А почему бы не классифицировать сервера по выполняемым задачам? Получается, если четыре сервера могут раздавать данные, а бсолютно равноправно, то регистрироваться действительно нельзя, а кроме того нужно ещё считать например деньги за проспотренный контент и проводить прочее административное журналирование, т.о. ИМХО всплывает пятый сервер — сервер регистрации и у правления, а так же он же мршрутизатор и редиректор .... но сам контент он не предоставляет, такая модель помоему имеет право на жизнь ...
Здравствуйте, Mikhail Polykovsky, Вы писали:
MP>1. Сервер, получивший запрос на регистрацию, отсылает всем остальным серверам сообщение о блокировке логина MP>2. Регистрирует пользователя MP>3. Отсылает всем серверам, что логин зарегистрирован.
MP>Единственный вопрос — как сервера будут узнавать друг о друге. Без этого никак.
Сервера друг о друге знают, но это не спасает. Представим себе такой сценарий.
Есть пользователи P и Q и сервера X и Y
Связи P-X, Q-Y работают, а вот связи P-Y, P-Q, Q-X, X-Y не работают. Скажем сетевой сбой. Это вполне вероятно если P и X в одной подсети, а Q-Y в другой.
P послал запрос на регистрацию логина vasja серверу X, а Q послал аналогичный запрос серверу Y.
X разослал всем оповещения, но до Y они не дошли, потому что сетевой сбой. И наоборот от Y к X тоже ничего не попало.
И чё мне делать?
А зачем аутентифицировать на всех серваках, а не отдельном сервере.
В случае с Kerberos, при аутентификации к любому серваку, он прокидывает аутентифицирующую информацию на сервер Kerberos. Тот генерит некоторый уникальный тикет. И далее пользователь работает равноправно со всеми сервисами пользуясь данным тикетом. И сервер в любой момент может подтвердить данный тикет с помощью выделеного сервера Kerberos. Active Directory содержит в себе как раз Kerberos.
Re[2]: Распределённая база пользователей и регистрация.
Здравствуйте, GlebZ, Вы писали:
GZ>А зачем аутентифицировать на всех серваках, а не отдельном сервере. GZ>В случае с Kerberos, при аутентификации к любому серваку, он прокидывает аутентифицирующую информацию на сервер Kerberos. Тот генерит некоторый уникальный тикет. И далее пользователь работает равноправно со всеми сервисами пользуясь данным тикетом. И сервер в любой момент может подтвердить данный тикет с помощью выделеного сервера Kerberos. Active Directory содержит в себе как раз Kerberos.
Здравствуйте, adontz, Вы писали:
A>что делать с двумя одинаковыми логинами (пользователи идентифицируются по GUIDам, но для аутенфикации используются логины)?
кроме логина использовать дополнительно "имя" сервера. Например: vasia.pupkin@google.com vs. vasia.pupkin@microsoft.com.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>кроме логина использовать дополнительно "имя" сервера. Например: vasia.pupkin@google.com vs. vasia.pupkin@microsoft.com.
Здравствуйте, adontz, Вы писали:
GZ>>А зачем аутентифицировать на всех серваках, а не отдельном сервере. GZ>>В случае с Kerberos, при аутентификации к любому серваку, он прокидывает аутентифицирующую информацию на сервер Kerberos. Тот генерит некоторый уникальный тикет. И далее пользователь работает равноправно со всеми сервисами пользуясь данным тикетом. И сервер в любой момент может подтвердить данный тикет с помощью выделеного сервера Kerberos. Active Directory содержит в себе как раз Kerberos.
A>А если самый главный сервер станет недоступен?
А причем тут главный сервер. Доступен должен быть сервер с Kerberos для всех остальных серваков. Есть также в WSE3 какая-то фигня, которая делает распределенную аутентификация с разными web сервисами. Но что именно такое — не смотрел за ненадобностью. Возможно что-то похожее на то, что нужно тебе.
Re[3]: Распределённая база пользователей и регистрация.
Здравствуйте, adontz, Вы писали:
GZ>>А зачем аутентифицировать на всех серваках, а не отдельном сервере. GZ>>В случае с Kerberos, при аутентификации к любому серваку, он прокидывает аутентифицирующую информацию на сервер Kerberos. Тот генерит некоторый уникальный тикет. И далее пользователь работает равноправно со всеми сервисами пользуясь данным тикетом. И сервер в любой момент может подтвердить данный тикет с помощью выделеного сервера Kerberos. Active Directory содержит в себе как раз Kerberos.
A>А если самый главный сервер станет недоступен?
А причем тут главный сервер. Доступен должен быть сервер с Kerberos для всех остальных серваков. Есть также в WSE3 какая-то фигня, которая делает распределенную аутентификация с разными web сервисами. Но что именно такое — не смотрел за ненадобностью. Возможно что-то похожее на то, что нужно тебе.
Re[3]: Распределённая база пользователей и регистрация.
Здравствуйте, adontz, Вы писали:
GZ>>А зачем аутентифицировать на всех серваках, а не отдельном сервере. GZ>>В случае с Kerberos, при аутентификации к любому серваку, он прокидывает аутентифицирующую информацию на сервер Kerberos. Тот генерит некоторый уникальный тикет. И далее пользователь работает равноправно со всеми сервисами пользуясь данным тикетом. И сервер в любой момент может подтвердить данный тикет с помощью выделеного сервера Kerberos. Active Directory содержит в себе как раз Kerberos.
A>А если самый главный сервер станет недоступен?
А причем тут главный сервер. Доступен должен быть сервер с Kerberos для всех остальных серваков. Есть также в WSE3 какая-то фигня, которая делает распределенную аутентификация с разными web сервисами. Но что именно такое — не смотрел за ненадобностью. Возможно что-то похожее на то, что нужно тебе.
Re[3]: Распределённая база пользователей и регистрация.
Здравствуйте, adontz, Вы писали: A>А если главный сервер будет недоступен?
Не разрешать регистрироваться, вот и всё ... а услуги предоставлять можно, он же не на всегда недоступен ...
Per Aspera Ad Astra
Re[3]: Распределённая база пользователей и регистрация.
adontz wrote:
> ANS>кроме логина использовать дополнительно "имя" сервера. Например: > vasia.pupkin@google.com vs. vasia.pupkin@microsoft.com. > > Хмм.... это идея. Надо подумать, спасибо!
Ну с этого и надо было начинать. Просто я подумал, что требуется возможность зарегистрироваться на
vasia.pupkin@microsoft.com, а потом, когда Майкрософт упадёт, дать возможность пользователю залогиниться на
vasia.pupkin@google.com и использовать все данные, которые были на майкрософтовском серваке. Это и означает
распределённость. А так — просто несколько разных серверов, в чём распределённость?
Хотя действительно, так ли часто регятся юзеры по сравнению с частотой логинов? Пусть всё же будет один выделенный
сервак для регистрации.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: Распределённая база пользователей и регистрация.
_>Ну с этого и надо было начинать. Просто я подумал, что требуется возможность зарегистрироваться на _>vasia.pupkin@microsoft.com, а потом, когда Майкрософт упадёт, дать возможность пользователю залогиниться на _>vasia.pupkin@google.com и использовать все данные, которые были на майкрософтовском серваке.
Да, но тут какое дело. Если я регистрируюсь на microsoft.com то к логину добавляется microsoft.com Если microsoft.com не доступен, то я не могу зарегистрироватся с логином оканчивающимся на microsoft.com. Это всё же меньшее зло, чем два одинаковых логина или невозможность регистрации.
Здравствуйте, adontz, Вы писали:
A>Да, но тут какое дело. Если я регистрируюсь на microsoft.com то к логину добавляется microsoft.com Если microsoft.com не доступен, то я не могу зарегистрироватся с логином оканчивающимся на microsoft.com. Это всё же меньшее зло, чем два одинаковых логина или невозможность регистрации.
Кстати, я всегда думал, что именно так работает винда. Типа "по мне лазит Вася авторизованый машиной Ф, и Вася с машины З".
