Project blogs

Архитектура сети

Сегодня я хотел бы рассказать об архитектуре сети Диптауна.

С точки зрения пользователя, сеть Диптауна представляет собой большой кластер. Т.е. нет никаких серверов - есть просто большой черный ящик. Под этим подразумевается то, что когда клиент говорит - "хочу доступ к такому-то объекту" - ему не надо знать адрес сервера, на котором расположен объект. Он просто кричит в черный ящик: "дайте мне такой-то объект" - и вот тебе пожалуйста.

А внутри это все организовано следующим образом.

Мозгом сети Диптауна являются сервера обсчета ландшафта, каждый из которых занимается обсчетом определенного количества объектов. Каждый сервер ландшафта отвечает за свой небольшой участок пространства.

Почему выбрана кластеризация именно такого рода? Просто потому, что скорее всего пользователь будет в один момент времени находиться в одной точке пространства - а соответственно, чтобы минимизировать количество серверов, с которыми соединен (через сервер доступа) пользователь, лучше всего разбить объекты между ЛС-ами по пространственному признаку. Каждый ЛС сервер соединен со своими соседями по пространству. Это нужно для того, чтобы в момент выхода объекта за пределы области ответственности сервера, сервер знал бы, куда именно нужно передать этот объект. Таким образом, сеть серверов обсчета ландшафта, распределенных по пространству, уже сама по себе позволяет бесконечно расширять это пространство и наращивать объектами. И все бы хорошо, если бы не некоторые проблемы.

Проблема первая и самая главная заключается в том, что в такой системе невозможно найти объект в сети. Ну тоесть грубо говоря есть некоторый объект, у него есть какой-то пусть даже уникальный по всей сети идентификатор. В качестве объекта может быть аватар или один из концов телепорта - не важно. Требуется найти этот объект, чтобы выполнить с ним какое-то действие. В этой концепции пришлось бы искать его, отправляя сообщения по всей сети, что сделало бы нагрузку на сеть огромной.

Для решения этой проблемы введены сервера генерации уникальных идентификаторов. Уникальный идентификатор объекта в нашей сети - это 16-байтовое число. Причем в этом числе 4 байта отвечают за адрес сервера, который выдал этот идентификатор (под адресом понимается не IP-адрес сервера, а внутренний адрес). Таким образом, в момент создания объекта он получает уникальный идентификатор, в котором указан адрес сервера, на котором зарегистрирован данный объект. Далее - обо всех перемещениях в сети сервера сообщают этому серверу. И когда требуется узнать, где находится объект - достаточно спросить у сервера, адрес которого есть прямо в идентификаторе объекта. Причем этот механизм встроен прямо в сетевой движок: т.е. вся эта процедура узнавания местоположения полностью автоматизирована ядром и совершенно прозрачна для пользователя (сообщения, передаваемые объектам, называются "событиями"). Всю черновую работу по вычислению текущей дислокации объекта ядро берет на себя.

Вторая проблема - это проблема оптимальной нагрузки. Когда проектируется пространство Диптауна, вряд ли можно сразу сказать наверняка, в какое место народ будет ходить толпами, а в какое - только изредка заглядывать. И поэтому тут все автоматизировано: для решения этой проблемы создана сеть брокеров. Эта сеть построена по древовидному принципу. Т.е. есть корневой брокер, у него в подчинении - буквально несколько серверов, которые только в общих чертах представляют о нагрузке в отведенных им зонах. Они, в свою очередь, имеют более мелких подчиненных и т.д. вплоть до самых мелких брокеров, которые уже занимаются непосредственно перераспределением нагрузки между серверами поддержки ландшафта.

Конечно, этот процесс - кому что считать - завязан на политику сети (в том смысле, что какие-то компании не захотят, чтобы их сервера занимались обсчетами каких-то левых кусков пространства, и наоборот - не хотели бы отдавать свои офисы в обсчет левым серверам), поэтому процесс перераспределения нагрузки будет тонко настраиваем (т.е. брокеру можно, например, сказать - что, мол, вот эту группу серверов не трогать ни при каких условиях).

Таким образом мы видим, что сеть Диптауна является саморегулирующейся. Кроме того, благодаря брокерам возможны механизмы зеркалирования некоторых участков. Т.е. если несколько серверов обсчета ландшафта падает - соответствующая часть пространства может быть по-быстрому перераспределена между остальными серверами.

Говоря о сети Диптауна, нельзя также не сказать про авторизацию в сети и сервера доступа. Но об этом можно прочитать в предыдущем посте. Прошу прощения за непоследовательность, конечно =)

Please login or register to see comments