В дополнение к топику про грид-мобильность.
Возник вопрос: а каким образом в системе без централизации будет назначаться ID пользователя, который зарегистрировался только что?
Одно из соображений: хранить базу всех ID в базе каждого пойнта. Минусы: обновление базы делать очень тяжко будет (в масштабах всех пользователей), да и в случае входа нескольких новых пользователей между обновлениями могут возникнуть коллизии по ID.
Другой вариант: назначать ID «не сразу». При прописывании в Сети берем ближайшие номера и смотрим, какие разряды уже точно забиты. Если, скажем, в окружении у пойнтов-соседей существует разряд (в двоичном представлении) номер 32, то ID начинается с разряда 33, в запросе отмечается «32-й равен нулю», и запрос передается на следующие пойнты. Там, где обнаруживается отсуствие заполненного разряда, в ID прописывается соответсвующий разряд.
Сам чувствую, что идея сырая, но это похоже на алгоритм поимки льва в Африке: делим Африку пополам, отбрасываем ту, в которой льва нет, повторяем до поимки…
Возник вопрос: а каким образом в системе без централизации будет назначаться ID пользователя, который зарегистрировался только что?
Одно из соображений: хранить базу всех ID в базе каждого пойнта. Минусы: обновление базы делать очень тяжко будет (в масштабах всех пользователей), да и в случае входа нескольких новых пользователей между обновлениями могут возникнуть коллизии по ID.
Другой вариант: назначать ID «не сразу». При прописывании в Сети берем ближайшие номера и смотрим, какие разряды уже точно забиты. Если, скажем, в окружении у пойнтов-соседей существует разряд (в двоичном представлении) номер 32, то ID начинается с разряда 33, в запросе отмечается «32-й равен нулю», и запрос передается на следующие пойнты. Там, где обнаруживается отсуствие заполненного разряда, в ID прописывается соответсвующий разряд.
Сам чувствую, что идея сырая, но это похоже на алгоритм поимки льва в Африке: делим Африку пополам, отбрасываем ту, в которой льва нет, повторяем до поимки…
