###################
#Блоги разработчиков
# Написал Дмитрий Роот
11.01.2007
Доброго времени суток, друзья!
Итак, открылся блог разработчиков Диптауна.
Многие говорят, что это нужно было сделать еще 4 года назад, когда проект только начинался. Но мы решили, что лучше поздно, чем никогда, и открыли его сейчас.
Блог предназначен для того, чтобы разработчики проекта могли делиться с читателями своими соображениями о будущем проекта, идеями, а также мыслями о том, что происходит и будет происходить в IT сфере.
Мы надеемся, что благодаря этому блогу наши читатели смогут лучше понять, к чему идет проект и что нас ждет в будущем.
В своем блоге, кроме всего прочего, я время от времени буду выкладывать воспоминания о том, что происходило с проектом за годы его существования, и попытаюсь таким образом восполнить упущенное время.
Итак, добро пожаловать.
Написал Дмитрий Роот
14.01.2007
Сегодня я хотел бы немного рассказать об идеологии нашего проекта: к чему мы стремимся и каким видим проект в будущем. Также я отвечу на некоторые вопросы, которые часто приходится слышать от интересующихся проектом людей.
За все время существования проекта у нас постоянно был открытым вопрос о его цели. Ответ на этот вопрос постоянно менялся, особенно в первое время существования. Сейчас "официальный" ответ на этот вопрос звучит следующим образом:
Целью проекта является:
* техническая реализация идеи проекта;
* проектирование и дизайн центральной части Диптауна;
* создание организации для административного контроля и развития проекта;
* техническая и административная поддержка проекта;
* дальнейшее развитие созданного мира.
Однако в процессе создания Диптауна я осознал - и остальные разработчики, я думаю, со мной согласятся, - что это отнюдь не главное. Мы создаем не виртуальный мир. Мы создаем информационную среду.
Компьютер, в том виде, в котором он есть сейчас, на мой взгляд очень развит в вычислительном плане, но совершенно не приспособлен для работы с человеком. Почему? Поясню на примерах:
* Файловая система - это, пожалуй, самый яркий пример. Древовидная организация информации очень удобна для компьютера: дерево - это один из алгоритмов быстрого поиска данных. Но удобно ли это человеку? По-моему, нет. Наверное каждый из нас сталкивался с необходимостью найти какой-то файл. Если при этом не помнить имя файла, поиск может затянуться. А если к тому же не помнить, на каком из ста дисков он записан? Поиск может затянуться на весь день... Сейчас существуют некоторые локальные решения этой проблемы (с ходу не вспомню названий) - но массового их применения я не вижу.
* Зоопарк процессоров, архитектур и операционных систем. Программа, написанная для PC, не будет работать на КПК. Совместимость Windows и Linux - это вообще проблема глобального масштаба, на мой взгляд. С точки зрения разработчиков процессоров, архитектур и ОС, каждая имеет свои преимущества, недостатки и области применения. Но все забыли о пользователе, которого, вообще-то, все эти проблемы должны мало волновать: ему нужно работать.
* Поиск информации. Многих, конечно, очень привлекает двухчасовой процесс поиска необходимой информации в яндексе, но лично я предпочел бы потратить это время на что-нибудь более полезное.
* Сохранность информации. Каждый из нас, наверное, сталкивался с такой проблемой, что какой-то файл потерян в результате сбоя программы, железа или - что самое частое - неосторожности в обращении с клавишей Delete. Разработчики железа ссылаются на статистику, а разработчики софта - на "тупость" пользователей. Я же считаю, что раз человеку свойственна невнимательность - значит, компьютер должен под это подстраиваться. А не наоборот.
Можно привести еще множество аналогичных примеров, но вывод один: современная ситуация такова, что компьютер скорее не служит человеку, а повелевает им, сколь бы пафосно это ни звучало. Говоря более точно - программные и аппаратные средства создаются с точки зрения удобства реализации, а не удобства для пользователя.
Проект Диптаун нацелен на то, чтобы изменить сложившуюся ситуацию - среди своих пользователей, конечно. Главной его целью я вижу именно создание единой информационной среды, нацеленной на то, чтобы служить пользователю. Виртуальная реальность в это вписывается лишь как удобное - но не единственное - представление информации. Для осуществления этой цели мы уже разработали технологии, которые позволят частично или полностью решить обозначенные проблемы. Сейчас я не буду заострять внимание на этих технологиях - об этом я напишу более подробно позже.
Теперь о вопросах пользователей. Больше всего всех интересует вопрос - когда, наконец, можно будет посмотреть на хоть какую-то демку?
Спешу вас обрадовать: ждать осталось совсем недолго, уже скоро будет публичное тестирование. Но эта версия пока что будет подпадать лишь под критерий "хоть что-то", потому как ничего особенного там не будет. Это тестирование нужно будет, в основном, разработчикам, а не пользователям: нам нужно собирать статистику о работоспособности клиентской программы на различных конфигурациях компьютеров и операционных системах, а также тестировать сервер на стабильность и большую нагрузку.
Второй вопрос: каким образом можно помочь проекту?
Чем дальше идет разработка, тем больше открывается фронтов работ. Поэтому если еще полгода-год назад мы не могли принимать много народу, то теперь нам нужны специалисты в самых разных областях:
* журналисты (или как их правильно назвать? не знаю). Многие жалуются на отсутствие информации о проекте. Информация есть, но она есть только в виде технической документации. Проекту нужны люди, которые умеют правильно подать информацию.
* технические писатели - люди, умеющие хорошо писать и имеющие представление о программировании. В обязанности будет входить обновление документации по мере разработки. Сейчас, когда стандарты API ядра и основных модулей еще не "устоялись", документация должна постоянно обновляться;
* дизайнеры, моделеры - соответственно, моделировать объекты, рисовать текстуры и материалы;
* ну и конечно же программисты C++. Я думаю не нужно пояснять, зачем они нужны.
Для того, чтобы принять участие, лучше всего обратиться непосредственно ко мне. Все контакты есть в профиле на этом сайте и на форуме.
аписал Дмитрий Роот
19.01.2007
Завтра будет день рождения нашего проекта. Прошло 4 года с того времени, как мы встретились и поставили себе цель - реализовать Диптаун. Впрочем, продуктивной можно назвать только работу последних двух лет. За это время мы наконец-то сделали хоть что-то, что можно показать пользователям - во всяком случае тем, кто интересуется развитием проекта.
Нужно отметить, что это будет именно тестирование, а не демонстрация. Если бы мы хотели что-то продемонстрировать - то никак не существующую версию.
Целью тестирования является:
выявление ошибок и недоработок;
демонстрация того, что работа над проектом не стоит на месте;
привлечение в проект программистов и дизайнеров.
Тут сразу нужно сделать несколько оговорок.
Во-первых, тестирование будет предложено только пользователям ОС Windows. Версия клиента для Linux прекрасно работает - причем даже более стабильно, чем Windows-версия, - но вот сборка бинарного дистрибутив для Linux сопряжена с определенными трудностями, а с учетом того, что пользователей этой ОС немного - мы решили не тратить на это время. Кроме того, потребуется Windows версии не меньше 2000.
Во-вторых, данная версия вряд ли будет хорошо работать на модемном соединении. Связано это с тем, что на данный момент еще не реализованы некоторые очень важные алгоритмы уменьшения количества трафика (например, дельта-компрессия), а также не реализованы алгоритмы, позволяющие передавать информацию только о видимых объектах, а не обо всей сцене.
Тестирование начнется завтра, 20.01.2007, в 19 часов по Московскому времени. Участники тестирования получат персональные приглашения по e-mail. Сбор и дальнейшие инструкции будут происходить на нашем IRC-канале.
Если Вы хотите принять участие в тестировании - пожалуйста, оставьте комментарий под этой записью. Количество участников ограничено.
Написал Дмитрий Кашицын
20.01.2007
Ну вот и первый мой пост на этом блоге. Смешно сказать, это не только первая запись но и первый мой блог вообще. До недавнего мнения я относился к блогам вполне равнодушно, если не сказать холодно. Даже не знаю почему все сложилось именно так... Нет, я не осуждал блоггеров и блоггерство в таком виде, в котором оно существует в наши дни. Скорее, я не совсем понимал смысла ведения подобных дневников, не смотря на то что все большая часть прогрессивного человечества отдает должное данной области человеческой деятельности.
...В общем, так это или иначе, но я постараюсь исправить недостойные сетянина мысли своими же поступками. Посмотрим, что из этого всего получится.
Да здравствует первый пост! Самый важный из всех постов!
P.S.: Довольно символично, что свой первый пост я приурочил ко дню рождения нашего проекта. Собственно эта мысль и натолкнула меня на создание своего рода летописи, в которой я постараюсь описать то как проект зарождался, какие события происходили в том далеком 2003м году, и как это все повлияло на то что мы с вами наблюдаем в настоящее время. Кто знает, может быть эта информация переживет нас всех, а потом чайники будут слагать легенды о первых виртуальщиках =)
Написал Дмитрий Роот
18.02.2007
Сегодня я бы хотел поговорить о том, как правильно отправлять отчеты об ошибках. Несмотря на то, что по этому поводу написано множество статей, я бы хотел обратить Ваше внимание на то, как это нужно делать с учетом некоторых аспектов нашего проекта.
В последнее время мы довольно часто проводим различные тестирования ПО Диптауна среди собравшихся на нашем канале в IRC. Тестирования бывают самого разного масштаба: начиная от избранных одного-двух человек и заканчивая массовыми тестированиями для всех желающих. И практически каждый раз выявляются какие-то новые ошибки: то сервер повиснет, то клиент вылетит с ошибкой. К сожалению, я наблюдаю такую странную вещь: посетителями канала эти тестирования воспринимаются как определенного рода игра. Как будто мы проводим их забавы ради. Смею вас заверить - это не так. От посетителей скрыты те бессонные ночи, которые мы проводим после каждого тестирования в попытках поиска ошибок, которые были выявлены в процессе. И очень часто бывает, что ошибку сложно найти из-за недостатка информации о ней.
Во многих случаях грамотные отчеты об ошибках могут значительно уменьшить время их поиска. Нужно только соблюдать определенные правила их написания, чтобы прислать именно ту информацию, которая нам необходима. Если выучить эти правила, написание отчетов будет отнимать по 5-7 минут времени, тогда как эта информация может сэкономить нам часы.
1. Как можно более подробно опишите, что и в какой последовательности Вы делали
Это - самая важная часть отчета. Чем более подробно Вы напишете - тем лучше. Именно из последовательности Ваших действий мы делаем выводы о том, что происходило в системе. Особенно следует уделить внимание тем деталям, которые обычно не происходят, например: "При вводе пароля я ошибся, и мне пришлось ввести его еще раз." Обратите внимание, что об этом следует написать даже в том случае, если, как Вам кажется, неверный ввод пароля не является причиной ошибки: во-первых потому, что при таких действиях внутри ПО происходят определенные изменения, которые могут создать необходимые условия для ошибки, а во-вторых если вдруг выяснится, что ошибка возникала только в этом случае - это будет очень ценной информацией для ее поиска.
2. Опишите симптомы ошибки
Для поиска причины ошибки нужно хотя бы знать, что за ошибку мы ищем. И желательно иметь это знание не на уровне "все повисло, кнопки не нажимаются", как мы можем судить по высказываниям в IRC.
Опишите возникшие визуальные эффекты. Например, если клиент вылетел с ошибкой, то нам очень важно знать, как именно он это сделал. Вариантов может быть множество: окно может просто закрыться; Windows может предложить написать отчет об ошибке; может появиться окно с описанием ошибки графического движка; клиент может повиснуть и не реагировать на клавиатуру.
Кстати, о повисании клиента. Повисшим его стоит считать только в том случае, если в левом нижнем углу экрана не обновляется статистика. Если статистика обновляется - об этом нужно обязательно сообщить в отчете.
3. Вложите в очет логи и файлы конфигурации
Эти файлы не так важны, как многие считают, но в некоторых случаях они позволяют встать на правильный путь поиска. Необходимо вложить следующие файлы:
* error_log
* event_log
* Media\Ogre.log
* Media\CEGUI.log
* local_startup.dsh
* Media\ogre.cfg
Больше никаких файлов вкладывать не нужно. Если Windows предложила отправить отчет об ошибке - не нужно отправлять этот отчет. Это лишняя трата времени и трафика.
Если Вы оставляете отчет на форуме - лучше всего вложить все вышеуказанные файлы в один архив и прикрепить его к своему сообщению.
4. Больше ничего писать не нужно
Лишняя информация в отчете совершенно ни к чему, а иногда она даже во вред. Если нам нужно будет уточнить какой-то вопрос - мы свяжемся с Вами через форум или в IRC и уточним. Отчет - это не сочинение по литературе. Нам нужно знать факты и только факты.
Не нужно писать каких-либо своих рецензий, предположений, эмоций и пр. Отчет, состоящий всего из двух строк четкого описания ситуации, гораздо ценнее двух абзацев околопроектной тематики.
Если Вы хотите предложить, как усовершенствовать ПО, высказать по нему свое мнение, предложить свою помощь в решении проблемы или написании кода - поверьте, мы будем очень рады это услышать. Вы можете написать свое предложение в форум, либо отправить его электронным письмом в группу поддержки или непосредственно мне или кому-то еще. Но только пожалуйста, не пишите его в отчете об ошибке!
Примеры
Приведу два примера - правильного и неправильного отчета.
Пример хорошего отчета:
"Я запустил клиента. Через некоторое время мне было предложено ввести логин и пароль. Я прошел авторизацию, вошел. Увидел двух человек, идущих навстречу. Я попытался пойти вперед, нажав клавишу ВВЕРХ. В этот момент клиент повис: персонажи напротив остановились, статистика кадров не обновлялась, на ввод с клавиатуры и движение мыши он не реагировал. Я нажал ctrl+alt+del и снял задачу deep.exe."
В этом отчете - всего несколько строк, но они содержат только факты, которые и являются ценной информацией. С начала и до слова "ВВЕРХ" идет описание собственных действий. Такой подробности описания будет вполне достаточно. После - описание симптомов.
Пример плохого отчета:
"Я нажал клавишу ВВЕРХ, и графический движок повис. Мне пришлось прибить клиента из диспетчера задач."
И речь даже не о том, что этот отчет очень краток - мне просто было лень придумывать пример длинного неправильного отчета :). Я бы хотел обратить Ваше внимание на то, что из этих двух предложений ценной информацией являются только первые четыре слова - т.е. то, что какая-то ошибка произошла после нажатия клавиши ВВЕРХ. О том, произошло ли это в момент авторизации, в самый первый момент после появления, или же через некоторое время после входа - автор умалчивает. Информация о том, что повис графический движок - это не более чем нелепое предположение автора. Повисание клиента может произойти по тысяче причин. Так посудите сами, кто сможет дать лучшую оценку причины ошибки - разработчики, которые держат в голове весь код клиента, или автор отчета, который, возможно, видит клиентскую программу впервые? Так позвольте же разработчикам самим судить о причине ошибки, дав им для этого как можно больше ценной информации!
В заключение мне бы хотелось привести довольно неприятную статистику. Вчера было массовое тестирование, в котором участвовали по меньшей мере 10 человек. В процессе тестирования были выявлены ошибки - сервер зависал через некоторое время. После тестирования мы не получили ни одного отчета об ошибке! Ни мне на e-mail, ни в специально созданную для этого ветку форума. Итого - об этой ошибке мы вынуждены судить лишь по скудным логам сервера и не менее скундым логам общения участников тестирования в IRC. Представление об ошибке заключается лишь в том, что она "где-то есть". Ценность такого тестирования - ноль целых и ноль десятых.
Нам часто задают вопросы - "как помочь проекту? ну дайте же сделать хоть что-нибудь для проекта!". Как видите, решение - на поверхности: написав буквально 3-4 строчки, Вы можете сэкономить несколько часов, а то и дней, которые тратятся на поиск ошибки.
Написал Евгений Сыромятников
01.03.2007
Пришла пора рассказать Вам и о финансовой стороне нашего проекта. Не секрет, что разработка ведется силами разработчиков с использованием собственных средств. Не так давно мы начали поиски потенциальных партнеров и инвесторов. Партнерам было предложено оценить возможности нашего проекта и обговорить интересующие их варианты использования. Инвесторам же было предложено вложить определенную сумму денег, в обмен на получение акций компании и соответственно участие в прибыли компании.
За прошедший промежуток времени сложилась определенная статистика по пожеланиям фирм. Большая часть фирм предлагали за эту мизерную сумму выкупить весь проект, а один человек (Юрий Васильевич) предложил за 50 тысяч долларов выкупить контрольный пакет, надеясь на наше безвыходное положение и «русский авось».
Не исключением в надеждах на «русский авось» оказалось и правительство Москвы. Мы обратились к Ю.М. Лужкову с предложением создать виртуальную копию Москвы на базе наших разработок, но, Серов Илья Юрьевич, которому попало на исполнение наше обращение, предложил нам найти заказчика среди подразделений Правительства Москвы, и провести конкурс «среди меня» на выполнение этого заказа. Опять же с учетом что более-менее похожие услуги им сможет предложить только Linden Labs, заставляет задуматься о том, для чего нужен этот конкурс (с кучей дополнительных платных регистраций в различных реестрах), т.е. грубо говоря нам предложили заплатить Московскому правительству за возможность построить «Виртуальную Москву» на базе Диптауна.
Из более ранних переговоров стоит отметить поисковый сервис компании Webalta (http://www.webalta.ru/), Алексей Чурбанов сказал что оценят и он перезвонит скажет о результатах, а в результате когда я попытался ему позвонить узнать о результатах, человек просто перестал брать трубку, ну что ж, видимо, они делают ставку на неповторимый поисковый сервис.
Так же за это время успели выслушать от руководства компании «Ифити Групп» (http://ifiti.ru/), в лице Баранова Сергея, предложение выкупить у них товарный знак «Диптаун», на который у них не только нет никаких прав, но даже регистрационных документов.
Также предложение о партнерстве было выслано в компанию Рамблер. Максимова Светлана после некоторого времени сказала «если нас заинтересует, мы Вам перезвоним», видимо, не заинтересовало.
По банкам тоже было разослано предложение участия, в качестве официального и единственного банка виртуального пространства Диптауна. Сотрудники банков Райффайзен и Авангард, поначалу, рассказывали как их это заинтересовало, а в дальнейшем сославшись на передачу финансистам для анализа прибыльности, обещали перезвонить. Видимо, у них есть множество подобных предложений о монопольном вхождении на закрытый рынок, на более выгодных условиях (хотя условия не обсуждались вообще).
Написал Евгений Сыромятников
06.03.2007
Сегодня я постараюсь детально рассмотреть вопрос денежной системы Диптауна. Многие считают, что идеальным было бы введение внутренней валюты, по примеру Second Life. Но мы придерживаемся прямо противоположного мнения, и на объяснении этих причин постараюсь сегодня остановиться поподробнее.
Давайте попытаемся понять, как же формируется курс валюты. В реальности курсы валют формируются на рынке, т.е. по результатам торгов. И на чем основывается это все? Естественно, на куче всяких экономических показателей, и в результате, не имея ничего за душой, наша валюта стоить будет копейки, а выставлять курс как это сделали в Linden Labs, по-моему глупо и заведомо обман. Ведь по сути, когда курс валюты на каждую конкретную операцию по обналичке может быть отдельно выставлен администрацией проекта, тут уж любой дурак поймет что крупную сумму обналичить по тому курсу, который сейчас есть, у него не получится.
Второй вопрос вытекает из выводов по первому: Ликвидность активов. И снова обратимся к теории: ликвидность — экономический термин, обозначающий способность ценностей (активов) быть быстро проданными по цене, близкой к рыночной. Так вот, в случае с внутренней валютой, да еще с плавающим курсом устанавливающимся администрацией, ликвидность виртуальных активов стремится к нулю, т.е. грубо говоря это похороненные деньги. По той причине, что даже если есть огромный спрос и Вы можете моментально продать свои виртуальные активы, то это еще не гарантирует, что Вы сможете их вывести наружу без потерь.
Третий вопрос: гарантии на вложенные средства. К примеру, в реальности банк гарантирует возврат денег которые лежат на счету, а в случае с внутренней валютой, собственно никаких гарантий быть не может, банк существующий в игрушке, он не имеет каких бы то ни было уникальных реквизитов передаваемых пользователю, да и в договоре ничего не пишется ни о гарантиях, ни о страховании вкладов. Т.е. никто вам не гарантирует что этот банк набрав энное количество денег не испарится.
Вопрос четвертый: открытость данного рынка и прозрачность его. Ну чем может подтвердить руководство компании оборот указанный ими на главной странице? Своими внутренними отчетами? Или логами своего же сервера? Но это если только «за уши» притягивать к основаниям.
Ну и теперь попробую остановиться на способах которые помогут избежать подобных не совсем приятных моментов. Начнем по порядку, если вместо внутренней валюты пустить в это пространство для обращения реальные мировые валюты. Естественно возникнут некоторые вопросы о том, как это сделать. Как решение, реально существующий банк, открывает пользователям банковские счета, в реальной валюте, и предоставляет услуги платежной системы внутри виртуального пространства. При таком подходе не возникает ограничений на движение денежных средств между реальным миром и виртуальным пространством. И кроме того не возникает ситуации когда Администрация препятствует выводу административными или экономическими санкциями. Ликвидность активов уже не зависит от барьеров вывода средств из виртуального пространства в реальный мир, и зависит только от конъюнктуры внутреннего рынка. Что в сравнении с вариантом с внутренней валютой. Ну и гарантии вкладов и страхование, все это так же предоставляется реально существующим банком, с которым заключается договор имеющий юридическую силу, в отличие от игровых миров. Плюс банк может сформировать обоснованный анализ рынка.
Исходя из всех этих условий и заботясь об удобстве пользователя, нами было принято решение об использовании реальной валюты, и полностью открытой банковской системой. Не только для удобства пользователей, но и для простоты работы компаний.
Написал Дмитрий Роот
08.03.2007
Сегодня я бы хотел сказать пару слов про защиту информации в сети Диптауна. Я постараюсь на пальцах пояснить, как работает система авторизации пользователей в сети, и если среди читателей найдутся специалисты в области безопасности - буду весьма признателен за их мнение по этому поводу.
Учет всех пользователей сети ведут т.н. сервера авторизации. Этих серверов - больше одного, но некоторое ограниченное количество - по нашим прикидкам, 10-20 штук будет вполне достаточно. Все эти сервера известны всем пользователям сети, т.е. изменение списка этих серверов не может происходить в автоматическом режиме - только через обновление клиенского ПО. Фактически, это - единственный в какой-то мере централизованный элемент сети Диптауна (в том смысле, что больше никакой централизации в сети нет).
Каждый сервер сети Диптауна имеет сертификат сервера, выданный сервером авторизации. Таким образом устанавливается подлинность сервера - т.е. пользователь всегда может быть уверен, что соединяется с тем сервером, с которым он хотел соединиться.
Сразу оговорюсь, что в сети Диптауна используются свои форматы ключей и сертификатов. Т.е. под сертификатом не следует понимать стандартный X.509 сертификат. С точки зрения безопасности, сертификат - это всего лишь техническая информация о сервере, подписанная ключом доверенного сервера - в данном случае сервера авторизации. Проверка сертификата заключается в том, чтобы убедиться, что информация в сертификате соответствует ожидаемой, а подпись - верна.
Но самое интересное - это авторизация пользователя в сети. Сеть является распределенной, и пользователь в процессе своих блужданий может посещать десятки различных серверов. Каждый из них должен удостовериться, что пользователь - тот, за кого он себя выдает. Каким образом он это делает? В этом заключается суть процесса авторизации.
Прежде всего, пользователь соединяется с сетью через сервер доступа, который служит для него, фактически, проводником по сети. Т.е. пользователь единожды при запуске клиента соединяется с сервером доступа, и все дальнейшее общение происходит с ним: сервер доступа сам устанавливает соединения с остальными требуемыми данным пользователем серверами сети.
Как только пользователь соединяется с сервером доступа, он проходит процесс авторизации. Для этого сервер доступа соединяет его с сервером авторизации. После проверки логина и пароля, сервер авторизации выдает серверу доступа пользователя сертификат сессии, в котором указывается следующая информация:
* идентификатор пользователя;
* отпечаток публичного ключа сервера доступа;
* время действия сертификата.
Возможно также указать "черный" или "белый" список серверов, для которых действителен данный сертификат.
Когда процесс авторизации пройден - пользователь входит в Диптаун, и, сам того не подозревая, заходит на множество серверов обсчета ландшафта. Каждый раз, когда это происходит, сервер доступа пользователя передает серверу обсчета ланжшафта выданный пользователю сертификат сессии, по которому и устанавливается подлинность пользователя.
Наличие в сертификате такого поля, как отпечаток публичного ключа сервера доступа, делает возможным использование данного сертификата только с данным сервером доступа - т.е. даже если кто-то и сворует этот сертификат, он не сможет им воспользоваться, поскольку не имеет приватного ключа сервера доступа пользователя.
В этой схеме предполагается, что пользователь доверяет своему серверу доступа, а серверам авторизации доверяют все. На наш взгляд, такой подход сочетает в себе удобство и достаточную степень безопасности. Для тех серверов, где стандартный уровень безопасности кажется недостаточным, предусмотрены более сложные методы авторизации.
На данный момент полностью реализован модуль ядра, отвечающий за безопасность: разработаны форматы данных ключей и сертификатов, имеется возможность их генерации и проверки, реализована авторизация пользователя по сертификату.
В часности, мне вчера удалось выдать самому себе сертификат, который прошел все проверки среднего уровня безопасности. Конечно, это было сделано в рамках тестирования, но тем не менее это можно считать первой успешной авторизацией в сети Диптауна
Написал Дмитрий Роот
24.03.2007
Сегодня я хотел бы рассказать об архитектуре сети Диптауна.
С точки зрения пользователя, сеть Диптауна представляет собой большой кластер. Т.е. нет никаких серверов - есть просто большой черный ящик. Под этим подразумевается то, что когда клиент говорит - "хочу доступ к такому-то объекту" - ему не надо знать адрес сервера, на котором расположен объект. Он просто кричит в черный ящик: "дайте мне такой-то объект" - и вот тебе пожалуйста.
А внутри это все организовано следующим образом.
Мозгом сети Диптауна являются сервера обсчета ландшафта, каждый из которых занимается обсчетом определенного количества объектов. Каждый сервер ландшафта отвечает за свой небольшой участок пространства.
Почему выбрана кластеризация именно такого рода? Просто потому, что скорее всего пользователь будет в один момент времени находиться в одной точке пространства - а соответственно, чтобы минимизировать количество серверов, с которыми соединен (через сервер доступа) пользователь, лучше всего разбить объекты между ЛС-ами по пространственному признаку. Каждый ЛС сервер соединен со своими соседями по пространству. Это нужно для того, чтобы в момент выхода объекта за пределы области ответственности сервера, сервер знал бы, куда именно нужно передать этот объект. Таким образом, сеть серверов обсчета ландшафта, распределенных по пространству, уже сама по себе позволяет бесконечно расширять это пространство и наращивать объектами. И все бы хорошо, если бы не некоторые проблемы.
Проблема первая и самая главная заключается в том, что в такой системе невозможно найти объект в сети. Ну тоесть грубо говоря есть некоторый объект, у него есть какой-то пусть даже уникальный по всей сети идентификатор. В качестве объекта может быть аватар или один из концов телепорта - не важно. Требуется найти этот объект, чтобы выполнить с ним какое-то действие. В этой концепции пришлось бы искать его, отправляя сообщения по всей сети, что сделало бы нагрузку на сеть огромной.
Для решения этой проблемы введены сервера генерации уникальных идентификаторов. Уникальный идентификатор объекта в нашей сети - это 16-байтовое число. Причем в этом числе 4 байта отвечают за адрес сервера, который выдал этот идентификатор (под адресом понимается не IP-адрес сервера, а внутренний адрес). Таким образом, в момент создания объекта он получает уникальный идентификатор, в котором указан адрес сервера, на котором зарегистрирован данный объект. Далее - обо всех перемещениях в сети сервера сообщают этому серверу. И когда требуется узнать, где находится объект - достаточно спросить у сервера, адрес которого есть прямо в идентификаторе объекта. Причем этот механизм встроен прямо в сетевой движок: т.е. вся эта процедура узнавания местоположения полностью автоматизирована ядром и совершенно прозрачна для пользователя (сообщения, передаваемые объектам, называются "событиями"). Всю черновую работу по вычислению текущей дислокации объекта ядро берет на себя.
Вторая проблема - это проблема оптимальной нагрузки. Когда проектируется пространство Диптауна, вряд ли можно сразу сказать наверняка, в какое место народ будет ходить толпами, а в какое - только изредка заглядывать. И поэтому тут все автоматизировано: для решения этой проблемы создана сеть брокеров. Эта сеть построена по древовидному принципу. Т.е. есть корневой брокер, у него в подчинении - буквально несколько серверов, которые только в общих чертах представляют о нагрузке в отведенных им зонах. Они, в свою очередь, имеют более мелких подчиненных и т.д. вплоть до самых мелких брокеров, которые уже занимаются непосредственно перераспределением нагрузки между серверами поддержки ландшафта.
Конечно, этот процесс - кому что считать - завязан на политику сети (в том смысле, что какие-то компании не захотят, чтобы их сервера занимались обсчетами каких-то левых кусков пространства, и наоборот - не хотели бы отдавать свои офисы в обсчет левым серверам), поэтому процесс перераспределения нагрузки будет тонко настраиваем (т.е. брокеру можно, например, сказать - что, мол, вот эту группу серверов не трогать ни при каких условиях).
Таким образом мы видим, что сеть Диптауна является саморегулирующейся. Кроме того, благодаря брокерам возможны механизмы зеркалирования некоторых участков. Т.е. если несколько серверов обсчета ландшафта падает - соответствующая часть пространства может быть по-быстрому перераспределена между остальными серверами.
Говоря о сети Диптауна, нельзя также не сказать про авторизацию в сети и сервера доступа. Но об этом можно прочитать в предыдущем посте. Прошу прощения за непоследовательность, конечно =)
-----------------------------126651241320169
Content-Disposition: form-data; name="smiles_on"
1